|
From: Perry G. <pe...@st...> - 2005-07-25 14:10:33
|
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]) 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 ;-) Since we deal with big data sets we have adopted 2 (no doubt to the consternation of many). This ought to be in a FAQ, it comes up enough to be :-) > > 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 Perry Greenfield |