[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