[Python-ideas] Suggestion: Extend integers to include iNaN

Steve Barnes 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
>> weaknesses),
> o_O
> Since I'm old enough to (just barely) remember the chaos and horror of
> numeric programming before IEEE-754, I find that comment rather
> shocking.
> 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()
> 0
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.
> https://stat.ethz.ch/R-manual/R-devel/library/base/html/NA.html
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 mailing list