[Numpy-discussion] 2 bugs related to isinf and isfinite generate crazy warnings
Wed Jun 2 23:02:08 CDT 2010
On 06/02/2010 05:00 PM, David wrote:
> On 06/03/2010 10:11 AM, Eric Firing wrote:
>> On some systems--but evidently not for most numpy users, or there would
>> have been a steady stream of screams--the appearance of np.inf in any
>> call to np.isfinite or np.isinf yields this:
>> In :import numpy as np
>> In :np.isinf(np.inf)
>> Warning: invalid value encountered in isinf
>> This generates streams of warnings if np.isinf or np.isfinite is applied
>> to an array with many inf values.
>> The problem is a combination of two bugs:
>> 1) When building with setup.py, but perhaps not with scons (which I
>> haven't tried yet), NPY_HAVE_DECL_ISFINITE and friends are never
>> defined, even though they should be--this is all on ubuntu 10.4, in my
>> case, and isfinite and isinf most definitely are in math.h. It looks to
>> me like the only mechanism for defining these is in SConstruct.
> Actually, there is a bug in setup.py to detect those for python>= 2.6,
> I have fixed this.
>> 2) So, with no access to the built-in isinf etc., npy_math.h falls back
>> on the compact but slow macros that replace the much nicer ones that
>> were in numpy a year or so ago.
> Which one are you thinking about: the ones using fpclassify ? Could you
> show the code where the current version is slower ?
OK, my memory was off as usual. What I was remembering was actually this:
So the macro versions were in mpl, and derived from numarray, but
apparently were never in numpy.
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.
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.
I do know (or think...) that two or three years ago I timed numpy.isnan
and numpy.isfinite, and found that the latter was notably faster than
the former, consistent with what I would have expected if the
implementation was as in MPL_isnan.h. 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.
> NumPy-Discussion mailing list
More information about the NumPy-Discussion