Pierre GM wrote: > On Friday 09 May 2008 17:13:02 Eric Firing wrote: >> Anne Archibald wrote: >>> 2008/5/9 Eric Firing <[EMAIL PROTECTED]>: >>>> 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 _______________________________________________ Numpy-discussion mailing list [email protected] http://projects.scipy.org/mailman/listinfo/numpy-discussion
