[Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)
Sat Mar 5 23:47:34 CST 2011
On Sat, Mar 5, 2011 at 8:13 PM, Charles R Harris
> On Sat, Mar 5, 2011 at 9:00 PM, Travis Oliphant <firstname.lastname@example.org>wrote:
>> My point is also that we need to make sure the broadcasting rules are
>> consistent for both addition and array copy.
>> Addition would not create an error if a (1,20) array was added to a (20,)
>> array. Therefore, a (1,20) array can also copied into a (20,) array --- as
>> can a (1,1,1,1,20) array. Conversely, a (20,1) or a (1,1,20,1,1) array can
>> not be copied into a (20,) array.
> Well, adding a (1,20) array to a (20,) array gives a (1,20) array. Changing
> this for assignment is like english spelling ( 'I' before 'e' except after
> 'c', or sounded 'a' as in neighbor and weigh -- with various exceptions) or
> having to learn to conjugate irregular verbs. Most illogical. That said, I
> suppose we have to support it for backward compatibility. It doesn't seem to
> be used that much, however, probably because it isn't obvious.
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,
The distinction is subtle, but the inconsistent behavior is harmless enough
for assignment that keeping backwards compatibility seems reasonable.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion