[Numpy-discussion] 2 bugs related to isinf and isfinite generate crazy warnings
Wed Jun 2 23:16:04 CDT 2010
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.
> 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.
More information about the NumPy-Discussion