[Numpy-discussion] matmul as a ufunc

Nathaniel Smith njs at pobox.com
Tue May 29 13:52:26 EDT 2018


On Mon, May 28, 2018, 20:41 Stephan Hoyer <shoyer at gmail.com> wrote:

> On Mon, May 28, 2018 at 7:36 PM Eric Wieser <wieser.eric+numpy at gmail.com>
> wrote:
>
>> which ensure that it is still well defined (as the identity) on 1d
>> arrays.
>>
>> This strikes me as a bad idea. There’s already enough confusion from
>> beginners that array_1d.T is a no-op. If we introduce a
>> matrix-transpose, it should either error on <1d inputs with a useful
>> message, or insert the extra dimension. I’d favor the former.
>>
> To be clear: matrix transpose is an example use-case rather than a serious
> proposal in this discussion.
>
> But given that idiomatic NumPy code uses 1D arrays in favor of explicit
> row/column vectors with shapes (1,n) and (n,1), I do think it does make
> sense for matrix transpose on 1D arrays to be the identity, because matrix
> transpose should convert back and forth between row and column vectors
> representations.
>

More concretely, I think the idea is that if you write code like

  a.T @ a

then it's nice if that automatically works for both 2d and 1d arrays.
Especially, say, if this is embedded inside a larger function so you have
some responsibilities to you users to handle different inputs
appropriately, and your users expect that to include both 2d matrices and
1d vectors. It reduces special cases.

But, on the other hand, if you write

a @ a.T

then you'll be in for a surprise... So maybe it's not a great idea after
all.

(Note that here I'm using .T as a placeholder for a hypothetical
"broadcasting matrix transpose". I don't think anyone proposes that .T
itself should be changed to do this; I just needed some notation.)

-n

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180529/3f9a57ef/attachment.html>


More information about the NumPy-Discussion mailing list