You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Operation on masked_array changes fill_value #3762
I first raised this issue on stackoverflow (see link on the bottom)
Seems like the new masked_array should inherit the fill_value from the two masked_arrays being summed?
Can someone explain to me this behavior of a numpy masked_array? It seems to change the fill_value after applying the sum operation, which is confusing if you intend to use the filled result.
It looks like most (all) of the reductions operations do not preserve the fill_value attribute:
import numpy as np
a = np.ma.arange(12, fill_value=88).reshape(3, 4)
print(np.__version__)
print("Original fill_value:", a.fill_value)
print("a.sum fill_value:", a.sum(axis=1).fill_value)
print("a.cumsum fill_value:", a.cumsum().fill_value)
1.12.0.dev0+2af06c8
Original fill_value: 88
a.sum fill_value: 999999
a.cumsum fill_value: 999999
This could be fixed (and I'm willing to submit a PR) but explicitly setting the fill value of the returned array in the various MaskedArray methods. Is this the desired behavior, or should the current behavior of using the default fill_value for these arrays be maintained?
Activity
akleeman commentedon Dec 12, 2013
A similar thing happens with the take operation in numpy 1.7 ...
np.version.version
Out: '1.7.0'
tmp = np.random.normal(size=(3, 4))
masked = np.ma.masked_array(tmp, mask=tmp > 0, fill_value=np.nan)
masked.fill_value
Out: nan
masked.take([0, 1, 2], axis=0).fill_value
Out: 1e+20
np.all(masked.take([0, 1, 2], axis=0) == masked)
Out: True
np.all(masked.take([0, 1, 2], axis=0).filled() == masked.filled())
Out: False
Looks like the same thing would happen in numpy 1.8
charris commentedon Feb 15, 2014
Sounds like something reasonable to do.
alimuldal commentedon Feb 10, 2016
A related question popped up on SO today: http://stackoverflow.com/q/35324836/1461210
In versions >= 1.10.0:
Prior to 1.10.0 I get a fill value of 1.0 in both cases, which seems much more reasonable to me. The behaviour in question was introduced in 3c6b6ba.
charris commentedon Feb 11, 2016
Probably related: #7122.
alimuldal commentedon Feb 14, 2016
@charris Definitely looks that way - I also did a bisect and identified 3c6b6ba as the culprit
jjhelmus commentedon Apr 1, 2016
It looks like most (all) of the reductions operations do not preserve the
fill_valueattribute:This could be fixed (and I'm willing to submit a PR) but explicitly setting the fill value of the returned array in the various MaskedArray methods. Is this the desired behavior, or should the current behavior of using the default fill_value for these arrays be maintained?
sannant commentedon Mar 1, 2019
Some related problem with the multiplication with a scalar:
some example test code:
And the output for the fill_value 0 :
the fill'_value doesn't change. according to
hma.__repr__(), but when applyingnp.asarraythe fill_value is systematically replaced by 1.System informations:
numpy: 1.16.0
python: Python 3.7.0
os: macOS 10.13.6