[Numpy-discussion] Power domain (was Re: bug in oldnumeric.ma)
Fri May 9 17:45:33 CDT 2008
Pierre GM wrote:
> On Friday 09 May 2008 17:13:02 Eric Firing wrote:
>> Anne Archibald wrote:
>>> 2008/5/9 Eric Firing <firstname.lastname@example.org>:
>>>> md = make_mask((fb != fb.astype(int)) & (fa < 0), shrink=True)
>>> Unfortunately this isn't quite the right condition:
>>> In : x = 2.**35; numpy.array([-1.])**x; numpy.array(x).astype(int)==x
>>> Out: array([ 1.])
>>> Out: 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:
> 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.
More information about the Numpy-discussion