On Mon, 2005-07-25 at 10:10 -0400, Perry Greenfield wrote:
On Jul 24, 2005, at 2:41 PM, Soeren Sonnenburg wrote:
Well but why did you change to the C version then ? Well maybe if it is about optimizing stuff seriously one could work with the transpose anyway...
To get a really solid answer to "why" you would have to ask those that wrote the original Numeric. (Jim Hugunin and Co.). My guess is was that it was just as much to preserve the following relation
arr[i,j] = arr[i][j]
(instead of arr[i,j] = arr[j][i])
Ok, that sounds reasonable.
But I could be wrong.
Note that this is a confusing issue to many and often as not there are unstated assumptions that are repeatedly made by many that are *not* shared by everyone. To illustrate, there are at least two different approaches to handling this mismatch and it seems to me that many seem oblivious to the fact that there are two approaches.
Approach 1: Keep the index convention the same. As a user of Numeric or numarray, you wish M[i,j] to mean the same as it does in Fortran/IDL/matlab... The consequence is that the data are ordered differently between Numeric/numarray and these other languages. This is seen as a data compatibility problem.
Approach 2: Keep the data invariant and change the indexing convention. What was M[i,j] in Fortran is now M[j,i] in Numeric/numarray. This is not a data compatibility problem, but is now a brain compatibility problem ;-)
well it might not be *that* bad in the end... only it is a tough decision to break with everything that is there (to put it to extreme: the world is wrong and but we did it right) and be compatible with C like array access... If one does so one needs to have very serious reasons to do so ... that is why I was asking.
Since we deal with big data sets we have adopted 2 (no doubt to the consternation of many).
hmmhh, there is no advantage with big datasets for any of the formats.
Do you know whether mixing slices and arrays will be supported at some point a[:,[0,1]] ?
Soeren.
No plans at the moment. We figured indexing was complicated enough as it was. I think Travis Oliphant did allow for this in Numeric3 (aka scipy.core); see the link below. But it may not mean what you think it should so you should check that out to see:
http://cvs.sourceforge.net/viewcvs.py/numpy/Numeric3/PEP.txt?view=markup
Hmmhh while we are at it, is there work on a consensus num* ? I've seen the PEP for inclusion of numarray, now I see numeric3 and scipy and also cvxopt - are people actually converging towards a single num* package ? Soeren.