> Another thing bothers me a bit. Your simple little > __getitem__ example is all very well, but a full-blown > NumPy array with multiple dimensions and strides and > whatnot is a rather complicated beast.
Robert's answered already but here's my thoughts on the matter. If you haven't read it already, I've written about this in my GSoC application: http://wiki.cython.org/DagSverreSeljebotn/soc/details Highlights: * It does rely on some pretty "advanced" compile-time inlining (which I've called unrolling a couple of places). To handle multiple dimensions one must ideally also inline loops of compile-time values (but *only* in functions marked with a @cython.unroll, you don't normally want loops unrolled). I've written about my thoughts on this here: http://wiki.cython.org/enhancements/inlining * If there's slices, simply hand them to the existing NumPy (i.e. (return (<object>self)[index]). (In particular, we should *not* inline slice copying, as that can potentially be handed to special MMX instructions etc. and is very CPU-specific). Multiple dimensions, negative indices etc. will probably be handled though. * It is possible to above is too utopic and one can say that it won't work. But, this is pretty much critical functionality for numerical Python use; and will be done anyway. If nothing else it will have to be implemented as a custom plugin to Cython, treating NumPy arrays as a language primitive type; but we really hope to find a way that is more in line with general Cython development. -- Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
