[Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)

Francesc Alted faltet@pytables....
Mon Mar 7 06:30:30 CST 2011

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

More information about the NumPy-Discussion mailing list