[Python-ideas] Python Numbers as Human Concept Decimal System

[Andrew Barnert]

From: Ron Adam <ron3200 at gmail.com>

Sent: Saturday, March 8, 2014 10:10 AM


> On 03/08/2014 11:43 AM, Chris Angelico wrote:
>>  On Sun, Mar 9, 2014 at 4:35 AM, Ron Adam<ron3200 at gmail.com>  wrote:
> 
>>>  >A repr should give the exact value its object if it's suppose 
> to be a
>>>  >machine readable version of it.  (As numbers __repr__ should do.)
> 
> 
>>  As I understand it, float.__repr__ does indeed give the exact value,
>>  in terms of reconstructing the float.
> 
> What I'm thinking about is...
> 
> If floats repr is changed to disregard exta digits, will this still be 
> true?  How is float to know what exta digits should be disregarded?


No one is suggesting such a change, and it would be shot down if anyone did.

The old repr and str for float used to discard (different numbers of) digits. The current version does not. Instead, if picks the shortest string that would evaluate back to the same value if passed to the float constructor (or to eval).

So, repr(0.100000000000000006) == '0.1', not because repr is discarding digits, but because 0.100000000000000006 == 0.1 (because the closest binary IEEE double value to both is 0.1000000000000000055511151231257827021181583404541015625).

>>  There are infinitely many float literals that will result in the exact

>>  same bit pattern, so any of them is valid for repr(n) to return.
> 
> When are float literals actually converted with floats.  It seems to me, 
> that the decimal functions can be used to get the closest one.  Then they 
> will be consistent with each other. (if that isn't already being done.)


Float literals are converted to floats at compile time. When the compiler sees 0.1, or 0.100000000000000006, it works out the nearest IEEE double to that literal and stores that double.

So, by the time any Decimal function sees the float, there's no way to tell whether it was constructed from the literal 0.1, the literal 0.100000000000000006, or some long chain of transcendental functions whose result happened to have a result within 1 ulp of 0.1.

The current behavior guarantees that, for any float, float(Decimal(f)) == float(repr(Decimal(f))) == f. Guido's proposal would preserve that guarantee. If that's all you care about, nothing would change. Guido is just suggesting that, instead of using the middle Decimal from the infinite set of Decimals that would make that true, we use the shortest one.