[Numpy-discussion] 2 bugs related to isinf and isfinite generate crazy warnings

[David]

On 06/03/2010 01:02 PM, Eric Firing wrote:

>
> In any case, in MPL_isnan.h, isfinite is fast, because it involves only
> a single bitwise-and plus comparison; isnan and isinf are slower,
> because they involve about twice as much work.

Concerning speed, the problem is that it depends a lot on the 
compiler/architecture. When I timed some implementations of isnan, just 
changing from Pentium 4 to Pentium M with the exact same 
compiler/options gave mixed results. It also depends on the input - some 
methods are faster for finite numbers but slower for nan/inf, etc...

>
> Given that the present numpy isfinite macro is broken--it raises an fp
> error--there is not much point in talking about its performance.

Indeed :)

>
> What I don't know is whether there is some reason not to use the
> MPL_isnan.h macros as the backups in numpy, for platforms that do not
> have their own isnan, isfinite, and isinf.

The problem is that it is actually quite some work. Float and double are 
not so difficult (two cases to deal with for endianness), but long 
double is a huge PITA - we have already 5 different implementations to 
deal with, and we are missing some (linux PPC).

> Presumably, at that time my numpy
> build was using the system versions, and maybe they are implemented in a
> similar way.  Looking in /usr/include/bits/*.h, I gave up trying to
> figure out what the system macros really are doing.

You have to look into sysdeps/ directory inside glibc sources (on 
Linux). They use clever tricks to avoid branching, but when I 
benchmarked those, things like x != x where much faster on the computer 
I tested this on. Most likely very CPU dependent.

cheers,

David