Mark Shannon wrote:
Steven D'Aprano wrote:
Mark Shannon wrote:
Related to the discussion on "Not a Number" can I point out a few
things that have not be explicitly addressed so far.
The IEEE standard is about hardware and bit patterns, rather than
types and values so may not be entirely appropriate for high-level
language
like Python.
I would argue that the implementation of NANs is irrelevant. If NANs
are useful in hardware floats -- and I think they are -- then they're
just as equally useful as objects, or as strings in languages like
REXX or Hypertalk where all data is stored as strings, or as quantum
wave functions in some future quantum computer.
So,
Indeed, so its OK if type(NaN) != type(0.0) ?
Sure. But that just adds complexity without actually resolving anything.
Fundamentally, the problem is that some containers bypass equality
tests for identity tests. There may be good reasons for that shortcut,
but it leads to problems with *any* object that does not define
equality to be reflexive, not just NANs.
[...]
Just because you can do that, doesn't mean you should.
Equality should be reflexive, without that fundamental assumption many
non-numeric algorithms fall apart.
So what? If I have a need for non-reflexivity in my application, why
should I care that some other algorithm, which I'm not using, will fail?
Python supports non-reflexivity. If I take advantage of that feature, I
can't guarantee that *other objects* will be smart enough to understand
this. This is no different from any other property of my objects.
The default comparisons will then work as expected for collections.
(No doubt, making NaN a new class will cause a whole new set of
problems)
As pointed out by Meyer:
NaN == NaN is False
is no more logical than
NaN != NaN is False
I don't agree with this argument. I think Meyer is completely mistaken
there. The question of NAN equality is that of a vacuous truth, quite
similar to the Present King of France:
http://en.wikipedia.org/wiki/Present_King_of_France
[...]
The problem with this argument is the present King of France does not
exist, whereas NaN (as a Python object) does exist.
NANs (as Python objects) exist in the same way as the present King of
France exists as words. It's an implementation detail: we can't talk
about the non-existent present King of France without using words, and
we can't do calculations on non-existent/indeterminate values in Python
without objects.
Words can represent things that don't exist, and so can bit-patterns or
objects or any other symbol. We must be careful to avoid mistaking the
symbol (the NAN bit-pattern or object) for the thing (the result of
whatever calculation generated that NAN). The idea of equality we care
about is equality of what the symbol represents, not the symbol itself.
The meaning of "spam and eggs" should not differ according to the
typeface we write the words in. Likewise the number 42 should not differ
according to how the int object is laid out, or whether the bit-pattern
is little-endian or big-endian. What matters is the "thing" itself, 42,
not the symbol: it will still be 42 even if we decided to write it in
Roman numerals or base 13.
Likewise, what matters is the non-thingness of NANs, not the fact that
the symbol for them has an existence as an object or a bit-pattern.
--
Steven
_______________________________________________
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
