<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mi, 2014-09-17 at 06:33 -0600, Charles R Harris wrote:<br>
><br>
><br>
<snip><br>
<span class="">><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><div>Right. It is possible to check all these things in the loop, but the loop code grows..<br>. <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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><div>With regards to the main topic, we could extend the signature notation, using `[...]` instead of `(...)' for the new behavior.<br><br></div><div>Chuck <br></div></div></div></div>