should outer take an output argument?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

should outer take an output argument?

Alan G Isaac
As I was looking at Bill's conjugate gradient posting,
I found myself wondering if there would be a payoff
to an output argument for ``numpy.outer``.  (It is fairly
natural to repeatedly recreate the outer product of
the adjusted residuals, which is only needed during a
single iteration.)

Cheers,
Alan Isaac



_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: should outer take an output argument?

Anne Archibald
2008/4/29 Alan G Isaac <[hidden email]>:
> As I was looking at Bill's conjugate gradient posting,
>  I found myself wondering if there would be a payoff
>  to an output argument for ``numpy.outer``.  (It is fairly
>  natural to repeatedly recreate the outer product of
>  the adjusted residuals, which is only needed during a
>  single iteration.)

I avoid np.outer, as it seems designed for foot shooting. (It forcibly
flattens both arguments into vectors no matter what shape they are and
then computes their outer product.) np.multiply.outer does (what I
consider to be) the right thing. Not that it takes an output argument
either, as far as I can tell.

But trying to inspect it suggests a few questions:

* Why are ufunc docstrings totally useless?
* Why are output arguments not keyword arguments?

As for your original question, yes, I think it would be good if
.outer() and .reduce() methods of ufuncs took output arguments. This
would let one use add.reduce() as a poor man's sum() even when dealing
with uint8s, for example. (Coming up with a problem for which
subtract.reduce(), divide.reduce(), or arctan2.reduce() are the
solutions is left as an exercise for the reader.) I can definitely see
a use for divide.outer() : Int -> Int -> Float, though.

Anne
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion