[Numpy-discussion] Is this a bug?

[Jaime Fernández del Río]

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

I am guessing we still want to deprecate the old behavior in the next
release and remove it entirely in a couple more, right?

Jaime


> Chuck
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>


-- 
(\__/)
( 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/20140917/59609f35/attachment.html>