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

[David Mertz]

Notwithstanding my observation of one case where 'nan <op> float' doesn't
stay a nan, I definitely want something like iNaN. Btw are there other
operations on NaN's do not produce NaN's?

I suspect a NaNAwareInt subclass is the easiest way to get there, but I'm
agnostic on that detail.

For the very same reasons that other numeric types benefit from NaN, ints
would also. I.e. I want to do a series of numeric operations on a bunch of
input numbers, and it's less cumbersome to check if we went to NaN-land at
the end than it is to try/except around every op.


On Sun, Sep 30, 2018, 9:42 AM Steve Barnes <gadgetsteve at live.co.uk> wrote:

>
>
> On 30/09/2018 13:55, Steven D'Aprano wrote:
> > On Sun, Sep 30, 2018 at 12:09:45PM +0300, Serhiy Storchaka wrote:
> >> 30.09.18 04:07, Steven D'Aprano пише:
> >>> Telling people that they don't understand their own code when you don't
> >>> know their code is not very productive.
> >>
> >> I can't tell him what he should do with his (not working) code, but it
> >> doesn't look like a good justification for changes in the Python core.
> >
> > You don't know that his code is not working. For all you know, Steve has
> > working code that works around the lack of an int NAN in some other,
> > more clumsy, less elegant, ugly and slow way.
> >
> > NANs are useful for when you don't want a calculation to halt on certain
> > errors, or on missing data. That ability of a NAN to propogate through
> > the calculation instead of halting can be useful when your data are
> > ints, not just floats or Decimals.
> >
> > Earlier, I suggested that this proposal would probably be best done as a
> > subclass of int. It certainly should be prototyped as a subclass before
> > we consider making a builtin int NAN. Since Steve has already agreed to
> > work on that first, I think any further discussion would be pointless
> > until he comes back to us. He may decide that a subclass solves his
> > problem and no longer want a builtin int NAN.
> >
> >
> I have had (over the years) a lot of working code with lots of checks in
> and a huge number of paths through due to the lack of such of iNaN, or
> something to return for "that didn't work", floats & complex have NaN,
> strings have empty string list and sets can be empty but there is no
> such option for integers. Hence the suggestion. I am hartened that the
> authors of the Decimal library also felt the need for NaN (as well as
> INF & -INF).
>
> I am roughing out such a class and some test cases which will hopefully
> include some cases where the hoped for advantages can be realised.
>
> My thinking on bitwise operations is to do the same as arithmetic
> operations, i.e. (anything op iNaN) = iNaN and likewise for shift
> operations.
> --
> 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
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180930/6eae97e4/attachment.html>