math.nroot [was Re: A brief question.]

[Steven D'Aprano]

Tom Anderson wrote about NaNs:

> > (Remember, a NaN is just an illusionary placeholder, not a number.)
> 
> If you think it's illusionary, i invite you to inspect the contents of 
> my variables - i have a real, live NaN trapped in one of them!

No you don't. You have a flag that says "This 
calculation failed" in your variable.

[snip]

> Yes. It may not be mathematically pure (although i argue that it is, in 
> fact, as long as you don't think of floats as being real numbers), it is 
> practical, and practicality beats purity.

But then:

>> But, apart from testing whether a float is a NaN, why would you ever 
>> want to do an equality test?
> 
> 
> By definition, never. Isn't that usage reason enough?

So, what you are saying is that you don't actually have 
a usage case for testing equality for NaNs.

Any floating point package that supports the IEEE 
standard should give you a test to see if a float 
represents a NaN. That's what you need. You certainly 
can't rely on "x == SOME_NAN" because there are 254 
different NaNs.

There is no sensible reason to test equality of NaNs. 
It is logically nonsense to say that one NaN is equal 
to another, as such a thing implies contradictions like 
-1==-2. If you support IEEE, you will have a test for 
NaNs, so you can detect them when you need to.

Problem solved.

> 
>> The only usage case I can think of is would be something like this:
>>
>> def isNaN(x):
>>    return x == SOME_KNOWN_NAN
>>
>> But that won't work, because there are lots of different NaNs. 254 of 
>> them, or twice that if you include signed NaNs (which you shouldn't, 
>> but you do have to allow for them in equality testing).
> 
> 
> Ah, well. There we have the question of whether python should implement 
> full-blown IEEE arithmetic. This is somewhat heretical, but i think it 
> shouldn't; i think it would be much better to adopt Java's noddy-IEEE 
> approach, where there's exactly one NaN (although with well-behaved 
> equality comparison). I realise this isn't going to happen, though.

Well-behaved equality comparison means that nan == nan 
returns false. Otherwise you have contradictions like this:

x = log(-1)  # one flavour of NaN
y = asin(2)  # a different flavour of NaN

log(-1) == asin(2)
sin(log(-1)) == 2
sin(NaN) == 2
NaN == 2

Contradiction.




[snip]

> I am utterly baffled. Three people so far have told me that 
> exponentiation has higher precedence than unary minus *in conventional 
> notation*. 

Yes.

> Are you really telling me that you think this expression:
> 
>   2
> -1
> 
> Evaluates to -1?

Of course it does. That's why mathematicians use

(-1)^n

for series where the sign of each term alternates, 
instead of -1^n which would just give -1, -1, -1, ...


-- 
Steven