<div dir="auto"><div>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?<br><br>I suspect a NaNAwareInt subclass is the easiest way to get there, but I'm agnostic on that detail.</div><div dir="auto"><br></div><div dir="auto">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.<br><br><br><div class="gmail_quote" dir="auto"><div dir="ltr">On Sun, Sep 30, 2018, 9:42 AM Steve Barnes <<a href="mailto:gadgetsteve@live.co.uk">gadgetsteve@live.co.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 30/09/2018 13:55, Steven D'Aprano wrote:<br>
> On Sun, Sep 30, 2018 at 12:09:45PM +0300, Serhiy Storchaka wrote:<br>
>> 30.09.18 04:07, Steven D'Aprano пише:<br>
>>> Telling people that they don't understand their own code when you don't<br>
>>> know their code is not very productive.<br>
>><br>
>> I can't tell him what he should do with his (not working) code, but it<br>
>> doesn't look like a good justification for changes in the Python core.<br>
> <br>
> You don't know that his code is not working. For all you know, Steve has<br>
> working code that works around the lack of an int NAN in some other,<br>
> more clumsy, less elegant, ugly and slow way.<br>
> <br>
> NANs are useful for when you don't want a calculation to halt on certain<br>
> errors, or on missing data. That ability of a NAN to propogate through<br>
> the calculation instead of halting can be useful when your data are<br>
> ints, not just floats or Decimals.<br>
> <br>
> Earlier, I suggested that this proposal would probably be best done as a<br>
> subclass of int. It certainly should be prototyped as a subclass before<br>
> we consider making a builtin int NAN. Since Steve has already agreed to<br>
> work on that first, I think any further discussion would be pointless<br>
> until he comes back to us. He may decide that a subclass solves his<br>
> problem and no longer want a builtin int NAN.<br>
> <br>
> <br>
I have had (over the years) a lot of working code with lots of checks in <br>
and a huge number of paths through due to the lack of such of iNaN, or <br>
something to return for "that didn't work", floats & complex have NaN, <br>
strings have empty string list and sets can be empty but there is no <br>
such option for integers. Hence the suggestion. I am hartened that the <br>
authors of the Decimal library also felt the need for NaN (as well as <br>
INF & -INF).<br>
<br>
I am roughing out such a class and some test cases which will hopefully <br>
include some cases where the hoped for advantages can be realised.<br>
<br>
My thinking on bitwise operations is to do the same as arithmetic <br>
operations, i.e. (anything op iNaN) = iNaN and likewise for shift <br>
operations.<br>
-- <br>
Steve (Gadget) Barnes<br>
Any opinions in this message are my personal opinions and do not reflect <br>
those of my employer.<br>
<br>
---<br>
This email has been checked for viruses by AVG.<br>
<a href="https://www.avg.com" rel="noreferrer noreferrer" target="_blank">https://www.avg.com</a><br>
<br>
_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank" rel="noreferrer">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer noreferrer" target="_blank">http://python.org/psf/codeofconduct/</a><br>
</blockquote></div></div></div>