[Numpy-discussion] numpy.ma bug
pfdubois at gmail.com
Fri Mar 10 07:07:12 CST 2006
It was a design decision: if an automatic conversion of a masked array to a
numeric one is attempted, and there actually are masked values, it is
logical to either:
a. raise an exception, because there is no equivalent numeric array, or;
b. fill the masked value with the fill value
(b) suffers from a problem: the default fill value might not be appropriate
for the use that is about to occur.
My original conclusion was that it was better to choose (a) to force the
user to explicitly do the conversion with x.fill(value) and pass THAT to
whatever was going to consume it. I don't think I've changed my mind.
On 10 Mar 2006 02:32:19 -0800, Travis Oliphant <oliphant.travis at ieee.org>
> Sasha wrote:
> > I would say it is an ma bug, but don't know how to fix it properly
> > without changing numpy scalar arithmetic to call an enhanced version
> > of __array__ and pass context in.
> I think it was an array scalar bug. I've fixed it by always calling the
> ufunc (which handles conversions to and from other objects better than
> the array scalars were doing in the generic arithmetic code).
> The result is shorter code and symmetric handling of the
> <array_scalar>*<masked array> vs. <masked array> * <array_scalar> case.
> I also changed the error to a warning for backward compatibility.
> Calling __array__() on a masked array should succeed and we will assume
> the user knows what they are doing.
> This SF.Net email is sponsored by xPML, a groundbreaking scripting
> that extends applications into web and mobile media. Attend the live
> and join the prime developer group breaking into this new coding
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Numpy-discussion