On Wed, Sep 17, 2014 at 3:01 PM, Jaime Fernández del Río < jaime.f...@gmail.com> wrote:
> On Wed, Sep 17, 2014 at 1:27 PM, Charles R Harris < > charlesr.har...@gmail.com> wrote: > >> >> >> On Wed, Sep 17, 2014 at 6:57 AM, Charles R Harris < >> charlesr.har...@gmail.com> wrote: >> >>> >>> >>> On Wed, Sep 17, 2014 at 6:48 AM, Sebastian Berg < >>> sebast...@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. Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
