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

[David Mertz]

For similar reasons, I'd like an iInf too, FWIW.  It's good for an overflow
value, although it's hard to get there in Python ints (would
'NaNAwareInt(1)/0' be an exception or iInf?).  Bonus points for anyone who
knows the actual maximum size of Python ints :-).

However, the main use I'd have for iInf is simply as a starting value in a
minimization loop.  E.g.

minimum = NaNAwareInt('inf')
for i in the_data:
    minimum = min(i, minimum)

    other_stuff(i, minimum, a, b, c)


I've written that code a fair number of times; usually I just pick a
placeholder value that is "absurdly large relative to my domain", but a
clean infinity would be slightly better.  E.g. 'minimum = 10**100'.

On Sun, Sep 30, 2018 at 9:55 AM David Mertz <mertz at gnosis.cx> wrote:

> 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/
>>
>

-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180930/dc389034/attachment-0001.html>