On Jun 18, 2009, at 9:36 PM, Stefan Behnel wrote: > 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.
IIRC part of the motivation for int[:,:] syntax rather than special_name[int, ndim=2] was that the former is actually easier for humans to parse. Personally, it seems a natural extension of the int [50] syntax. It also makes it very clear to me that this is not some ordinary type implemented in some library, but a builtin type (like int[50]) that the compiler implements internally. This new type isn't really an object, it's a multi-dimensional set of ints, the same way int[10] or int* is a one-dimensional set of ints. Note that just implementing an extension class Foo, and using the buffer syntax on Foo is insufficient (subtypes (which may override Foo's behavior) are disallowed, compile-time slicing and arithmetic can't be performed without special magic, an actual, potentially redundant, instance of Foo would have to be created). Since the SMID type can't be a cdef class, I think it's an advantage to not have it look like it is one. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
