[PEP draft 2] Adding new math operators

[Robin Becker]

In article <8msl0v$g5m$1 at tomm.stsci.edu>, Perry Greenfield
<perry at eclipse.stsci.edu> writes
>In article <m2n1imfr0q.fsf at spiff.home.com>, Tim Hochberg <tim.hochberg at ieee.org> 
>writes:
> 
>[description of .E and .A approach snipped]
>
>Some of us have been talking about an almost identical approach (though
>I'm not sure we all agree even amongst ourselves which is the best
>approach :-). I think it is worth some serious consideration.
>
>|> There has been some critisism of this approach on the basis that
>|> inside a function one doesn't know what types are passed in. I think
>|> this is a smaller problem than it has been presented as. If the
>|> function in question is not a small, throwaway function, then it is
>|> both useful and easy to check or coerce the arguments at the top of
>|> the function. For example:
>|> 
>|> def frobulate(A, B, C):
>|>    A, B, C = A.E, B.E, C.E # I like working elementwise.
>|>    # ....
>|> 
>|> or better still:
>|> 
>|> def fribbinate(A, B, C):
>|>    A, B, C = asarray(A, Float), asarray(B, Float), asarray(C, Float)
>|>    #....
>|> 
>
>But don't forget the need to coerce the result to the type submitted
>as an argument. For example if the FFT module used the NumPy module
>and someone called an fft with MatPy arrays, presumably we would like
>the fft to return a MatPy array. So some convenience function ought to
>be provided to coerce to the input type.
>
>As mentioned below, this issue has to be addressed regardless of whether
>new operators are provided if MatPy and NumPy use different meanings for
>the standard operators.
.....
>Perry Greenfield
 I think the problem of what to coerce return values to is more
difficult that the inputs. A particular function can at least decide
which argument types suite it best, it's much harder for a function to
decide in what context it's being called.
-- 
Robin Becker