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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com