<html><body bgcolor="#FFFFFF"><div>This discussion is interesting and useful for NumPy 2.0, but the subtle change is not acceptable for NumPy 1.6.</div><div><br></div><div>The rules were consistent, even if seen as unintuitive by some.</div><div><br></div><div>The fact that two libraries we know of already had tests break should be a big red warning flag. There are a lot of other libraries that may have tests break. </div><div><br></div><div>Having to fix tests would be expected for NumPy 2.0, but not 1.6.</div><div><br></div><div>I am a big -10 for rolling out a change like this in NumPy 1.6</div><div><br></div><div>For NumPy 2.0, the discussion is interesting, but I am still a -0</div><div><br></div><div>Travis</div><div><br></div><div><br>--<div>(mobile phone of)</div><div>Travis Oliphant</div><div>Enthought, Inc.</div><div><a href="http://www.enthought.com">http://www.enthought.com</a></div></div><div><br>On Mar 11, 2011, at 10:51 AM, Charles R Harris <<a href="mailto:charlesr.harris@gmail.com">charlesr.harris@gmail.com</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div><br><br><div class="gmail_quote">On Fri, Mar 11, 2011 at 8:06 AM, Wes McKinney <span dir="ltr"><<a href="mailto:wesmckinn@gmail.com"><a href="mailto:wesmckinn@gmail.com">wesmckinn@gmail.com</a></a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
On Fri, Mar 11, 2011 at 9:57 AM, Charles R Harris<br>
<div><div></div><div class="h5"><<a href="mailto:charlesr.harris@gmail.com"><a href="mailto:charlesr.harris@gmail.com">charlesr.harris@gmail.com</a></a>> wrote:<br>
><br>
><br>
> On Fri, Mar 11, 2011 at 7:42 AM, Charles R Harris<br>
> <<a href="mailto:charlesr.harris@gmail.com"><a href="mailto:charlesr.harris@gmail.com">charlesr.harris@gmail.com</a></a>> wrote:<br>
>><br>
>><br>
>> On Fri, Mar 11, 2011 at 2:01 AM, Ralf Gommers<br>
>> <<a href="mailto:ralf.gommers@googlemail.com"><a href="mailto:ralf.gommers@googlemail.com">ralf.gommers@googlemail.com</a></a>> wrote:<br>
>>><br>
>>> I'm just going through the very long 1.6 schedule thread to see what<br>
>>> is still on the TODO list before a 1.6.x branch can be made. So I'll<br>
>>> send a few separate mails, one for each topic.<br>
>>><br>
>>> On Mon, Mar 7, 2011 at 8:30 PM, Francesc Alted <<a href="mailto:faltet@pytables.org"><a href="mailto:faltet@pytables.org">faltet@pytables.org</a></a>><br>
>>> wrote:<br>
>>> > A Sunday 06 March 2011 06:47:34 Mark Wiebe escrigué:<br>
>>> >> I think it's ok to revert this behavior for backwards compatibility,<br>
>>> >> but believe it's an inconsistent and unintuitive choice. In<br>
>>> >> broadcasting, there are two operations, growing a dimension 1 -> n,<br>
>>> >> and appending a new 1 dimension to the left. The behaviour under<br>
>>> >> discussion in assignment is different from normal broadcasting in<br>
>>> >> that only the second one is permitted. It is broadcasting the output<br>
>>> >> to the input, rather than broadcasting the input to the output.<br>
>>> >><br>
>>> >> Suppose a has shape (20,), b has shape (1,20), and c has shape<br>
>>> >> (20,1). Then a+b has shape (1,20), a+c has shape (20,20), and b+c<br>
>>> >> has shape (20,20).<br>
>>> >><br>
>>> >> If we do "b[...] = a", a will be broadcast to match b by adding a 1<br>
>>> >> dimension to the left. This is reasonable and consistent with<br>
>>> >> addition.<br>
>>> >><br>
>>> >> If we do "a[...]=b", under 1.5 rules, a will once again be broadcast<br>
>>> >> to match b by adding a 1 dimension to the left.<br>
>>> >><br>
>>> >> If we do "a[...]=c", we could broadcast both a and c together to the<br>
>>> >> shape (20,20). This results in multiple assignments to each element<br>
>>> >> of a, which is inconsistent. This is not analogous to a+c, but<br>
>>> >> rather to np.add(c, c, out=a).<br>
>>> >><br>
>>> >> The distinction is subtle, but the inconsistent behavior is harmless<br>
>>> >> enough for assignment that keeping backwards compatibility seems<br>
>>> >> reasonable.<br>
>>> ><br>
>>> > For what is worth, I also like the behaviour that Mark proposes, and<br>
>>> > have updated tables test suite to adapt to this. But I'm fine if it is<br>
>>> > decided to revert to the previous behaviour.<br>
>>><br>
>>> The conclusion on this topic, as I read the discussion, is that we<br>
>>> need to keep backwards compatible behavior (even though the proposed<br>
>>> change is more intuitive). Has backwards compatibility been fixed<br>
>>> already?<br>
>>><br>
>><br>
>> I don't think an official conclusion was reached, at least in so far as<br>
>> numpy has an official anything ;) But this change does show up as an error<br>
>> in one of the pandas tests, so it is likely to affect other folks as well.<br>
>> Probably the route of least compatibility hassle is to revert to the old<br>
>> behavior and maybe switch to the new behavior, which I prefer, for 2.0.<br>
>><br>
><br>
> That said, apart from pandas and pytables, and the latter has been fixed,<br>
> the new behavior doesn't seem to have much fallout. I think it actually<br>
> exposes unoticed assumptions in code that slipped by because there was no<br>
> consequence.<br>
><br>
> Chuck<br>
><br>
</div></div><div class="im">> _______________________________________________<br>
> NumPy-Discussion mailing list<br>
> <a href="mailto:NumPy-Discussion@scipy.org"><a href="mailto:NumPy-Discussion@scipy.org">NumPy-Discussion@scipy.org</a></a><br>
> <a href="http://mail.scipy.org/mailman/listinfo/numpy-discussion" target="_blank"><a href="http://mail.scipy.org/mailman/listinfo/numpy-discussion">http://mail.scipy.org/mailman/listinfo/numpy-discussion</a></a><br>
><br>
><br>
<br>
</div>I've fixed the pandas issue-- I'll put out a bugfix release whenever<br>
NumPy 1.6 final is out. I don't suspect it will cause very many<br>
problems (and those problems will--hopefully--be easy to fix).<br>
<div><div></div><div class="h5">__</div></div></blockquote><div><br>Now I'm really vacillating. I do prefer the new behavior and the fallout does seem minimal. Put me +1 for the change unless a strong objection surfaces.<br>
<br>Chuck <br></div></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>NumPy-Discussion mailing list</span><br><span><a href="mailto:NumPy-Discussion@scipy.org">NumPy-Discussion@scipy.org</a></span><br><span><a href="http://mail.scipy.org/mailman/listinfo/numpy-discussion">http://mail.scipy.org/mailman/listinfo/numpy-discussion</a></span><br></div></blockquote></body></html>