On Jun 19, 2009, at 12:28 AM, Stefan Behnel wrote: > Robert Bradshaw wrote: >> On Jun 18, 2009, at 9:36 PM, Stefan Behnel wrote: >>> 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 behaves very different, though. For one, it's not a memory > allocated > data object but a *view* on such a thing, just like the typed > memory view. > What syntax would you propose for the memory view, and if none, why > not?
The proposal is to give our memory view types SIMD semantics, not have separate types with different semantics that one would have to cast between. Buffers and memory views are mostly abstractions and generalizations of ndarray that have been added to Python. What we want is to be able to treat these objects as one would treat numpy arrays, but with more room for optimization and more flexibility in the back end. >> 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. > > That's an implementation detail, not a language 'feature'. > >> 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. > > No, that would be the array type, which has no SIMD behaviour. int[], int[10], int*, and int[:] would be distinct types with different behaviors, but I think they have more in common (from a use point of view) than SomeType[int]. >> 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, > > Fine, trying to do so is a compile time error then. Give it a good > error > message saying you're "sorry but performance dictates an immutable > type > here" and every user will be happy. Perhaps we could add a final keyword to methods, but it would be messy to disallow Python subclasses, and still wouldn't allow the kind of optimization that can be done if the compiler knows that it's a SIMD type. >> 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. > > Details, details. I don't think it's just details, I think it's an important user interface issue. The syntax changes how one thinks about these things, and also impacts readability. Trying to understand your point of view, what of the following are you against: 1) Any compiler/language support for memory views and SIMD---they should be a library requiring no support from the compiler or language. 2) A magic extension class that the compiler knows about and inlines/ emulates operations for optimization purposes, e.g. CythonArray[int, ndim=2]. 3) Same as the above, CythonArray is really just a keyword--there's no actual extension class backing it since the compiler encapsulates its logic anyways. 4) Syntactic sugar like int[:,:] which means the same thing as CythonArray[int, ndim=2]. 5) The syntactic sugar is the new syntax, rather than introducing the CythonArray keyword. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
