[Numpy-discussion] missing function in numpy.ma?

Thu Mar 27 10:38:35 EDT 2008

Eric, Pierre,

I agree the new ma is probably much better and we should use it.

all i was saying is that 1.0.4 was working great with the small 
compatibility layer.
I even have a frozen version of 1.0.5 devel that works great. Then 
suddenly everything broke.

I was really happy was the layer of 1.0.4.

It is not only a matter of converting our software, I can do that. It 
also a matter of have our user base go smoothly thru the transition.

So far they were happy with the 1st order conversion script. And a 
little bit of editing. But we can't ask them to go thru thousands of 
lines of old code and sort of rewrite it all.

When I said it shouldn't be hard to do as much of MA as possible. I 
simply meant put back the compatibility layer that was there in 1.0.4. 
and early 1.0.5dev. I'm not advocating to rewrite the old MA at all, 
simply to keep what was already there as far as transition, why undoing it?

I really don't mind help you i the process if you want.

C.

Eric Firing wrote:
> Charles Doutriaux wrote:
>   
>> The reorder is a function we implement. By digging a bit into this my 
>> guess is that all the missing function in numpy.ma are causing to fail 
>> at some point in our init and returning the wrong object type.
>>
>> But the whole idea was to keep a backward compatible layer with Numeric 
>> and MA. It worked great for a while and now things are getting more and 
>> more broken.
>>     
> There are costs as well as benefits in maintaining backward 
> compatibility, so one should not rely on it indefinitely.
>   
>> Correct me if I'm wrong but it seems as if the numpy.oldnumeric.am is 
>> now simply numpy.ma and it's pointing to the new MaskedArray interface. 
>> Loosing a LOT of backward compatibility at the same time.
>>     
>
> numpy.oldnumeric.ma was a very small compatibility wrapper for 
> numpy.core.ma; now it is the same, but pointing to numpy.ma, which is 
> now Pierre's new maskedarray implementatin. Maybe more compatibility 
> interfacing is needed, either there or in numpy.ma itself, but I would 
> not agree with your characterization of the degree of incompatibility.
>
> Whether it would be possible (and desirable) to replace oldnumeric.ma 
> with the old numpy/core/ma.py, I don't know, but maybe this, or some 
> other way of keeping core/ma.py available, should be considered.  Would 
> this meet your needs?
>
> Were you happy with release 1.04?
>
>   
>> I'm thinking that such changes should definitely not happen from 1.0.4 
>> to 1.0.5 but rather in some major upgrade of numpy (1.1 at least, may be 
>> even 2.0).
>>     
>
> No, this has been planned for quite a while, and I would strongly oppose 
> any such drastic delay.
>
>   
>> It is absolutely necessary to have the oldnumeric.ma working as much as 
>> possible as MA, what's in now is incompatible with code that have been 
>> successfully upgraded to numpy using your recommended method (official 
>> numpy doc)
>>
>> Can you put back ALL the function from numpy.oldnumeric.ma ? It 
>> shouldn't be too much work.
>>
>> Now I'm actually worried about using ma at all? What version is in? Is 
>> it a completely new package or is it still the old one just a bit 
>> broken? If it's a new one, we'd have to be sure it is fully tested 
>>     
>
> No, it is not broken, it has many improvements and bug fixes relative to 
> the old ma.py.  That is why it is replacing ma.py.
>
>   
>> before we can redistribute it to other people via our package, or before 
>> we use it ourselves
>>     
>
> Well, the only way to get something fully tested is to put it in use. 
> It has been available for testing for a long time as a separate 
> implementation, then as a numpy branch, and now for a while in the numpy 
> svn trunk.  It works well.  It is time to release it--possibly after a 
> few more tweaks, possibly leaving the old core/ma.py accessible, but 
> definitely for 1.05. No one will force you to adopt 1.05, so if more 
> compatibility tweaks are needed after 1.05 you can identify them and 
> they can be incorporated for the next release.
>
> Eric
>
>   
>> Can somebody bring some light on this issue? thanks a lot,
>>
>> C.
>>
>>
>> Pierre GM wrote:
>>     
>>> Charles,
>>>   
>>>       
>>>> result = result.reorder(order).regrid(grid)
>>>> AttributeError: 'MaskedArray' object has no attribute 'reorder'
>>>>
>>>> Should I inherit from soemtihng else ?
>>>>     
>>>>         
>>> Mmh, .reorder is not a regular ndarray method, so that won't work. What is it 
>>> supposed to do ? And regrid ?
>>>
>>>   
>>>       
>>>> Aslo I used to import a some function from numpy.oldnumeric.ma, that are
>>>> now missing can you point me to their new ma equivalent?
>>>> common_fill_value, identity, indices and set_fill_value
>>>>     
>>>>         
>>> For set_fill_value, just use
>>> m.fill_value = your_fill_value
>>>
>>> For identity, just use the regular numpy version, and view it as a 
>>> MaskedArray:
>>> numpy.identity(...).view(MaskedArray)
>>>
>>> For common_fill_value: ah, tricky one, I'll have to check.
>>>
>>> If needed, I'll bring identity into numpy.ma. Please don't hesitate to send 
>>> more feedback, it's always needed.
>>> Sincerely,
>>> P.
>>> _______________________________________________
>>> Numpy-discussion mailing list
>>> Numpy-discussion at scipy.org
>>> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>>>
>>>   
>>>       
>> _______________________________________________
>> Numpy-discussion mailing list
>> Numpy-discussion at scipy.org
>> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>>     
>
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>
>   