On 12/29/19 4:30 PM, Chris Angelico wrote:
On Mon, Dec 30, 2019 at 5:48 AM Steven D'Aprano <st...@pearwood.info> wrote:
On Sat, Dec 28, 2019 at 09:20:49PM -0800, Brendan Barnwell wrote:
The things that
computers work with are floats, and NaN is a float, so in any relevant
sense it is a number; it is an instance of a numerical type.
You seem to be assuming that `x is an instance of type float (or
Decimal)` implies `x is a number`. That seems reasonable in the general
case (e.g. we would rightly expect that every instance of a type "Car"
represents an actual car) but in the specific case of floats (and
Decimal) the assumption breaks down.
The writers of the IEEE-754 standard didn't choose the name "Not A
Number" at random. The name tells you their intention: NANs represent
values or quantities which are not numbers. It seems particularly
perverse to insist that even when a value is explicitly described as Not
A Number, it's actually a number.
Especially since it fails quite a few commonsense tests for whether or
not something is a number:
- Do NANs appear anywhere on the real number line or complex plane?
- Can we successfully measure (say) the length of a piece of string
and get a result of NAN inches?
- Can we successfully count the number of (say) spoons on a table
and get a result of NAN?
- Do NANs obey, even approximately, the usual properties of numbers?
The answer in all four cases is No. If something doesn't quack like a
duck, doesn't swim like a duck, and doesn't walk like a duck, and is
explicitly called Not A Duck, would we insist that it's actually a duck?
Be careful: This kind of logic and intuition doesn't always hold true
even for things that we actually DO call numbers. The counting numbers
follow logical intuition, but you can't count the number of spoons on
a table and get a result of "negative five" or "the square root of
two" or "3 + 2i". Extending the concept of "numbers" to include zero,
negatives, laterals (complexes), etc is something that various
different cultures had to come to terms with. (The ancient Romans, for
instance, didn't have any way to represent zero - which means it was
extremely difficult for their C programs to indicate successful
termination. This led directly to the empire's downfall.)
More useful would be to look at the useful operations and invariants
that can be maintained, but that doesn't work too well for finite
subsets of numbers. Very few operations are closed for, say, "sixteen
bit integers". Nor for "rational numbers with denominators that are
powers of two between -1024 and 1024". There is no easy way to define
"number" in a way that is both mathematically pure AND practically
useful.
ChrisA
The first and forth test are reasonable tests for a real number
(expressed as a float).
The second does limit itself to positive reals, but is otherwise a
reasonable test of something being numberish.
The third is more a test of the Natural Numbers (or the Non-Negative
Whole Numbers), which would map to the 'unsigned' type in some language,
or a part of the range of integers.
Since Practicality trumps Purity, we don't need (or really want) a
mathematically pure definition, and since it is admitted that the
floating point representation is just an approximation of the Real
Numbers, a pure definition probably doesn't work anyway (Pure
Mathematics doesn't deal with approximations well).
We have a mathematic definition of the ideal Real Numbers, using any of
a number of ways to build it, and then we say that floats are an
approximation to that system.
The question remains, what in the Real Numbers do you propose that the
NaN IEEE value approximate? It really doesn't, so isn't a 'number', but
just a value, used to represent things that aren't numerical answers
when a operation needs to generate SOME answer.
The alternative to having NaN values in the representation would be for
the operations that currently generate it to fault out and either kill
the program or at least generate an exception.
--
Richard Damon
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/GMVLTJN5V3JFY2QP5FG5JIZQGW5VVY3O/
Code of Conduct: http://python.org/psf/codeofconduct/
