[Numpy-discussion] design issues - octave 'incompatibilities'
Soeren Sonnenburg
python-ml at nn7.de
Wed Jul 27 15:03:02 EDT 2005
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
More information about the NumPy-Discussion
mailing list