Take the 2-minute tour ×

I've typed this into python shell:

>>> 0.1*0.1

I expected that 0.1*0.1 is not 0.01, because I know that 0.1 in base 10 is periodic in base 2.

>>> len(str(0.1*0.1))

I expected to get 20 as I've seen 20 characters above. Why do I get 4?

>>> str(0.1*0.1)

Ok, this explains why I len gives me 4, but why does str return '0.01'?

>>> repr(0.1*0.1)

Why does str round but repr not? (I have read this answer, but I would like to know how they have decided when str rounds a float and when it doesn't)

>>> str(0.01) == str(0.0100000000001)
>>> str(0.01) == str(0.01000000000001)

So it seems to be a problem with the accuracy of floats. I thought Python would use IEEE 754 single precicion floats. So I've checked it like this:

#include <stdint.h>
#include <stdio.h> // printf

union myUnion {
    uint32_t i; // unsigned integer 32-bit type (on every machine)
    float f;    // a type you want to play with

int main() {
    union myUnion testVar;
    testVar.f = 0.01000000000001f;
    printf("%f\n", testVar.f);

    testVar.f = 0.01000000000000002f;
    printf("%f\n", testVar.f);

    testVar.f = 0.01f*0.01f;
    printf("%f\n", testVar.f);

I got:


Python gives me:

>>> 0.01000000000001
>>> 0.01000000000000002
>>> 0.01*0.01

Why does Python give me these results?

(I use Python 2.6.5. If you know of differences in the Python versions, I would also be interested in them.)

share|improve this question
not sure why the users deleted their answers, but indeed the behaviour is explained in tutorial –  SilentGhost Nov 12 '12 at 14:38
float('4.1') * 100 == 409.99999999999994 –  Hugo Apr 17 at 7:12

3 Answers 3

up vote 12 down vote accepted

The crucial requirement on repr is that it should round-trip; that is, eval(repr(f)) == f should give True in all cases.

In Python 2.x (before 2.7) repr works by doing a printf with format %.17g and discarding trailing zeroes. This is guaranteed correct (for 64-bit floats) by IEEE-754. Since 2.7 and 3.1, Python uses a more intelligent algorithm that can find shorter representations in some cases where %.17g gives unnecessary non-zero terminal digits or terminal nines. See What's new in 3.1? and issue 1580.

Even under Python 2.7, repr(0.1 * 0.1) gives "0.010000000000000002". This is because 0.1 * 0.1 == 0.01 is False under IEEE-754 parsing and arithmetic; that is, the nearest 64-bit floating-point value to 0.1, when multiplied by itself, yields a 64-bit floating-point value that is not the nearest 64-bit floating-point value to 0.01:

>>> 0.1.hex()
>>> (0.1 * 0.1).hex()
>>> 0.01.hex()
                 ^ 1 ulp difference

The difference between repr and str (pre-2.7/3.1) is that str formats with 12 decimal places as opposed to 17, which is non-round-trippable but produces more readable results in many cases.

share|improve this answer
+1. And in Python >= 3.2, the difference between repr and str for floats is gone entirely. (And about time, too :-) –  Mark Dickinson Nov 12 '12 at 18:20

I can confirm your behaviour

ActivePython (ActiveState Software Inc.) based on
Python 2.6.4 (r264:75706, Jan 22 2010, 17:24:21) [MSC v.1500 64 bit (AMD64)] on win32
>>> repr(0.1)
>>> repr(0.01)

Now, the docs claim that in Python <2.7


This is a slight simplification.

Note that this is all to do with the string formatting code -- in memory, all Python floats are just stored as C++ doubles, so there is never going to be a difference between them.

Also, it's kind of unpleasant to work with the full-length string for a float even if you know that there's a better one. Indeed, in modern Pythons a new algorithm is used for float formatting, that picks the shortest representation in a smart way.

I spent a while looking this up in the source code, so I'll include the details here in case you're interested. You can skip this section.

In floatobject.c, we see

static PyObject *
float_repr(PyFloatObject *v)
    char buf[100];
    format_float(buf, sizeof(buf), v, PREC_REPR);

    return PyString_FromString(buf);

which leads us to look at format_float. Omitting the NaN/inf special cases, it is:

format_float(char *buf, size_t buflen, PyFloatObject *v, int precision)
    register char *cp;
    char format[32];
    int i;

    /* Subroutine for float_repr and float_print.
       We want float numbers to be recognizable as such,
       i.e., they should contain a decimal point or an exponent.
       However, %g may print the number as an integer;
       in such cases, we append ".0" to the string. */

    PyOS_snprintf(format, 32, "%%.%ig", precision);
    PyOS_ascii_formatd(buf, buflen, format, v->ob_fval);
    cp = buf;
    if (*cp == '-')
    for (; *cp != '\0'; cp++) {
        /* Any non-digit means it's not an integer;
           this takes care of NAN and INF as well. */
        if (!isdigit(Py_CHARMASK(*cp)))
    if (*cp == '\0') {
        *cp++ = '.';
        *cp++ = '0';
        *cp++ = '\0';

    <some NaN/inf stuff>

We can see that

So this first initialises some variables and checks that v is a well-formed float. It then prepares a format string:


Now PREC_REPR is defined elsewhere in floatobject.c as 17, so this computes to "%.17g". Now we call


With the end of the tunnel in sight, we look up PyOS_ascii_formatd and discover that it uses snprintf internally.

share|improve this answer
I agree that the claim in the What's New doc for Python is a simplification of the old behavior. Perhaps a better description can be found in the enhancement request that lead to the change: "The current float repr() always calculates the 17 first digits of the decimal representation of a float, and displays all of them (discarding trailing zeros)." –  Steven Rumbalski Nov 12 '12 at 15:17
Here's the link for 2.6.5 PyOS_ascii_formatd and ensure_minimum_exponent_length, though I don't know which platforms require the latter to conform with C99. –  eryksun Nov 13 '12 at 16:45

from python tutorial:

In versions prior to Python 2.7 and Python 3.1, Python rounded this value to 17 significant digits, giving ‘0.10000000000000001’. In current versions, Python displays a value based on the shortest decimal fraction that rounds correctly back to the true binary value, resulting simply in ‘0.1’.

share|improve this answer

Your Answer


