On Tue, Sep 16, 2014 at 4:31 PM, Jaime Fernández del Río
<jaime.f...@gmail.com> wrote:
> If it is a bug, it is an extended one, because it is the same behavior of
> einsum:
>
>>>> np.einsum('i,i', [1,1,1], [1])
> 3
>>>> np.einsum('i,i', [1,1,1], [1,1])
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> ValueError: operands could not be broadcast together with remapped shapes
> [origi
> nal->remapped]: (3,)->(3,) (2,)->(2,)
>
> And I think it is a conscious design decision, there is a comment about
> broadcasting missing core dimensions here:
>
> https://github.com/numpy/numpy/blob/master/numpy/core/src/umath/ufunc_object.c#L1940

"intentional" and "sensible" are not always the same thing :-). That
said, it isn't totally obvious to me what the correct behaviour for
einsum is in this case.

> and the code makes it very explicit that input argument dimensions with the
> same label are broadcast to a common shape, see here:
>
> https://github.com/numpy/numpy/blob/master/numpy/core/src/umath/ufunc_object.c#L1956
>
> I kind of expect numpy to broadcast whenever possible, so this doesn't feel
> wrong to me.

The case Chuck is talking about is like if we allowed matrix
multiplication between an array with shape (n, 1) with an array with
(k, m), because (n, 1) can be broadcast to (n, k). This feels VERY
wrong to me, will certainly hide many bugs, and is definitely not how
it works right now (for np.dot, anyway; apparently it does work that
way for the brand-new gufunc np.linalg.matrix_multiply, but this must
be an accident).

> That said, it is hard to come up with convincing examples of how this
> behavior would be useful in any practical context. But changing something
> that has been working like that for so long seems like a risky thing. And I
> cannot come with a convincing example of why it would be harmful either.

gufuncs are very new.

-n

-- 
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Reply via email to