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@ieee.org> wrote:
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