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

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

On Mon, 2005-07-25 at 17:47 -0400, Perry Greenfield wrote:
> I missed this part and was reminded by Travis's message.
> 
> On Jul 23, 2005, at 12:03 PM, Soeren Sonnenburg wrote:
> > -- How can one obtain submatrices from full matrices:
> >
> > numarray gives only elements (which is very, very rarely needed and
> > should IMHO rather be some extra function):
> >
> >>>> i=[0,1]
> >>>> j=[0,2]
> >>>> a[i,j]
> > array([1, 6])
> >
> > vs octave:
> >>> i=[1,2];
> >>> j=[1,3];
> >>> a(i,j)
> > ans =
> >         1        3
> >         4        6
> >
> Maybe for you it is rarely needed, but not for us. The situation is 
> reversed. The latter is rarely used in our case. This is largely a 
> reflection of whether your orientation is matrices or multidimensional 
> arrays. In our case it is quite handy to select out a list of point in 
> an image by giving a list of their respective indices (e.g., stars).

Hmmhh. I see that this again breaks with R/octave/matlab. One should not
do so if there is no serious reason. It just makes life harder for every
potential convert from any of these languages. A funktion take() would
have served this purposed much better... but this is ofcourse all IMHO
and I can see your point: You design it according to your (or your
communities) requirements and different communities different needs... 

I am realizing that this must have been why cvxopt switched away from
numarray/numeric. There slicing/indexing and '*' work as I would have
expected:

In [71]: a=matrix([1,2,3,4,5,6,7,8,9],size=(3,3))
In [72]: a
Out[72]: <3x3 matrix, tc='d'>
In [73]: b=matrix([1,2,3,4,5,6,7,8,9],size=(3,3))
In [74]: a*b
Out[74]: <3x3 matrix, tc='d'>
In [75]: print a
   1.0000e+00   4.0000e+00   7.0000e+00
   2.0000e+00   5.0000e+00   8.0000e+00
   3.0000e+00   6.0000e+00   9.0000e+00

In [76]: print b
   1.0000e+00   4.0000e+00   7.0000e+00
   2.0000e+00   5.0000e+00   8.0000e+00
   3.0000e+00   6.0000e+00   9.0000e+00

In [77]: print a*b
   3.0000e+01   6.6000e+01   1.0200e+02
   3.6000e+01   8.1000e+01   1.2600e+02
   4.2000e+01   9.6000e+01   1.5000e+02

In [78]: print a[:,0]
   1.0000e+00
   2.0000e+00
   3.0000e+00

In [79]: print a[0,1]
4.0
In [80]: print a[0,:]
   1.0000e+00   4.0000e+00   7.0000e+00

> True, I do see that others may need the other view, but then the 
> question is which should get the convenience. Since Numeric/numarray 
> are primarily oriented towards multidimensional arrays (e.g., 
> operations are element-by-element rather than matrix) it seemed to make 
> sense to go this way for consistency, but I understand that there is 
> another side to this.

It now seems very difficult for me to end up with a single
numeric/matrix package that makes it into core python - which is at the
same time very sad.

Soeren