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

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

On Tue, 2005-07-26 at 09:30 -0700, Chris Barker wrote:
> Soeren Sonnenburg wrote:
> > 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.
> 
> If you're looking for a matlab clone, use octave or psilab, or....

No I am not, I am sold to python.

> Speaking as an ex-matlab user, I much prefer the NumPy approach. The
> reason is that I very rarely did linear algebra, and generally used
> matlab as a general computational environment. I got very tired of
> having to type that "." before all my operators. I also love array
> broadcasting, it seems so much cleaner and efficient.

Well coming from machine learning I am used to having just matrices.

> When I moved from Matlab to NumPy, I missed these things:
> 
> Integrated plotting: many years later, this is still weak, but at least
> for 2-d matplotlib is wonderful.

I agree here.

[no single numeric package in python]
> But I'm not sure we should be sad about it. What we all  want is the
> package best suited to our own needs to be in the standard library.
> However, I'd rather the current situation than having a package poorly
> suited to my needs in the standard library. As this thread proves, there
> is no one kind of array package that would fit even most people's needs.
> 
> However, there is some promise for the future:
> 
> 1) SciPy base may serve to unify Numeric/numarray
> 
> 2) Travis has introduced the "array interface"
> 
> http://numeric.scipy.org/array_interface.html
> 
> this would provide an efficient way for the various array and matrix
> packages to exchange data. It does have a hope of making it into the
> standard library, though even if it doesn't, if a wide variety of add-on
> packages use it, then the same thing is accomplished. If fact, if
> packages that don't implement an array type, but might use one (like
> PIL, wxPython, etc) accept this interface, then any package that
> implements it can be used together with them.
> 
> 3) What  about PEP 225: Elementwise/Objectwise Operators?
> It's listed under:
> 
> Deferred, Abandoned, Withdrawn, and Rejected PEPs
> 
> Which of those applied here? I had high hope for it one time.
> 
> By the way, I had not seen cvxopt before, thanks for the link. Perhaps
> it would serve as a better base for a full-featured linear algebra
> package than Numeric/numarray. Ideally, it could use the array
> interface, for easy exchange of data with other packages.

Actually that would be nice. Having had a closer look at cvxopt that
might suit *my* needs more, but having an interface to get cvxopt
matrices -> numarray/numeric without trouble to get certain potentially
missing functionality would be nice.

Thanks,
Soeren