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

[Eric Firing]

On 06/02/2010 05:00 PM, David wrote:
> On 06/03/2010 10:11 AM, Eric Firing wrote:
>> http://www.mail-archive.com/numpy-discussion@scipy.org/msg23912.html
>>
>> 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 [1]:import numpy as np
>>
>> In [2]:np.isinf(np.inf)
>> Warning: invalid value encountered in isinf
>> Out[2]:True
>>
>>
>> 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.

David,

Thank you.

>
>>
>> 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:

http://currents.soest.hawaii.edu/hgstage/hgwebdir.cgi/mpl_hg/file/4ab6f2159bea/matplotlib/src/MPL_isnan.h

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.

Eric


>
> cheers,
>
> David
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion