Discussion: new operators for numerical computation

[John Lull]

At the dawn of the third millenium (by the common reckoning),
hzhu at localhost.localdomain (Huaiyu Zhu) wrote (with possible
deletions):


> NumPy matrix  NumPy element  MatPy matrix  Matpy element
>   @+              +              +            .+
>   @-              -              -            .-
>   @*              *              *            .*
>   @/              /              /            ./
>   /@             none           what          none
>   @**             **             **           .**
> 
> This provides the smoothest migration path for all the users. Note that the
> cause of NumPy/MatPy inconsistency was the lack of binary operators.  As
> this already happened, it is difficult to integrate them until both got two
> versions of operators.  Problems:
> 
> - This introduces 6+5 new operators.  Ironically the previous lack of
>   operators actually results in more operators.
> 
> - Having standard + - * / mean different things in NumPy and MatPy.  I
>   personally find this no problem.  In certain portions of my programs I need
>   elementwise operations exclusively, and I found it convenient to cast
>   everything into NumPy without trouble.
> 
> - There's still no left division for MatPy.

This, I think, would be a mistake, and would likely result in
rejection of the proposal.

We need to do what is right for Python, long term.  If that results is
short-term pain to a small user base, so be it.  The *right* thing to
do (IMO) is to have one set of new operators, with equivalent meaning
in both NumPy and MatPy.

Quite frankly, I prefer the .* notation, simply for consistency with
Matlab if nothing else -- but the MatPy user base is likely far
smaller than that for NumPy.  This argues for your NumPy notation, or
some other notation defaulting to elementwise, and MatPy may just have
to change.  I believe you agreed that element-wise is the appropriate
default for other reasons, as well.

This could be done relatively painlessly by renaming MatPy when the
new operators show up, and allowing both to be installed on the same
machine.  It could also be done by providing duplicate class
defintions, with slightly changed names, where the new classes use the
new operators.  The old classes could be clearly marked 'deprecated',
and dropped after a year or so.  If this is to be done, though, the
change ought to start as soon as practical.

Regards,
John