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

[Francesc Alted]

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