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.
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.
-Travis
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion