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 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@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/