On May 11, 2008, at 3:41 AM, Greg Ewing wrote: > Robert Bradshaw wrote: >> On May 11, 2008, at 2:50 AM, Greg Ewing wrote: >> >>> Will it be legal to do something like >>> >>> cdef class B(A(len=10)): >> >> No, I don't think the above would be allowed. > > That would sidestep some problems, I suppose, although > it would make it less of a general parameterised-types > mechanism.
Yes, that is true. We are not trying to re-invent C++ here (which is powerful but at the expense of a much steeper learning curve). > 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. > > Are you sure it will be possible to write a __getitem__ > that deals with all that in its full generality while > still providing the efficiencies you're after? What > would such a __getitem__ implementation look like? I would imagine it would look a lot like the actual implementation of NumPy's current __getitem__ (well, after inlining some of the function calls, the current code does the actual work several levels down). Actually, probably more realistically, it would handle some of the simpler cases (one-dimensional for sure), and have an "else" clause that calls the current very-generic code (which stands the least to gain from an overhead-reducing perspective anyways). One hitch would be coming up with a nice syntax for handling a variable number of dimensions. If that wasn't feasible, hardcoding the method for 1, 2, and 3 dimensions would handle (I bet) most of cases, and it would call of to more generic code if the dimension was larger. Related to this I am pretty sure we want to implement polymorphism for cdef (and perhaps special) methods. > Also, as well as accessing single items, there's slicing > to consider. Is it going to be feasible to write a > __getitem__ and a __setitem__ that work together such > that things like > > a[i:j, k:l] = b[x, y, i:j, k:l] > > do the right thing efficiently? Ah, that certainly is quite the challenge :-). Unwrapping it into a single loop that does the copy would be tricky (for one thing, the analysis would have to happen on a much higher level) but I think the right hand side can do things with strides to avoid any copying, and the assignment would do the efficient loop. This may actually already be quite efficient--the big performance hits come when one wants to manipulate elements one-by-one (rather than as blocks, for which NumPy has efficient code). - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
