[Python-Dev] Caching float(0.0)

Nicko van Someren nicko at nicko.org
Tue Oct 3 17:45:16 CEST 2006


On 3 Oct 2006, at 15:10, Martin v. Löwis wrote:

> Nick Maclaren schrieb:
>> That was the point of a previous posting of mine in this thread :-(
>>
>> You shouldn't, despite what IEEE 754 says, at least if you are
>> allowing for either portability or numeric validation.
>>
>> There are a huge number of good reasons why IEEE 754 signed zeroes
>> fit extremely badly into any normal programming language and are
>> seriously incompatible with numeric validation, but Python adds more.
>> Is there any other type where there are two values that are required
>> to be different, but where both the hash is required to be zero and
>> both are required to evaluate to False in truth value context?
>
> Ah, you are proposing a semantic change, then: -0.0 will become
> unrepresentable, right?

It's only a semantic change on platforms that "happen to" use IEEE  
754 float representations, or some other representation that exposes  
the sign of zero.  The Python docs have for many years stated with  
regard to the float type: "All bets on their precision are off unless  
you happen to know the machine you are working with." and that "You  
are at the mercy of the underlying machine architecture...".  Not all  
floating point representations support sign of zero, though in the  
modern world it's true that the vast majority do.

It would be instructive to understand how much, if any, python code  
would break if we lost -0.0.  I'm do not believe that there is any  
reliable way for python code to tell the difference between all of  
the different types of IEEE 754 zeros and in the special case of -0.0  
the best test I can come up with is repr(n)[0]=='-'.  Is there an  
compelling case, to do with compatibility or otherwise, for exposing  
the sign of a zero?  It seems like a numerical anomaly to me.

	Nicko



More information about the Python-Dev mailing list