[Numpy-discussion] Changes to the generalized functions.

[Charles R Harris]

On Wed, Sep 24, 2014 at 2:54 PM, Jaime Fernández del Río <
jaime.frio at gmail.com> wrote:

> 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.
>

I've been headed the other way, but using a simplified name for the new
function: PyUFunc_FromFuncAndDataAndSignature2, which is along the lines of
PyArray_MatrixProduct and  PyArray_MatrixProduct2 in the numpy API. I do
like Nathaniel's suggestion, but I also like taking chances and need to
fight the urge ;)

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20140924/e7bf37bf/attachment.html>