Hi, Dag Sverre Seljebotn wrote: > OK, I misunderstood you again. Breaking down what you say in two: > > 1) Syntax of SIMD view type. You propose SIMD[something] instead of > basetype[something] -- that can obviously be made to work. As all syntax > it is a matter of taste. I'll certainly go for whatever majority vote > says here, it's not very important to me, but I vote for > basetype[something] as it looks a lot more attractive for potential > numerical users IMO. > > 2) Acquisition. You could rewrite your example with my syntax like e.g. > this: > > obj = cython_array_type[int](20, 20) # create array object > cdef int[:,:] some_simd > some_simd = int[:,:](obj) > > IIUC you would just switch out int[:,:] with SIMD[...] to get something > close to what you want. > > Hmm. I actually like the explicitness that you propose. But it is a > matter of verbosity/repeating, as replacing line 3 with "some_simd = > obj" could only mean one thing. I'm +0 on this issue. > > In pure Python mode, one would definitely have to do "some_simd = > int[:,:](obj)" though.
Explicitness was a major reason for my counterproposal, yes. And I think the same would work in Python, where the SIMD type would be used to wrap a buffer/array object. The main reason was that I would prefer avoiding syntax overloading all over the place. Type specialisation is a new concept that is expected to use the [] syntax. We have the same syntax for buffers (which is also a kind of specialisation). We will use the same syntax for the future array type, which is at least closely related to buffers and should use C array syntax anyway. Having the same syntax for memory views and SIMD views sounds like an awful lot of things and a very unnecessary addition, since the same can be achieved using the normal type instantiation syntax and type specialisation on the SIMD/memory-view *type* (note the difference to using that syntax on just *any* type). The [] syntax makes a lot of sense for the new array type, it makes mostly sense for buffers, it was accepted (IIRC) for type specialisation. IMHO, that's a long enough distance that we go down that road. Going further would make the language less parseable to humans. I stripped the rest of your post with which I'm mostly fine. If we get a new SIMD type, why not give it real SIMD semantics, even if they may seem a bit weird at times. Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
