[PEP draft 2] Adding new math operators

[Gregory Lielens]

Rainer Deyke 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]].

Excellent point. This is indeed a problem with the proposed -extension-
of
meaning of the ~op to lists and strings. 
If the extension is retained, I would use depth 1, i.e shalow, i.e.
 ([[0, 1], [2, 3]] (elementwise+) [[4, 5], [6, 7]]) == [[0, 1, 4, 5],
[2, 3, 6, 7]]
It seems to me a more logical option when dealing with a list, which
contain heterogeneous objects (including nested lists). I would expect
the deep behavior when dealing with arrays (Ndimensional tables of
homogeneous objects), for which NumPy arrays is far more efficient than
nested lists and have already the intended behavior...

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

I would say instead: A more general approach would be ('~'*n)op means op
with depth n. The current notation is limited to depth 1, unless someone
figures out how to support an infinite number of operators...

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

Yes, it is a problem, but is already the current method used by python
for dealing with binary +,-, or binary *,/,%
and also the way finally choosen for implementing augmented assignment,
I think...
Do you think it is possible to implement the desired operator without
multiplying the OPCODES? Or to turn binary ops into ternary ones, with
the third argument beeing the depth, computed using the number of
leading ~ (this would be a pretty good way to do it imho, but I does not
know how to do it within the current parser...)


Greg.