Matlab vs Python (was RE: Discussion: Introducing new operators f

[Huaiyu Zhu]

On Tue, 18 Jul 2000 11:08:57 -0500, Travis Oliphant <olipt at mayo.edu> wrote:
>
>I think I'll chime in here.  I have been greatly enjoying this discussion.
>I have been an active participant in Numerical Python development and have
>been advocating it's use over Matlab to anyone who will listen for over a
>year.  This recent excitement is encouraging as I've seen the potential
>for Python to replace Matlab for some time.  Before, my thesis writing
>picked up I spent quite a bit of time working on improving the number of
>"toolboxes" available for Python --- a project I intend to continue as
>soon as my dissertation gets written since I plan on using Python in the
>electrical engineering classes I teach at University this winter.

Hi, Travis,

First let me say I admire your work greatly.  You and all the NumPy
developers have done tramendously wonderful work.  (And I stole a little
glory with a wrapper package MatPy.)

The reason I started the MatPy project was simply that to me a simple linear
algebra interface is more convenient than a multiarray interface. There are
surely people whose work lead to the opposite preference.  In fact, as
everyone finds out sooner or later, both notations are equally important.  I
think that is the reason why there is a Matrix class in NumPy and there are
elementwise operations in MatPy.  (And partly why we are having this
discussion).  MatPy is not concentrated to 2d matrix only, as there is also
a rudimentary tensor class.  The main thing is that the standard operators
stand for (multi-)linear algebra instead elementwise operations.

I agree there need to be better coordination between the two projects. At
the moment MatPy is still in its initial growth period.  I do see the merit
of either letting the standard operators take matrix or elementwise flavor.
Had python provided a larger supply of operators there may not need to be
two packages, because choosing * or @* as primary is not a big deal.  Now we
are forced to choose between

either    a*b.__dotmul__(c)
or        matrixmultipy(a,b)*c

and it makes sense to different people to use either package as primary
tools.  Because of the conciseness of linear algebra it is very difficult to
switch operators in working code.  So I foresee both packages to coexist for
a long time.

One way to enhance the coordination might be to first standardize the method
definitions as

.mmul
.emul

which are then hooked to either

.__mul__
.__dotmul__
.__atmul__

If NumP adds @ operators for matrix and MatPy adds the . operator for
elementwise, non of the existing code would break.  That is
          element      matrix
NumPy        *           @*
MatPy        .*          *

We can also start adopting common names for various functions whenever
possible.   When everyone's code standardizes on these notations, it would
be much easier to switch to one standard notation if it is so desired.

I for one would really like to see NumPy getting into the core.  It will
remove a big barrier for a lot of people who would have otherwise used it
but for the (perceived) difficulty of installing an additional package.
Of course it will also remove a barrier for people installing MatPy.  :-)

I understand your concern that adding additional operators might hinder the
acceptance by core developers.  I am encouraged by the recent discussion of
the idea that it might be possible for a module to define its own operators.
Before that happens, one can always write code in the more verbose notation
so that it is guaranteed to work with standard python.  The magic methods
could be defined so that those who can patch the source code could use the
new symbols.

I have not yet taken a look at numpy2, but from you description it sounds
numpy2 would bring us more to the table.  I encourage everyone who care and
who can to give it a look and hopefully join the development.  For a
foreseeable future matpy will be a wrapper around numpy.

Gregory had expressed the idea that both numpy and matpy use the same set of
symbols when his patch is released.  I'm not against this idea but I don't
see any feasible way to deal with existing code except via above route.


Huaiyu

-- 
Huaiyu Zhu                       hzhu at users.sourceforge.net
Matrix for Python Project        http://MatPy.sourceforge.net