On 12/29/19 5:41 PM, Chris Angelico wrote:
On 12/29/19 4:30 PM, Chris Angelico wrote:
On Mon, Dec 30, 2019 at 5:48 AM Steven D'Aprano <steve@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
On Mon, Dec 30, 2019 at 9:01 AM Richard Damon <Richard@damon-family.org> wrote: 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?
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
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. 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