[Numpy-discussion] Is this a bug?

Sebastian Berg sebastian at sipsolutions.net
Wed Sep 17 04:30:30 EDT 2014


On Di, 2014-09-16 at 16:51 -0400, Nathaniel Smith wrote:
> On Tue, Sep 16, 2014 at 4:31 PM, Jaime Fernández del Río
> <jaime.frio at 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).

Agreed, the only argument to not change it right away would be being
afraid of breaking user code abusing the kind of thing Josef mentioned.

- Sebastian

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20140917/a16f8b1a/attachment.sig>


More information about the NumPy-Discussion mailing list