Re: [Numpy-discussion] missing function in numpy.ma?
Hi Pierre, I"m ccing Bob on this, he's the main developper for cdms2 package. At this point I think Travis original suggestion was the best. We should leave it like it was for 1.0.5 There's a lot of changes to do in order to get the backward compatibility going. And I feel it should wait until 1.1. I don't feel comfortable doing all these changes and releasing our software like this. It's a major change and it needs to be tested for a while. OUr users are massively hammering the MA and rely on it so much. Although I do see the usefulness of the new ma and at term I believe it has major merits to be used instead of oldnumeric.ma. Your thoughts? C. Pierre GM wrote:
Charles,
Any idea where that comes from ?
No, not really. Seems that TransientVariable(*args) doesn't work. I guess it's because it has inherited a __call__method, and tries to use that method instead of the __new__. Try to call TransientVariable.__new__ instead of just TransientVariable in l505 of avariables.py, and see how it goes. You may want to rethink what subSlice does as well. Instead of calling the class constructor, you can also just create a view of your array and update the attributes accordingly.
Once again, a stripped-down version of the class and its parents would be useful.
All, Because numpy.ma.MaskedArray objects are now derived from classical ndarrays, the subclassing rules should be followed. As we observed yesterday with Charles, the adaptation is not as straightforward as we hoped. If you have time constraints, the easiest would indeed be to revert to the previous implementation of MaskedArray (viz, as an object, where the initialization is performed with a __init__ function). Now, I'm not sure how well it's gonna interface with numpy.ma, we need to try. In the long run however, I think you should try to switch to regular ndarrays and ndarray subclasses. I do agree it's more of a long-term process, but I'd be happy to help (you and I are working more or less on the same field anyway, I needed some tools to handle my environmental/climatic time series) Let me try to cook something up. In the meantime, please keep me posted. P. On Tuesday 01 April 2008 11:07:41 Charles Doutriaux wrote:
Hi Pierre,
I"m ccing Bob on this, he's the main developper for cdms2 package. At this point I think Travis original suggestion was the best. We should leave it like it was for 1.0.5 There's a lot of changes to do in order to get the backward compatibility going. And I feel it should wait until 1.1. I don't feel comfortable doing all these changes and releasing our software like this. It's a major change and it needs to be tested for a while. OUr users are massively hammering the MA and rely on it so much. Although I do see the usefulness of the new ma and at term I believe it has major merits to be used instead of oldnumeric.ma.
Your thoughts?
Hi Pierre,
I"m ccing Bob on this, he's the main developper for cdms2 package. I've uploaded the original ma.py file back into oldnumeric so that
Charles Doutriaux wrote: oldnumeric.ma should continue to work as before. Can you verify this? Thanks, -Travis O.
Hi Travis, I get this: import numpy, numpy.oldnumeric.ma as MA, numpy.oldnumeric as Numeric, PropertiedClasses File "/lgm/cdat/latest/lib/python2.5/site-packages/numpy/oldnumeric/ma.py", line 2204, in <module> array.mean = _m(average) NameError: name 'average' is not defined C. Travis E. Oliphant wrote:
Charles Doutriaux wrote:
Hi Pierre,
I"m ccing Bob on this, he's the main developper for cdms2 package.
I've uploaded the original ma.py file back into oldnumeric so that oldnumeric.ma should continue to work as before. Can you verify this?
Thanks,
-Travis O.
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Charles Doutriaux wrote:
Hi Travis,
I get this:
import numpy, numpy.oldnumeric.ma as MA, numpy.oldnumeric as Numeric, PropertiedClasses File "/lgm/cdat/latest/lib/python2.5/site-packages/numpy/oldnumeric/ma.py", line 2204, in <module> array.mean = _m(average) NameError: name 'average' is not defined
Thanks, Can you try again? Best regards, -Travis
Hi Travis, Ok we're almost there, in my test suite i get: maresult = numpy.core.ma.take(ta, indices, axis=axis) AttributeError: 'module' object has no attribute 'ma' data = numpy.core.ma.take(ax[:], indices) AttributeError: 'module' object has no attribute 'ma' I don't know if it was automatically put there by the converter or if we put it by hand. If it's the first one, you might want to correct this, otherwise don't worry it's easy enough to fix (i think ?) C. Travis E. Oliphant wrote:
Charles Doutriaux wrote:
Hi Travis,
I get this:
import numpy, numpy.oldnumeric.ma as MA, numpy.oldnumeric as Numeric, PropertiedClasses File "/lgm/cdat/latest/lib/python2.5/site-packages/numpy/oldnumeric/ma.py", line 2204, in <module> array.mean = _m(average) NameError: name 'average' is not defined
Thanks,
Can you try again?
Best regards,
-Travis
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Charles Doutriaux wrote:
Hi Travis, Ok we're almost there, in my test suite i get: maresult = numpy.core.ma.take(ta, indices, axis=axis) AttributeError: 'module' object has no attribute 'ma' data = numpy.core.ma.take(ax[:], indices) AttributeError: 'module' object has no attribute 'ma'
I think the problem here is that numpy.core.ma is no longer the correct place. This should be numpy.oldnumeric.ma.take because numpy.oldnumeric.ma is the correct location. In my mind you shouldn't really have been using "numpy.core.ma", but instead numpy.ma because whether things are in core or lib could change ;-) -Travis
Hi Travis, Thanks, I'll fix this and let you know. (probably tomorrow because I came down with some nasty "real" bug... flue or something like that) C. Travis E. Oliphant wrote:
Charles Doutriaux wrote:
Hi Travis, Ok we're almost there, in my test suite i get: maresult = numpy.core.ma.take(ta, indices, axis=axis) AttributeError: 'module' object has no attribute 'ma' data = numpy.core.ma.take(ax[:], indices) AttributeError: 'module' object has no attribute 'ma'
I think the problem here is that numpy.core.ma is no longer the correct place. This should be
numpy.oldnumeric.ma.take because numpy.oldnumeric.ma is the correct location.
In my mind you shouldn't really have been using "numpy.core.ma", but instead numpy.ma because whether things are in core or lib could change ;-)
-Travis
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Travis, Pierre, Goood news what's in trunk right now seems to work great with our stuff, I only had to replace numpy.core.ma.take with numpy.ma.take (numpy.oldnumeric.ma.take didn't seem to work) So as soon as 1.0.5 is out, I'll start working toward using numpy.ma only. Also, I have one little request, i remember you said oldnumeric would be gone in the next version. But our users will have hundreds (thousands?) of script convert with "import numpy.oldnumeric.ma as MA" or "import numpy.oldnumeric as Numeric" And although we're insisting and using numpy and numpy.ma right away, i'm sure 99% of them will ignore this. So would be be horrible to leave as shortcut (with a warning while loading probably, actually we could have the warning already in numpy 1.0.5 ?) from numpy.oldnumeric back to numpy ? same for oldnumeric.ma pointing back to numpy.ma. I realize it's not really clean... At least it would be great to have the warning raised in 1.0.5 that it will disappear in 1.1. Like that users might be more inclined to start converting "cleaninly" Thanks for considering this and also thanks a LOT for all your help on this issue! C. Travis E. Oliphant wrote:
Charles Doutriaux wrote:
Hi Travis, Ok we're almost there, in my test suite i get: maresult = numpy.core.ma.take(ta, indices, axis=axis) AttributeError: 'module' object has no attribute 'ma' data = numpy.core.ma.take(ax[:], indices) AttributeError: 'module' object has no attribute 'ma'
I think the problem here is that numpy.core.ma is no longer the correct place. This should be
numpy.oldnumeric.ma.take because numpy.oldnumeric.ma is the correct location.
In my mind you shouldn't really have been using "numpy.core.ma", but instead numpy.ma because whether things are in core or lib could change ;-)
-Travis
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Charles Doutriaux wrote:
Travis, Pierre,
Goood news what's in trunk right now seems to work great with our stuff, I only had to replace numpy.core.ma.take with numpy.ma.take (numpy.oldnumeric.ma.take didn't seem to work)
So as soon as 1.0.5 is out, I'll start working toward using numpy.ma only.
Also, I have one little request, i remember you said oldnumeric would be gone in the next version. But our users will have hundreds (thousands?) of script convert with "import numpy.oldnumeric.ma as MA" or "import numpy.oldnumeric as Numeric" And although we're insisting and using numpy and numpy.ma right away, i'm sure 99% of them will ignore this. So would be be horrible to leave as shortcut (with a warning while loading probably, actually we could have the warning already in numpy 1.0.5 ?) from numpy.oldnumeric back to numpy ? same for oldnumeric.ma pointing back to numpy.ma. I realize it's not really clean... At least it would be great to have the warning raised in 1.0.5 that it will disappear in 1.1. Like that users might be more inclined to start converting "cleaninly"
I'm pretty sure we will make a 1.0.X release that issues warnings prior to making a 1.1 release. -Travis
Charles Doutriaux wrote:
Travis, Pierre,
Goood news what's in trunk right now seems to work great with our stuff, I only had to replace numpy.core.ma.take with numpy.ma.take (numpy.oldnumeric.ma.take didn't seem to work)
I don't know if it fixes the problem you ran into, but there is a clear bug fixed by the following: efiring@manini:~/programs/py/numpy_svn/trunk/numpy/oldnumeric$ svn diff Index: ma.py =================================================================== --- ma.py (revision 4958) +++ ma.py (working copy) @@ -2264,6 +2264,6 @@ return new_average(a, axis, weights, returned) def take(a, indices, axis=0): - return new_take(a, indices, axis=0) + return new_take(a, indices, axis) Eric
So as soon as 1.0.5 is out, I'll start working toward using numpy.ma only.
Also, I have one little request, i remember you said oldnumeric would be gone in the next version. But our users will have hundreds (thousands?) of script convert with "import numpy.oldnumeric.ma as MA" or "import numpy.oldnumeric as Numeric" And although we're insisting and using numpy and numpy.ma right away, i'm sure 99% of them will ignore this. So would be be horrible to leave as shortcut (with a warning while loading probably, actually we could have the warning already in numpy 1.0.5 ?) from numpy.oldnumeric back to numpy ? same for oldnumeric.ma pointing back to numpy.ma. I realize it's not really clean... At least it would be great to have the warning raised in 1.0.5 that it will disappear in 1.1. Like that users might be more inclined to start converting "cleaninly"
Thanks for considering this and also thanks a LOT for all your help on this issue!
C.
Travis E. Oliphant wrote:
Charles Doutriaux wrote:
Hi Travis, Ok we're almost there, in my test suite i get: maresult = numpy.core.ma.take(ta, indices, axis=axis) AttributeError: 'module' object has no attribute 'ma' data = numpy.core.ma.take(ax[:], indices) AttributeError: 'module' object has no attribute 'ma'
I think the problem here is that numpy.core.ma is no longer the correct place. This should be
numpy.oldnumeric.ma.take because numpy.oldnumeric.ma is the correct location.
In my mind you shouldn't really have been using "numpy.core.ma", but instead numpy.ma because whether things are in core or lib could change ;-)
-Travis
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
participants (4)
-
Charles Doutriaux -
Eric Firing -
Pierre GM -
Travis E. Oliphant