Stefan Behnel wrote: > Dag Sverre Seljebotn wrote: >> Stefan Behnel wrote: >>>> 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 :-) > > Yes, and I skipped over it because that was a tiny section titled > "numerical calculations". It was far from obvious to me that that was the > main point of the proposal.
It was intended as a demonstration of what went before. Anyway, communication is hard. Sorry. (When the dust has settled I'll revise the CEP.) (I wouldn't say the main point of the proposal as such, but it would be the main reason why it would make sense to just as well make this a builtin feature and not just something in a library, due to implementation constraints.) >> 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 > > Are you sure you always know where the parallelism ends? If a function takes "object", you have to assume it means to take the whole array and not its elements. I think that is it. (There are pretty standard rules for how to deal with multiple arguments etc. too). >> 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): ... > > Not if we can avoid it in any way. Well that's how you'd do it in Python (given the right elementwise decorator). >> 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. > > I don't have the impression that this proposal is accepted yet. I had that impression until now (except for the syntax bit, where you wanted to use int[:] for a list-style type. Or are you suggesting to use + for multi-dimensional concatenation as well?) I guess that was before we cleared up the SIMD misunderstanding though. So I'll revise my impression -- obviously, if you say so, there's still problems. Rather than us discussing this I think it might be more constructive though if you comment on Robert's first email about this yesterday? He tends to put things in a different way from me. -- Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
