Robert Bradshaw wrote: > 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
That's where we disagree. I think there should be three types with different behaviour: a dynamic array type that allocates memory and two different view types with different (arithmetic etc.) behavior. I defined all three of them in an earlier post. > not > have separate types with different semantics that one would have to > cast between. It's not a cast, it's more of a "create a view object for this buffer or array". That's why I say it should look like an object creation. If Cython optimises the object creation away or not, if it uses a different type, or if it does exactly what the source indicates is an implementation detail. > Buffers and memory views are mostly abstractions and > generalizations of ndarray that have been added to Python. Totally not. The first two are views, the latter is an object that contains data. You can have tons of views, but only one data container. Views can have different ways of modifying the container (such as a sequence or SIMD way), but there is only one way per view type, and one way per container. > 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. We agree on that. >>> 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]. I already asked what syntax you wanted to have for a non-SIMD memory view. Imagine we found a need for a third type of view one day. We can't keep coming up with new ways of overriding syntax when we already have a perfect way of instantiating *any* kind of view - simply by instantiating its type. >>> 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. That's not what I meant. I meant to say that it would be a compile time error to try to subtype the SIMD type at all. It's a special type for which some things don't work, just like some things don't work with cdef classes that work perfectly with Python classes (e.g. multiple inheritance). That also leave a future path open if we ever figure out a way to make subtyping possible (and meaningful). >>> 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. I think both the dynamic array type and the typed memory view type can be implemented externally, while an optimised SIMD type requires compiler support. I'm fine with all three, and I'm also ok with an array or memory view type that benefits from some kind of compiler support (although I think we should keep things out that can be kept out). > 2) A magic extension class that the compiler knows about and inlines/ > emulates operations for optimization purposes, e.g. CythonArray[int, > ndim=2]. Perfectly ok. > 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. Details again, but if that's really required, well, then it's required. > 4) Syntactic sugar like int[:,:] which means the same thing as > CythonArray[int, ndim=2]. I'm against that, because I can't see why we should have syntactic sugar for one type of view but not for another (or even a couple of other types). > 5) The syntactic sugar is the new syntax, rather than introducing the > CythonArray keyword. Same as above: adding a syntax for one type of view but not for another is not a good way of evolving the language. We may add a syntax later on iff we ever see that a) it's used very frequently and b) users complain about the lengthy spelling and c) we don't have a better thing to throw a specific syntax on. Until then, I'm against syntactic sugar for a very special subset of a larger number of use cases. Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
