On 28/04/2011 18:26, Steven D'Aprano wrote:
Of course, these are inevitable consequences of floating-point representation. Inevitable in just about *any* language.Rob Cliffe wrote:To me the idea of non-reflexive equality (an object not being equal to itself) is abhorrent. Nothing is more likely to put off new Python users if they happen to run into it.I believe that's a gross exaggeration. In any case, that's just your opinion, and Python is hardly the only language that supports (at least partially) NANs.Besides, floats have all sorts of unintuitive properties that go against properties of real numbers, and new users manage to cope.With floats, even ignoring NANs, you can't assume: a*(b+c) == a*b + a*c a+b+c = c+b+a 1.0/x*x = 1 x+y-x = y x+1 > xor many other properties of real numbers. In real code, the lack of reflexivity for NANs is just not that important. You can program for *years* without once accidentally stumbling over one, whereas you can't do the simplest floating point calculation without stubbing your toes on things like this:>>> 1.0/10 0.10000000000000001
I am not arguing against the use of NANs. Or even against different NANs not being equal to each other. What I was arguing about was the behaviour of Python objects that represent NANs, specifically in allowingThe fact is, NANs are useful. Less useful in Python, which goes out of the way to avoid generating them (a pity, in my opinion), but still useful.
x == x
to be False, something which is *not* inevitable but a choice of
language design or usage.
Rob Cliffe _______________________________________________ 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
