[PEP draft 2] Adding new math operators

[Huaiyu Zhu]

On Wed, 09 Aug 2000 04:52:04 GMT, Rainer Deyke <root at rainerdeyke.com> wrote:

>I've mentioned this before: your division between objectwise and elementwise
>operators does not hold because it is not clear whether elementwise
>operators are "deep" or "shallow".  For example ([[0, 1], [2, 3]]
>(elementwise+) [[4, 5], [6, 7]]) could evaluate to either [[4, 6], [8, 10]]
>or [[0, 1, 4, 5], [2, 3, 6, 7]].

Here's what I have in mind: What amounts to going down one level of
"elementization" (can't find a word for this) is a semantic issue for
applications.  For example, an element of matrix is _two_levels_ down in
terms of lists.  (This appears to be another reason the semantics of these
operators should be left to applications.)

>
>The only truly flexible approach would be to allow users to specify an
>arbitrary depth for elementwise operators.  In the proposed ~* notation,
>that would mean that for every binary operator X there is an operator ~X
>which goes one level deeper than X - even if X itself is ~~+.  (This makes
>the proposed notation useless unless someone figures out how support an
>infinite number of operators.)

Well, the only flexible way to solve, once and for all, the general problem
of arbitrary levels of "elementization" may indeed be that complicated, but
this proposal only deals with one level of "elementization", which is what
happens in practice most of the time. The question is then: does this
prevent us from a better solution to the general problem in the future?  In
other words, can we envision a future general solution that would become
more difficult because of the current proposal?  Another relevant question
would be, could we attempt to solve the general problem at this point
without much more effort?

>Another problem with naive elementwise operators is that they require a
>ridiculous number of __magic__ functions, all of which are essentially
>identical.  For example:

The situation is (if you try MatPy you'll see), not only are these magic
functions already defined, they are forced to be used in practice like

(a.e_mul(b) + c).e_add((d.e_mul(c)*b).e_div(e))

instead of 

a~*b + c ~+ d~*c*b~/e

>
>A better solution would be to have a method for "elementwise" operations:
>
>class Pair:
>  def __init__(self, first, second):
>    self.first = first
>    self.second = second
>
>  def elementwise(self, operation):
>    return Pair(operation(self.first), operation(self.second))

I don't follow you.  Suppose 
operation = add
first = (1,2)
second = (3,4)

do you get (3,7) or (4,6)?  The latter is elementwise add.  Maybe I just
missed something.


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