A Sunday 06 March 2011 06:47:34 Mark Wiebe escrigué: > I think it's ok to revert this behavior for backwards compatibility, > but believe it's an inconsistent and unintuitive choice. In > broadcasting, there are two operations, growing a dimension 1 -> n, > and appending a new 1 dimension to the left. The behaviour under > discussion in assignment is different from normal broadcasting in > that only the second one is permitted. It is broadcasting the output > to the input, rather than broadcasting the input to the output. > > Suppose a has shape (20,), b has shape (1,20), and c has shape > (20,1). Then a+b has shape (1,20), a+c has shape (20,20), and b+c > has shape (20,20). > > If we do "b[...] = a", a will be broadcast to match b by adding a 1 > dimension to the left. This is reasonable and consistent with > addition. > > If we do "a[...]=b", under 1.5 rules, a will once again be broadcast > to match b by adding a 1 dimension to the left. > > If we do "a[...]=c", we could broadcast both a and c together to the > shape (20,20). This results in multiple assignments to each element > of a, which is inconsistent. This is not analogous to a+c, but > rather to np.add(c, c, out=a). > > The distinction is subtle, but the inconsistent behavior is harmless > enough for assignment that keeping backwards compatibility seems > reasonable.
For what is worth, I also like the behaviour that Mark proposes, and have updated tables test suite to adapt to this. But I'm fine if it is decided to revert to the previous behaviour. -- Francesc Alted _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
