[Numpy-discussion] design issues - octave 'incompatibilities'
perry at stsci.edu
Mon Jul 25 07:11:17 CDT 2005
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
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
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]] ?
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:
More information about the Numpy-discussion