[Python-3000] Reconsider repr(0.1) == '0.10000000000000001'

Terry Reedy tjreedy at udel.edu
Sun Dec 9 12:05:41 CET 2007


"Noam Raphael" <noamraph at gmail.com> wrote in message 
news:b348a0850712090033r61577b83hc8d8a324705ef0f7 at mail.gmail.com...
| My use case is data manipulation in the interactive shell -

When doing things other than add and subtract, one soon gets floats that 
are no longer such 'even' decimals, even if the input is.

| Many times I have float data.

| >>> height['Alice']
| 1.67

For parroting back low precision input, I sort of see your point, but you 
already knew your input values,

| Is much easier to understand than
|
| >>> height['Alice']
| 1.6699999999999999

so I do not see how there is a problem with understanding them.

Of course, in this case, you can get what you want with
>>> print height['Alice']
1.67

It seems your real problem is that repr() rather than str() is applied 
within collections.  (I am not sure exactly why but suspect there is a 
reason.)

| I think that the reason for the long representation is that it uses a
| simple algorithm that makes "eval(repr(f)) == f" always true.

A necessary condition for this is that every float have its own 
representation, so that f != g ==> repr(f) != repr(g).  I think this is a 
nice property.  You seem to agree.

|  However,
| why not use another, a bit more complex, algorithm, which will still
| preserve "eval(repr(f)) == f", but which will shorten the result when it 
can?

Do you have such an algorithm?  I have the impression that Tim Peters (or 
whoever) tried and gave up.  Note that 1.6700000000000001 converts to a 
different binary than 1.67 or 1.6699999999999999, and so cannot be rounded 
to 1.67 (and preserve the condition), no matter how much more 
'understandable' the latter is.  In other words, some numbers wiill round 
the way you expect but other will not.  This might end up being at least as 
confusing at the current situation.

| You see, it's not even that the current algorithm is exact

No, that would require even longer decimals.  I think it intends to gives 
the closest 17 digit number (plus exponent). 17 being enough to give unique 
representations.  (I do not know if this includes subnormalized floats.)

Terry Jan Reedy







More information about the Python-3000 mailing list