[Numpy-discussion] Is this a bug?

[Charles R Harris]

On Wed, Sep 17, 2014 at 3:29 PM, Charles R Harris <charlesr.harris at gmail.com
> wrote:

>
>
> On Wed, Sep 17, 2014 at 3:01 PM, Jaime Fernández del Río <
> jaime.frio at gmail.com> wrote:
>
>> On Wed, Sep 17, 2014 at 1:27 PM, Charles R Harris <
>> charlesr.harris at gmail.com> wrote:
>>
>>>
>>>
>>> On Wed, Sep 17, 2014 at 6:57 AM, Charles R Harris <
>>> charlesr.harris at gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Sep 17, 2014 at 6:48 AM, Sebastian Berg <
>>>> sebastian at sipsolutions.net> wrote:
>>>>
>>>>> On Mi, 2014-09-17 at 06:33 -0600, Charles R Harris wrote:
>>>>> >
>>>>> >
>>>>> <snip>
>>>>> >
>>>>> >
>>>>> > It would also be nice if the order could be made part of the
>>>>> signature
>>>>> > as DGEMM and friends like one of the argument axis to be contiguous,
>>>>> > but I don't see a clean way to do that. The gufuncs do have an order
>>>>> > parameter which should probably default to 'C'  if the arrays/vectors
>>>>> > are stacked. I think the default is currently 'K'. Hmm, we could make
>>>>> > 'K' refer to the last one or two dimensions in the inputs. OTOH, that
>>>>> > isn't needed for types not handled by BLAS. Or it could be handled in
>>>>> > the inner loops.
>>>>> >
>>>>>
>>>>> This is a different discussion, right? It would be nice to have an
>>>>> order
>>>>> flag for the core dimensions. The gufunc itself should not care at all
>>>>> about the outer ones.
>>>>>
>>>>
>>>> Right. It is possible to check all these things in the loop, but the
>>>> loop code grows..
>>>> .
>>>>
>>>>> All the orders for the core dimensions would be nice probably,
>>>>> including
>>>>> no contiguity being enforced (or actually, maybe we can define 'K' to
>>>>> mean that in this context). To be honest, if 'K' means that, it seems
>>>>> like a decent default.
>>>>>
>>>>>
>>>> With regards to the main topic, we could extend the signature notation,
>>>> using `[...]` instead of `(...)' for the new behavior.
>>>>
>>>
>>> Or we could add a new function,  PyUFunc_StrictGeneralizedFunction, with
>>> the new behavior. that might be the safe way to go.
>>>
>>
>> That sounds good to me, the current flow is that 'ufunc_generic_call',
>> which is the function in the tp_call slot of the PyUFunc object, calls
>> 'PyUFunc_GenericFunction', which will call 'PyUFunc_GeneralizedFunction' if
>> the 'core_enabled' member variable is set to 1. We could have a new
>> 'PyUFunc_StrictFromFuncAndDataAndSignature' that sets the 'core_enabled'
>> variable to e.g. 2, and then dispatch on this value in
>> 'PyUFunc_GenericFunction' to the new 'PyUFunc_StrictGeneralizedFunction'.
>>
>> This will also give us a better sandbox to experiment with all the other
>> enhancements we have been talking about: frozen dimensions, optional
>> dimensions, computed dimensions...
>>
>
> That sounds good, it is cleaner than the other solutions. The new
> constructor will need to be in the interface and the interface version
> updated.
>
>
>> I am guessing we still want to deprecate the old behavior in the next
>> release and remove it entirely in a couple more, right?
>>
>>
> Don't know. It is in the interface, so might want to just deprecate it and
> leave it laying around. Could maybe add an argument to the new constructor
> that sets the `core_enabled` value so we don't need to keep adding new
> functions to the api. If so, should probably be an enum in the include file
> so valid values get passed.
>
>
And then Ufunc in the code_generator could be modified to take both utype
(core_enabled value) and signature and use the new constructor.

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