[Numpy-discussion] design issues - octave 'incompatibilities'
Chris.Barker at noaa.gov
Tue Jul 26 09:32:07 CDT 2005
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
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"
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.
Christopher Barker, Ph.D.
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
More information about the Numpy-discussion