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

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

On Wed, 2005-07-27 at 02:02 -0600, Travis Oliphant wrote:
> Soeren Sonnenburg wrote:
> 
> >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:
> >  
> >
> cvxopt uses it's own classes because they did not feel that a general 
> purpose array was needed.  They wanted to define a matrix class with 
> sparse matrix and dense matrix sub-classes.   In fact, cvxopt's matrix 
> classes can not be used as ubiquitously as Numeric/numarray arrays.   
> Everything is not a matrix.  In fact, I would like to see more general 
> linear algebra routines that allow people to more naturally deal with 
> (for example) six-dimensional linear operators mapping from a 
> three-dimensional space to a three-dimensional space.  Currently, you 
> are forced to perform an artificial row-scanning procedure just to 
> interface with matrix libraries.  Scipy can help with this kind of thing.

Hmmhh, 

> I do not see cvxopt as a competing array implementation.   At some 
> point, hopefully cvxopt will be integrated with scipy.  I am continually 
> looking for feasible ways to make scipy more attractive to 
> contributors.  Everybody benefits when their is a standard 
> infrastructure.   For example, there are sparse matrices in SciPy.  If 
> cvxopt has better sparse matrix objects, I would love to use them.  
> Hopefully, the array interface will assist on a more abstract scale so 
> that memory re-use can occur for at least the dense cvxopt matrices.

I guess we now observe the different communities different expectations
problem :/ In any case I agree that a standard infrastructure is very
desirable. However it might come at a cost one might not want to pay,
but still at least conversion functions from say cvxopt <-> numarray are
worth spending time on.

> >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.
> >  
> >
> 
> Their are several issues here.  But, yes a Matrix object will always be 
> a separate object just as quaternions should be because they represent 
> an interpretation to a memory block.  In Numeric/numarray the focus is 
> on generic multidimensional arrays.  Therefore numeric operators must be 
> element-by element. 

OK.

> Note that Numeric does have a Matrix object that allows you to use '*' 
> to represent matrix multiplication.   It's only problem is that passing 
> this object to a function usually returns an array again instead of a 
> Matrix. 

So the cvxopt approach is pretty valid, doing everything for matrices as
they do, but allowing other types as 'int' etc..

Soeren