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

[Steve Barnes]

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.
> 
Thanks!

-- 
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.
https://www.avg.com