<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Sep 23, 2014 at 4:31 PM, Charles R Harris <span dir="ltr"><<a href="mailto:charlesr.harris@gmail.com" target="_blank">charlesr.harris@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Tue, Sep 23, 2014 at 4:59 PM, Charles R Harris <span dir="ltr"><<a href="mailto:charlesr.harris@gmail.com" target="_blank">charlesr.harris@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Hi All,<br><br></div>The question has come up as the whether of not to treat the new gufunc behavior as a bug fix, keeping the old constructor name, or have a different constructor. Keeping the name makes life easier as we don't need to edit the code where numpy currently uses gufuncs, but is risky if some third party depends on the old behavior. The gufuncs have been part of numpy since the 1.3 release, and google doesn't turn up any uses that I can see apart from repeats of numpy code. We can also make fixes if needed during the 1.10 beta release cycle. Even so, it is a bit of a risk. To spread the blame, if any, please weigh in on the following.<br><br></div><ol><li>Yes, it is a bug, keep the current name and fix the behavior.</li><li>No, we need to be conservative and use a new function.</li></ol><p></p></div></div></blockquote></div></div><div>To clarify the changes. Currently, if an input array does not have as many dimensions as indicated by the signature, it is filled out with ones to match the signature as well as broadcasting to the other array. It is also the case that if a dimension in the signature is 1, then it is broadcast with the data in the other signature. That is, the parts identified in the signature are treated as little arrays. The proposed change is to require that the inputs have at least as many dimensions as the signature and that dimensions of 1 are not broadcast. That is, the parts identified in the signature are treated as vectors or matrices rather than little arrays.<br></div></div></div></div></blockquote><div><br></div><div>It looks like we get to keep all the blame to ourselves... ;-)</div><div><br></div><div>After sleeping on it, I am leaning more and more towards Nathaniel's proposal. Make it a bug, but leave it ready to be a warning if needed, preferably triggered by something like #define STRICT_SIGNATURE and a bunch of #ifdef's scattered through the code. It shouldn't be much more work than what already is in place. We would merge another commit right before the beta cycle removing the unused code, and if anyone complains revert that commit, remove the #define, and keep it for one release before deprecating it.</div><div><br></div><div>Testing for both possibilities is going to be a little trickier to get right, but should be doable.</div><div><br></div><div>Jaime</div><div> </div></div>-- <br>(\__/)<br>( O.o)<br>( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes de dominación mundial.
</div></div>