[Numpy-discussion] Power domain (was Re: bug in oldnumeric.ma)

[Eric Firing]

Pierre GM wrote:
> On Friday 09 May 2008 17:13:02 Eric Firing wrote:
>> Anne Archibald wrote:
>>> 2008/5/9 Eric Firing <efiring at hawaii.edu>:
>>>>      md = make_mask((fb != fb.astype(int)) & (fa < 0), shrink=True)
>>> Unfortunately this isn't quite the right condition:
>>>
>>> In [18]: x = 2.**35; numpy.array([-1.])**x; numpy.array(x).astype(int)==x
>>> Out[18]: array([ 1.])
>>> Out[18]: False
>>>
>>> Switching to int64 seems to help:
> 
>> There may not be a perfect solution, but I suspect your suggestion to
>> use int64 is more than good enough to get things going for a 1.1
>> release.  The docstring could note the limitation.  If it is established
>> that the calculation will fail for a power outside some domain, then
>> such a domain check could be added to the mask.
> 
> Interestingly, I notice that MaskedArray misses a __pow__ method: it uses the 
> ndarray.__pow__ method instead, that may outputs NaNs. In other terms, I 
> gonna have to code MaskedArray.__pow__, following Eric' example, with int64 
> instead of int.
> But, why don't we compare:
> abs(np.array(b).astype(int)-b).max()<np.finfo(float).precision
> instead ? At which point will b be considered sufficiently close to an integer 
> that x**b won't return NaN ?

I don't think the .max() part of that is right; the test needs to be 
element-wise, and turned into a mask.

It is also not clear to me that the test would actually catch all the 
cases where x**b would return NaN.

It seems like some strategic re-thinking may be needed in the long run, 
if not immediately.  There is a wide range of combinations of arguments 
that will trigger invalid results, whether Inf or NaN.  The only way to 
trap and mask all of these is to use masked_invalid after the 
calculation, and this only works if the user has not disabled nan 
output.  I have not checked recently, but based on earlier strategy 
discussions, I suspect that numpy.ma is already strongly depending on 
the availability of nan and inf output to prevent exceptions being 
raised upon invalid calculations.  Maybe this should simply be 
considered a requirement for the use of ma.

The point of my original suggestion was that it would make power work as 
a user might reasonably expect under sane conditions that are likely to 
arise in practice.  Under extreme conditions, it would leave unmasked 
nans or infs, or would raise an exception if that were the specified 
handling mode for invalid calculations.

Eric