Python Float Precision Calculator
Explore why Python does not calculate many decimal fractions exactly. Compare binary floating-point output with an exact decimal style calculation, inspect the rounding gap, and visualize the error that appears in common cases like 0.1 + 0.2.
Results
Enter values and click the button to see how binary floating-point compares with an exact decimal style calculation.
Why Python is not calculating floats exactly
When developers say that Python is not calculating floats exactly, they are usually not describing a Python bug. They are seeing a normal consequence of how modern computers store real numbers. Python uses IEEE 754 binary floating-point numbers for the built-in float type, which is the same broad model used by JavaScript, C, Java, and many other languages. This representation is extremely fast and works well for science, engineering, graphics, machine learning, and everyday calculations. However, it cannot represent every decimal fraction exactly.
The classic example is 0.1 + 0.2. In Python, if you inspect enough digits, the result reveals a tiny binary rounding artifact. That is because the values 0.1 and 0.2 are repeating fractions in base 2, just as 1/3 repeats forever in base 10. Python stores the nearest representable binary64 value, not the mathematically ideal infinite fraction. When arithmetic combines those approximations, the final result can differ by a very small amount from the decimal value humans expect to see.
How binary floating-point works
A Python float is typically an IEEE 754 binary64 number. That means it stores three main components: a sign bit, an exponent field, and a fraction field. Together these create a compact approximation of many values across a very large range. Binary64 is powerful because it offers roughly 15 to 17 significant decimal digits of precision while still fitting into 64 bits.
- 1 sign bit determines whether the number is positive or negative.
- 11 exponent bits scale the value up or down over a huge numerical range.
- 52 explicit fraction bits plus an implicit leading bit provide about 53 bits of precision.
This format is excellent for performance and broad compatibility, but it has a hard limit: only fractions whose denominator can be expressed as a power of 2 terminate exactly in binary. Numbers like 0.5, 0.25, and 0.125 are exact because they equal 1/2, 1/4, and 1/8. Numbers like 0.1 or 0.01 are not exact because their denominators involve factors other than 2. In decimal terms, 0.1 = 1/10, and 10 includes a factor of 5. Binary cannot terminate that fraction cleanly.
What Python is really storing
If you type 0.1 into Python, the interpreter stores the closest representable binary64 value. Python often prints a short friendly decimal representation, so at first it looks exact. But if you request more digits, you expose the hidden approximation. This is not deception. It is a formatting choice designed to keep the output readable while still round-tripping back to the same stored value.
| Metric | Binary64 fact | Why it matters |
|---|---|---|
| Total storage size | 64 bits | Standard double precision format used by Python floats on mainstream systems. |
| Precision bits | 53 significant binary bits | Produces about 15 to 17 reliable decimal digits. |
| Machine epsilon | 2-52 ≈ 2.220446049250313e-16 | Represents the gap between 1.0 and the next larger representable float. |
| Max finite value | ≈ 1.7976931348623157e308 | Shows the enormous range available before overflow to infinity. |
| Smallest normal positive value | ≈ 2.2250738585072014e-308 | Below this, subnormal numbers trade precision for range. |
The practical takeaway is simple: Python is usually doing the correct floating-point computation, but the mathematical object in memory is an approximation of your decimal input. Once that is clear, many strange outputs become easier to understand.
Examples of exact and inexact decimal values
Some numbers are naturally safe in binary floating-point, while others are recurring fractions that must be rounded. The pattern is predictable. A fraction is exactly representable in binary only if, after reduction, its denominator contains no prime factors other than 2.
| Decimal value | Fraction form | Exact in binary64? | Reason |
|---|---|---|---|
| 0.5 | 1/2 | Yes | Denominator is a power of 2. |
| 0.25 | 1/4 | Yes | Denominator is a power of 2. |
| 0.125 | 1/8 | Yes | Denominator is a power of 2. |
| 0.1 | 1/10 | No | Denominator contains factor 5, so binary expansion repeats. |
| 0.2 | 1/5 | No | Repeating in base 2. |
| 0.3 | 3/10 | No | Still includes a factor of 5 in the denominator. |
| 0.01 | 1/100 | No | 100 = 2² × 5², so the factor 5 prevents exact binary termination. |
Why 0.1 + 0.2 is such a famous example
The expression 0.1 + 0.2 has become the symbol of floating-point confusion because it is so simple, yet it exposes the core issue immediately. Both inputs are approximations, and their sum is another approximation. In a fully expanded decimal display, the result is slightly larger than exactly 0.3. In Python, this is expected behavior under IEEE 754 arithmetic.
It is important to understand that the error is usually very small. In many applications, the difference is tiny enough to be irrelevant. For scientific simulations, this is often acceptable because the model itself already contains uncertainty and because floating-point performance is critical. For financial software, however, even tiny decimal errors can be unacceptable if they affect totals, taxes, or audit trails. That is why Python offers alternatives such as the decimal module and exact rational arithmetic in fractions.Fraction.
Common places where float artifacts show up
- Equality tests. Comparing floats with == can fail even when values look identical on screen.
- Currency calculations. Repeated additions like prices, discounts, and tax rates can accumulate decimal representation errors.
- Loop conditions. Incrementing by decimal fractions may never hit a visually expected target exactly.
- Rounding surprises. Results such as round(2.675, 2) surprise users because the stored value is not exactly 2.675.
- Serialization and reporting. Exporting too many digits can reveal the underlying approximation and confuse stakeholders.
How to handle float comparisons correctly
One of the best habits in numerical programming is to stop using direct equality for values produced by prior calculations. Instead, compare within a tolerance. Python provides math.isclose() for this reason. You choose a relative tolerance, absolute tolerance, or both, depending on the scale of your numbers. This aligns your code with the real behavior of floating-point arithmetic rather than with an unrealistic expectation of decimal perfection.
For example, if two calculations differ by only 1e-15, they may be effectively equal for your application. In accounting, your tolerance might be zero at the cent level and you may prefer Decimal entirely. In physics, a small tolerance is often more realistic than exact equality.
When to use Decimal instead of float
Python’s decimal.Decimal type is designed for exact decimal arithmetic and user-controlled rounding. It is slower than binary float but far better for financial calculations and any workflow where decimal representation itself is part of the requirement. If your inputs are human-entered base 10 numbers and the output must preserve decimal expectations exactly, Decimal is often the right answer.
- Use float for speed, scientific workloads, statistics, graphics, and large numerical arrays.
- Use Decimal for money, invoices, taxes, compliance, and exact decimal rounding rules.
- Use Fraction when exact rational values are more important than performance.
Why formatting can hide the issue
Python intentionally displays floats in a way that balances readability and correctness. Most of the time, the printed value is the shortest decimal string that maps back to the same underlying float. This is helpful because it avoids scaring users with long strings of digits for everyday work. But it also means a beginner may think a float is exact when it is merely being displayed concisely.
To inspect the real stored value more closely, developers can print more digits, use repr(), inspect hexadecimal float forms, or look at the exact rational fraction with methods like as_integer_ratio(). These tools reveal that the issue is not random. It is structural and consistent.
Real-world statistics that matter for floating-point understanding
The following practical benchmarks are worth remembering because they explain most day-to-day float behavior in Python:
| Statistic | Approximate value | Interpretation |
|---|---|---|
| Reliable decimal precision of binary64 | 15 to 17 digits | If you stay within this range, printed values usually round-trip safely. |
| Relative gap near 1.0 | 2.22e-16 | Tiny changes smaller than this may vanish at that scale. |
| Exact decimal fractions with denominator 2n | All such fractions | Examples like 0.5 and 0.125 are exact in binary. |
| Exact decimal fractions with denominator containing factor 5 | None unless reducible to 2n | That is why 0.1, 0.2, and 0.01 are inexact. |
Best practices for Python developers
- Do not expect decimal fractions like 0.1 or 0.01 to be exact as floats.
- Use math.isclose() rather than direct equality for computed floats.
- Round only for display, not as a universal fix for internal numeric logic.
- Use Decimal when exact decimal rules are part of the business requirement.
- Use integer smallest units where practical, such as cents instead of dollars.
- Document numeric assumptions in code, especially around tolerance and rounding.
- Test edge cases like repeated additions, large magnitudes, and values near zero.
Authoritative references
If you want deeper technical background, these academic resources are excellent starting points:
- University of Toronto: What Every Computer Scientist Should Know About Floating-Point Arithmetic
- ENS Lyon educational copy of Goldberg’s floating-point paper
- UC Berkeley materials by William Kahan on floating-point computation
Final takeaway
Python is not failing when it produces tiny float discrepancies. It is following the rules of binary floating-point arithmetic. The real lesson is to choose the right number type for the job. If you need speed and broad numeric range, float is usually the correct tool. If you need exact decimal behavior, use Decimal or integer-based accounting logic. Once you understand the distinction between representation and mathematics, float behavior stops looking mysterious and starts looking predictable.
The calculator above helps you see that difference in action. Try a few inputs, especially values with decimal denominators involving 5, and compare the binary floating-point result with the exact decimal style result. That contrast is the heart of why Python does not calculate many floats exactly.