Re: [Numpy-discussion] [SciPy-user] maskedarray
Pierre GM wrote:
On Tuesday 11 December 2007 15:48:01 Tom Johnson wrote:
What is the status regarding 'maskedarray'? When will this become part (replace ma) of the standard distribution? Also, what is the recommended way to import sandbox modules so that code changes are minimized when (if) the package becomes part of the standard distribution.
Mmh, no answer from our leaders ? Well, for now maskedarray lives in the scipy sandbox, but it probably could be transferred to the numpy sandbox. There's still no particular decision I'm aware of about putting it the official release. More feedback is probably needed from users.
I apologize for not chiming in here. It has been difficult to keep up with all the lists on which I should ostensibly know what is being discussed as I have changed jobs and am settling in to new responsibilites. It seems to me that it is time to move the scipy.sandbox.maskedarray implementation over to numpy.ma. I'm a little concerned about doing this before 1.1, but if the API has not changed, then it should be fine. If there is no opposition, then it seems that this can move forward before 1.0.5 which I would like to see in January. For the future 1.1 release (late 2008), I would like to see (in no particular priority order): 1) The MA made a C-subclass 2) The matrix object made a C-subclass (for speed). 3) The sparse matrix structure (but not all the algorithms) brought over into NumPy with the indexing matching the matrix indexing. 4) Weave brought over into NumPy The additions should be created in such a way that they can be disabled should so that perhaps a numpy-lite could be produced as well. Or, perhaps better separate packages like numpy-devel, numpy-compat, numpy-sparse could be created. I'm looking forward to some good discussions over the weekend. -Travis O.
On Wed, 12 Dec 2007, "Travis E. Oliphant" apparently wrote:
2) The matrix object made a C-subclass (for speed).
This will probably be the last chance for such a change, so I again hope that consideration will be given to *one* change in the matrix object: iteration over a matrix should return arrays (instead of matrices). So if A is a matrix, A[1] should be an array, but A[1,:] should be a matrix. Obviously this is an argument from design rather than from functionality. Current behavior is not "natural". E.g., it makes it awkward to iterate over all elements in the "natural" way, which I claim is:: for row in A: for element in row: print element This example is just meant to illustrate in a simple way what is "odd" about the current behavior. (It is not meant to be an "argument" nor to suggest that the current absence simple ways to do the same thing---e.g., using A.A.) Whenever I am working with matrices, I notice some aspect of this "oddity", and it is annoying when so much else is quite aesthetic. Cheers, Alan Isaac PS For those who do not know, here is an example of the current behavior. (The following prints 2 matrices instead of 4 elements.)
A = N.mat('1 2;3 4') for row in A: ... for element in row: ... print element ... [[1 2]] [[3 4]]
participants (2)
-
Alan G Isaac -
Travis E. Oliphant