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

[Chris Barker]

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....

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.

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.

The large library of math functions: SciPy is moving to fill that gap.

Automatic handling of IEEE special values: numarray now does that pretty
well.

That's what I missed. What I gained was a far more powerful and
expressive language, AND a more powerful and flexible array type. I
don't miss MATLAB at all. In fact, you'll find me on the matplotlib
mailing list, often repeating the refrain: matplotlib is NOT MATLAB nor
should it be!

> It now seems very difficult for me to end up with a single
> numeric/matrix package that makes it into core python - 

That is probably true.

> which is at the same time very sad.

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.

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov