[Numpy-discussion] design issues - octave 'incompatibilities'
python-ml at nn7.de
Mon Jul 25 21:36:23 CDT 2005
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:
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 ?
More information about the Numpy-discussion