[Python-ideas] Suggestion: Extend integers to include iNaN
gadgetsteve at live.co.uk
Sat Sep 29 14:25:37 EDT 2018
On 29/09/2018 14:00, Steven D'Aprano wrote:
> On Sat, Sep 29, 2018 at 06:31:46AM +0000, Steve Barnes wrote:
>> One of the strengths of the IEEE float, (to set against its many
> Since I'm old enough to (just barely) remember the chaos and horror of
> numeric programming before IEEE-754, I find that comment rather
> I'm curious what you think those weaknesses are.
I am likewise old enough - the weaknesses that I am thinking of include:
- Variable precision
- Non-linearity around zero
- Common real world, (decimal), values being irrational, 0.1 anybody?
- In many cases being very limited range (then number of people who
get caught out on statistical calculations involving permutations).
>> is the presence of the magic value NaN. Not a Number, or
>> NaA, is especially useful in that it is a valid value in any
>> mathematical operation, (always returning NaN), or comparison, (always
>> returning False).
> Almost so. But the exceptions don't matter for this discussion.
Indeed, (and possibly those exceptions should be matched in many cases).
>> In functional programming this is especially useful as
>> it allows the chain to complete after an error while retaining the fact
>> that an error occurred, (as we got NaN).
> Not just functional programming.
True, functional programming was the most obvious to spring to mind but
in a lot of my code I need to return some value even in the case of an
exception so as to allow the system to carry on running.
>> I think that it should be relatively simple to extend the Python integer
>> class to have a NaN flag, possibly by having a bit length of 0, and have
>> it follow the same rules for the handling of floating point NaN, i.e.
>> any mathematical operation on an iNaN returns an iNaN and any comparison
>> with one returns False.
> Alas, a bit length of 0 is zero:
> py> (0).bit_length()
I still think that iNaN.bit_length() should return 0 but obviously that
would not be enough in itself to denote iNaN.
> I too have often wished that integers would include three special
> values, namely plus and minus infinity and a NAN. On the other hand,
> that would add some complexity to the type, and make them harder to
> learn and use. Perhaps it would be better to subclass int and put the
> special values in the subclass.
I thought of including pINF & nINF in the original email and then
decided to take on a single dragon at a time.
> A subclass could be written in Python, and would act as a good proof of
> concept, demonstrating the behaviour of iNAN. For example, what would
> you expect iNAN & 1 to return?
I am thinking of trying to put together an overload of integer with iNaN
overloads for all of the dunder operations as a proof of concept.
> Back in the 1990s, Apple Computers introduced their implementation of
> IEEE-754, called "SANE" (Standard Apple Numeric Environment). It
> included a 64-bit integer format "comp", which included a single NAN
> value (but no infinities), so there is definately prior art to having an
> integer iNAN value.
I had forgotten this.
> Likewise, R includes a special NA value, distinct from IEEE-754 NANs,
> which we could think of as something very vaguely like an integer NAN.
Not done enough R programming to have come across it.
Steve (Gadget) Barnes
Any opinions in this message are my personal opinions and do not reflect
those of my employer.
This email has been checked for viruses by AVG.
More information about the Python-ideas