[Numpy-discussion] dot/tensordot limitations
Travis E. Oliphant
Tue Apr 29 23:31:30 CDT 2008
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:
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.
More information about the Numpy-discussion