You have a pre-tax amount like 20.00 and a tax rate like 0.08 (that's 8%). You want the after-tax total. What's the arithmetic?
Multiply the amount by one plus the rate? So 20 * 1.08 = 21.60.
Exactly. The formula amount * (1 + rate) gives you the total in one shot. In Python it reads the same way:
total = amount * (1 + rate)For amount=20, rate=0.08: total is 21.6.
Python gave me 21.6 — not 21.60. Do I need to force the two decimals somewhere?
Two different concerns. 21.6 and 21.60 are the same float — both values match. The trailing zero only matters when you format the number for display with an f-string. For a function that returns a float, you don't need a trailing zero.
What about floating-point weirdness? I've heard 0.1 + 0.2 doesn't give exactly 0.3 in Python.
It doesn't — it gives 0.30000000000000004. Same issue surfaces with tax arithmetic: 35.50 * 1.08 gives 38.34000000000001. For money, you clean that up with round(value, 2) — round to 2 decimal places at the boundary.
total = round(amount * (1 + rate), 2)
So arithmetic first, round() at the end — the rounding is the finishing touch that makes the float look like a price.
One line, predictable output, no surprises. This is the same round() pattern you'll reach for every time you need clean money values back from a calculation.
round()TL;DR: compute the total, then round at the boundary — never in the middle.
a * (1 + r) — add r% to around(x, 2) — 2 decimal places (banker's rounding)/ returns a float — 6 / 2 is 3.0, not 3| Value | print(x) | f"{x:.2f}" |
|---|---|---|
21.6 | 21.6 | 21.60 |
38.34 | 38.34 | 38.34 |
The trailing zero is a display concern, not a value concern. Use :.2f in f-strings for display; use round() to clean float imprecision.
You have a pre-tax amount like 20.00 and a tax rate like 0.08 (that's 8%). You want the after-tax total. What's the arithmetic?
Multiply the amount by one plus the rate? So 20 * 1.08 = 21.60.
Exactly. The formula amount * (1 + rate) gives you the total in one shot. In Python it reads the same way:
total = amount * (1 + rate)For amount=20, rate=0.08: total is 21.6.
Python gave me 21.6 — not 21.60. Do I need to force the two decimals somewhere?
Two different concerns. 21.6 and 21.60 are the same float — both values match. The trailing zero only matters when you format the number for display with an f-string. For a function that returns a float, you don't need a trailing zero.
What about floating-point weirdness? I've heard 0.1 + 0.2 doesn't give exactly 0.3 in Python.
It doesn't — it gives 0.30000000000000004. Same issue surfaces with tax arithmetic: 35.50 * 1.08 gives 38.34000000000001. For money, you clean that up with round(value, 2) — round to 2 decimal places at the boundary.
total = round(amount * (1 + rate), 2)So arithmetic first, round() at the end — the rounding is the finishing touch that makes the float look like a price.
One line, predictable output, no surprises. This is the same round() pattern you'll reach for every time you need clean money values back from a calculation.
round()TL;DR: compute the total, then round at the boundary — never in the middle.
a * (1 + r) — add r% to around(x, 2) — 2 decimal places (banker's rounding)/ returns a float — 6 / 2 is 3.0, not 3| Value | print(x) | f"{x:.2f}" |
|---|---|---|
21.6 | 21.6 | 21.60 |
38.34 | 38.34 | 38.34 |
The trailing zero is a display concern, not a value concern. Use :.2f in f-strings for display; use round() to clean float imprecision.
Write `apply_sales_tax(amount, rate)` that returns the amount plus tax, rounded to 2 decimal places. Example: `apply_sales_tax(20.0, 0.08)` returns `21.6`.
Tap each step for scaffolded hints.
No blank-editor panic.