<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 17, 2014 at 3:01 PM, Jaime Fernández del Río <span dir="ltr"><<a href="mailto:jaime.frio@gmail.com" target="_blank">jaime.frio@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5">On Wed, Sep 17, 2014 at 1:27 PM, Charles R Harris <span dir="ltr"><<a href="mailto:charlesr.harris@gmail.com" target="_blank">charlesr.harris@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Wed, Sep 17, 2014 at 6:57 AM, Charles R Harris <span dir="ltr"><<a href="mailto:charlesr.harris@gmail.com" target="_blank">charlesr.harris@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Wed, Sep 17, 2014 at 6:48 AM, Sebastian Berg <span dir="ltr"><<a href="mailto:sebastian@sipsolutions.net" target="_blank">sebastian@sipsolutions.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On Mi, 2014-09-17 at 06:33 -0600, Charles R Harris wrote:<br>
><br>
><br>
<snip><br>
<span>><br>
><br>
> It would also be nice if the order could be made part of the signature<br>
> as DGEMM and friends like one of the argument axis to be contiguous,<br>
> but I don't see a clean way to do that. The gufuncs do have an order<br>
> parameter which should probably default to 'C'  if the arrays/vectors<br>
> are stacked. I think the default is currently 'K'. Hmm, we could make<br>
> 'K' refer to the last one or two dimensions in the inputs. OTOH, that<br>
> isn't needed for types not handled by BLAS. Or it could be handled in<br>
> the inner loops.<br>
><br>
<br>
</span>This is a different discussion, right? It would be nice to have an order<br>
flag for the core dimensions. The gufunc itself should not care at all<br>
about the outer ones.<br></blockquote><div><br></div></span><div>Right. It is possible to check all these things in the loop, but the loop code grows..<br>. <br></div><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
All the orders for the core dimensions would be nice probably, including<br>
no contiguity being enforced (or actually, maybe we can define 'K' to<br>
mean that in this context). To be honest, if 'K' means that, it seems<br>
like a decent default.<br>
<br></blockquote><div><br></div></span><div>With regards to the main topic, we could extend the signature notation, using `[...]` instead of `(...)' for the new behavior.<br></div></div></div></div></blockquote><div><br></div></div></div><div>Or we could add a new function,  PyUFunc_StrictGeneralizedFunction, with the new behavior. that might be the safe way to go.<br></div></div></div></div></blockquote><div><br></div></div></div><div>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'.</div><div><br></div><div>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...</div></div></div></div></blockquote><div><br></div><div>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.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>I am guessing we still want to deprecate the old behavior in the next release and remove it entirely in a couple more, right?</div><span class="HOEnZb"><font color="#888888"><div><br></div></font></span></div></div></div></blockquote><div><br></div><div>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.<br><br></div><div>Chuc<font color="#888888">k</font></div></div></div></div>