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. Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion