[Numpy-discussion] broadcasting behavior for 1.6 (was: Numpy 1.6 schedule)

[Ralf Gommers]

I'm just going through the very long 1.6 schedule thread to see what
is still on the TODO list before a 1.6.x branch can be made. So I'll
send a few separate mails, one for each topic.

On Mon, Mar 7, 2011 at 8:30 PM, Francesc Alted <faltet at pytables.org> wrote:
> 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.

The conclusion on this topic, as I read the discussion, is that we
need to keep backwards compatible behavior (even though the proposed
change is more intuitive). Has backwards compatibility been fixed
already?

Ralf