Home Original page

Precision issue

Terry Reedy tjreedy at udel.edu
Fri Oct 10 13:26:27 EDT 2003 
"Stephen Horne" <$$$$$$$$$$$$$$$$$@$$$$$$$$$$$$$$$$$$$$.co.uk> wrote
in message news:odcdovgdf7mib8emi9g7qhrnjv53r9bmcs at 4ax.com...
> My impression has always been that 'repr' gives a representation of
> the value which, when parsed (using 'eval', for instance),
> reconstructs the original value. In this respect, '3.4' is just as
> good as '3.3999999999'.

Not just *a* representation, but the *most accurate*.  '3.4' is (as
you show below) less accurate, or that would have been chosen instead.
The internal value is what it is, regardless of whether it results
from this literal or that literal or from calculation.  Why the
opposition to having a way to get the closest 17-digit decimal
approximation?

> IIRC, a binary float can always be given a precise decimal
> representation - it simply tends to take a lot of digits. The fact
> that repr doesn't give a perfect representation of the binary float
> value suggests that it is not 'for discovering, as precisely as
> possible, the actual value'.

It is for decimally representing, as precisely as possible *with 17
digits*, the actual value.  I presume that 17 in the minimum necessary
to guarantee a unique, back-convertible prepresentation for every
float.

> Out of curiosity, I wrote the function at the bottem of this post to
> convert a Python float into two string representations - a rational
> and a decimal - both having precisely the same value as the float. I
> got the following results starting with 3.4...
>
> Rational : 7656119366529843/2251799813685248
> Decimal  : 3.399999999999999911182158029987476766109466552734375

If this is correct, then rounding up to 3.4 would be like rounding .11
to 1 instead of 0.

Terry J. Reedy
More information about the Python-list mailing list