[Numpy-discussion] Is this a bug?
Charles R Harris
charlesr.harris at gmail.com
Wed Sep 17 16:27:30 EDT 2014
On Wed, Sep 17, 2014 at 6:57 AM, Charles R Harris <charlesr.harris at gmail.com
> 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:
>> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion