Stefan Behnel wrote:
> Stefan Behnel wrote:
>> Dag Sverre Seljebotn wrote:
>>> In every other programming language I know about with componentwise
>>> operations, the word "array" is used. "vector" is something you Coder
>>> People try to force down on us Numericals :-)
>>>
>>> (I know that the word is used like this in CS circles, but I prefer only
>>> using the word in contexts where the meaning is crystal clear (as in
>>> "vectorized operations") myself.)
>> Ah, so all you really want is a SIMD data type, right?
Right :-) Now linear algebra support in the compiler *would* be taking
things quite overboard (and probably only slow things down, unless N is
really small, like 4x4 3D game matrices...), I'm actually against that.
> ... which would then also support parallel operations as in
>
> some_int_array *= 2
>
> to multiply all entries by two, and
That's actually an example in the CEP :-)
> some_float_array = math.sqrt(some_int_array)
>
> to take the square-root of all entries in parallel?
Well, the issue here is function namespaces -- do we "misuse" the Python
library like this? But the idea -- certainly. At least it should be easy
to call C stdlib's sin in parallell on a double array.
And it should be possible to create custom functions to call in
parallel, either by
cdef extern from "stdlib.h":
double sin(double)
cdef myfunc(double x): ...
myfunc(sin(arr)) # SIMD, by convention, as we know they
# take single element
or, if people think that is too magic, by a decorator:
cdef extern from "stdlib.h":
@cython.array.elementwise
double sin(double)
@cython.array.elementwise
cdef myfunc(double x): ...
I suggest we deal with this particular issue much later though -- for
now it's nice to have a roadmap and figure out the syntax for
concatenateable vs. SIMD, but any actual work on componentwise
operations will happen after everything else works.
--
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
