[Numpy-discussion] dot/tensordot limitations

Charles R Harris charlesr.harris@gmail....
Wed Apr 30 00:24:08 CDT 2008

On Tue, Apr 29, 2008 at 10:31 PM, Travis E. Oliphant <oliphant@enthought.com>

> Nadav Horesh wrote:
> > You open here a Pandora box:
> > What should I do if I want to run an operation on elements of an array
> which are not in the library. The usual answers are either use more memory (
> (A*B).sum(axis=1) ), or more time ([dot(A[i],B[i]) for i in len(A)]).
> >
> > Would your issue can be rephrase like this:
> > A way to iterate over array in the C level, where the function/operation
> is defined in the C level, without the overhead of python?
> >
> Quoting from the GeneralLoopingFunction wiki page:
> There seems to be a general need for looping over functions that work on
> whole arrays and return other arrays. The function has information
> associated with it that states what the basic dimensionality of the
> inputs are as well as the corresponding dimensionality of the outputs.
> This is in addition to information like supported data-types and so forth.
> Then, when "larger" arrays are provided as inputs, the extra dimensions
> should be "broadcast" to create a looping that calls the underlying
> construct on the different sub-arrays and produces multiple outputs.
> Thus, let's say we have a function, basic_inner, that takes two vectors
> and returns a scalar where the signature of the function is known to
> take two 1-d arrays of the same shape and return a scalar.
> Then, when this same function is converted to a general looping function:
> loopfuncs.inner(a, b)
> where a is (3,5,N) and b is (5,N) will return an output that is (3,5)
> whose elements are constructed by calling the underlying function
> repeatedly on each piece. Perl has a notion of threading that captures a
> part of this idea, I think. The concept is to have a more general
> function than the ufuncs where the signature includes dimensionality so
> that the function does more than "element-by-element" but does
> "sub-array" by "sub-array".
> Such a facility would prove very useful, I think and would abstract many
> operations very well.

Basically, element wise operations on elements that are subarrays;
generalized ufuncs, if you will. Sorting would be a unary type operation in
that context ;)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.scipy.org/pipermail/numpy-discussion/attachments/20080429/54d878c6/attachment-0001.html 

More information about the Numpy-discussion mailing list