On Jun 19, 2009, at 3:09 AM, Stefan Behnel wrote: > Robert Bradshaw wrote: >> >> 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.
Ah, somehow I missed that this was an important point for you. I think we're all OK with a dynamic list type (that behaves like a python list of c types)--that would be really handy so most users will never even have to touch malloc. In terms of the two views, I see the SIMD type as a specialization (i.e extra features) of the "generic" memory view type, and have trouble seeing what it would provide that would make it incompatible with SIMD. > 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. We'll come to that when we need to. Probably just MemoryView[int, ndim=2] would be sufficient. But there is a large demand for an SIMD view type, and no one is coming up with a clear use for a strictly non-SIMD view type, which I think makes it special enough to merit special syntax. (The lack of native array types in other languages is one of the things that makes Fortran the language of choice for numerical programming.) >> 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. I guess I see this as the primary use case for memory views, but that's a difference of opinion. OK, then lets at least add this type without the syntactic sugar for now, and come back to it later. (Well, maybe not in the too distant future, but it's becoming like a bike-shedding thread right now.) - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
