Re: [Numpy-discussion] design issues - octave 'incompatibilities'

[Soeren S. <pyt...@nn...>]

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.