Is nan in (nan,) correct?

[Steven D'Aprano]

Rustom Mody wrote:

> On Friday, March 6, 2015 at 3:31:58 PM UTC+5:30, Chris Angelico wrote:
>> On Fri, Mar 6, 2015 at 8:50 PM, Rustom Mody  wrote:
>> > In a language like python with decent exceptions we do not need nans.
>> 
>> Not so. I could perhaps accept that we don't need signalling NaNs, as
>> they can be replaced with exceptions, but quiet NaNs are by definition
>> _not_ exceptions.
> 
> My impression (maybe I am wrong):
> "Catch an exception and ignore it" is a way of converting signalling to
> quiet With the added advantage of being able to tweak the specs of what
> happens when nan op normal to one's taste


I don't understand what you are trying to say.

Let's take a dirt-simple example:

def inverse(x):
    return 1.0/x

There's an exception there, waiting to bite. If I include inverse() in some
complex calculation:

def function(x, y):
    return atan2(inverse(3*x*y)+1, inverse(1 - x**2 + 3*x - 0.2)**3)

values = [function(1.5*x, y+2) for x, y in zip(xx, yy)]

and I just wish to skip over the failed calculations, I can't just "ignore"
exceptions:

# This doesn't work!
def inverse(x):
    try:
        return 1.0/x
    except ZeroDivisionError:
        pass


I have to return something that acts like a number but isn't a number.

Something which, once it enters a calculation, should propagate through it.
But not necessarily something which once it enters can never be removed! It
may be that some calculations can "cancel out" these "errors" (indeed, the
atan2 function is one of those -- it can return non-NANs from at least some
NAN arguments). So what should I return? It cannot be a number, but it has
to act like a number. Ideally, it should carry diagnostic information so I
can see what the failure was, for debugging, although I may not bother to
do so that information should at least be available for use.

I have just re-invented NANs.


-- 
Steven