[PEP draft 2] Adding new math operators

[Tim Hochberg]

perry at eclipse.stsci.edu (Perry Greenfield) writes:

> In article <m2n1imfr0q.fsf at spiff.home.com>, Tim Hochberg <tim.hochberg at ieee.org> writes:

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

I'm not sure I agree with the FFT example although I see your
point. This isn't really consistent with the current behaviour of FFT
in thatm for example, FFT doesn't currently convert back to a list if
you pass in a list. I think there's something to be said for having a
function always return a given type. It might make more sense to have
Numeric.FFT and MatPy.FFT (both wrappers around the same function)
which returned the appropriate types. One reason I say this is that
one probably wants multiargument functions (e.g, dot) to behave as
they do now with mixed arguments. In order to be consistent with the
behaviour you suggest above, dot would have to give up with mixed
arguments and return the appropriate type for matched arguments. It
seems better to have in this case Numeric.dot and MatPy.dot.

But like I say I see your point and this may be something that should
be decided function with FFT being treated one way and dot another.

-tim