[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.
>
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
More information about the Python-ideas
mailing list