On 12/29/19 5:41 PM, Chris Angelico wrote:
On Mon, Dec 30, 2019 at 9:01 AM Richard Damon <rich...@damon-family.org> wrote:
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:
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?
Be careful: This kind of logic and intuition doesn't always hold true
even for things that we actually DO call numbers.
The first and forth test are reasonable tests for a real number
(expressed as a float).
There's nothing about "expressed as a float" in the first test; it
basically just uses the definition of "real number line" and "complex
plane" to define them. Actually performing the test is not exactly
practical, but it's valid. I don't know what you mean by the fourth
test being a test for a real number.
When using the 'usual properties of numbers' we needed to condition our
testing based on the limited precision of the float system, these usual
properties are things like a + b = b + a, a + b - b = a, (a + b) + c = a
+ (b + c), and the like. In all of these, the equality may not be exact,
but should only be tested within the precision of the floating point
system, which also means that using extreme differences in magnitude can
cause a total loss of precision, but that is all explainable by the
limited precision (as opposed to some strangeness in operation). There
is a large set of operations that we consider 'normal' to perform on
normal real numbers, and the floating point values that fall in the
finite number range do well at these, when you consider limits of
precision and range.
Yes, the first test isn't something that the computer is going to be
able to answer, but actually IS a very simple answer for the
programmer/analyst to answer by inspection. All the finite numbers
naturally meet it. The infinities meet it if we consider the Extended
Real Number Line (or if not, we see that they are NOT numbers, and for
the 'usual properties of numbers', the infinities don't meet as well as
normal numbers, so them being an edge case of being a number makes
sense). NaNs clearly fail this test (unless you want to show me how it
does). I don't see what is so impractical about that decision.
The second does limit itself to positive reals, but is otherwise a
reasonable test of something being numberish.
Have you ever successfully measured the length of a piece of string as
being precisely pi inches? Does that mean that pi is not a positive
real number?
Again, pure theory getting in the way for practicality. First 'Pi' is
not a possible floating point value, so we don't need to make a string
of Pi inches (but I can make one by wrapping it around a 1" diameter
dowel). Second, the test again is really a mental exercise to make
numbers something 'real' to the mind, so is really a thought experiment.
One issue with this with double precision floating point numbers is that
they are more precise than most physical things we can practically
measure, which sort of says they are good enough of an approximation for
most things.
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.
No, the "unsigned" type in most languages is a finite subset of
unsigned integers. To be fair, a 64-bit unsigned number is going to
include every number of spoons you'll ever see on any table, but that
doesn't equate it to the naturals. Also, zero creates a lot of strange
paradoxes. There are zero spoons on this table, AND there are zero
forks AND zero knives. Furthermore, there are zero woolly mammoths,
zero cans of Heinz Baked Beans, and zero chunks of red Kryptonite. How
can you count the number of Infinite Improbability Drives sitting on
the table, if you don't even know what an Infinite Improbability Drive
looks like? Intuition simply can't answer all of these questions. You
have to start mathematically or by performing operations on numbers
("if I have three spoons and I remove one, I have 3-1 == 2 two
spoons"), at which point you are taking a completely different
approach.
But that is a precision/range limit, which is part of the approximation.
Also the test is to map from the computer value to the mathematical, not
can all mathematical map to the computer. We acknowledge that the
computer model is finite, and thus there is a range limit .
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.
But since they are an approximation, the rules for reals do not hold.
For instance, addition of two positive real numbers always results in
another real number that is larger than each of the originals. Not so
for floats. (Although the (infinite) sum of every power of two can be
shown to be -1, so take of that what you will.)
The rules for the Reals DO hold WITHIN the approximation. This again is
practical beating purity.
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 equally valid question also remains: what in the real numbers does
float("inf") represent? That equally isn't a number, it is a value. It
is used to represent things that aren't numerical answers.
inf is a member of the Extended Real Numbers in mathematics. Yes, if you
are looking at the rules of regular Real Numbers, you need to exclude
the values of the infinities as being 'a number', and that is
acknowledged by the standard. If you are willing to adjust the rules you
expect to those under the Extended Real Numbers, then you can consider
them as numbers. I have no problem with the fact that the infinities are
in many respects not numbers but in others they can be.
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.
Also true of infinity. Are you going to object to that?
Floats are NOT pure mathematical concepts of numbers. They are a
disgustingly practical approximation to them, with many compromises
and many unintuitive behaviours, but incredibly useful ones.
And I suppose if you aren't willing to deal with them as APPROXIMATIONS,
then you need to not use computers for most things. I suppose you could
use symbolic mathematics packages, which never have numbers as anything
other that exact values (and thus sqrt(2) stays as sqrt(2) and not
1.414....). When you do accept them as approximations, you can't demand
from them what isn't in the approximation. Floats were NEVER said to be
an exact representation of the mathematical concepts. It is people who
ignore the difference, and the effect of the approximations, that get
themselves into trouble. Perhaps that is part of the natural education
of a programmer, that they learn that computers are practical devices,
not theoretical ones. Maybe that is why 'Programming' falls in the
domain of Engineering instead of the Sciences.
ChrisA
--
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/OEX4C4ZHTKP2PESTBDOQC5MXDFZOABAA/
Code of Conduct: http://python.org/psf/codeofconduct/
