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.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).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 >
signature.asc
Description: This is a digitally signed message part
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
