[Numpy-discussion] Changes to the generalized functions.

Jaime Fernández del Río jaime.frio at gmail.com
Wed Sep 24 16:54:38 EDT 2014


On Tue, Sep 23, 2014 at 4:31 PM, Charles R Harris <charlesr.harris at gmail.com
> wrote:

>
>
> On Tue, Sep 23, 2014 at 4:59 PM, Charles R Harris <
> charlesr.harris at gmail.com> wrote:
>
>> Hi All,
>>
>> 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.
>>
>>
>>    1. Yes, it is a bug, keep the current name and fix the behavior.
>>    2. No, we need to be conservative and use a new function.
>>
>> 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.
>

It looks like we get to keep all the blame to ourselves... ;-)

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.

Testing for both possibilities is going to be a little trickier to get
right, but should be doable.

Jaime

-- 
(\__/)
( O.o)
( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes
de dominación mundial.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20140924/9cc0cdd1/attachment.html>


More information about the NumPy-Discussion mailing list