Hi Dag, On Sun, Oct 26, 2008 at 5:02 AM, Dag Sverre Seljebotn <[EMAIL PROTECTED]> wrote: > dieter h wrote: >> Hi all, >> >> What would be an 'elegant' way to handle dynamic casting? >> >> For instance, I have a numpy.recarray.data buffer (char*) that I want >> to iterate (pointer arithmetic) and manipulate in cython. What would >> be an elegant way to dynamically cast the char* to the type of the >> heterogeneous elements? Obvious to say, these are unknown at compile >> time. > > I would say that is highly unobvious, in most cases you know the type?
Well in terms of generlization, I wouldn't. > > Make sure to chech whether you have a contiguous array: > > if not arr.flags['C_CONTIGUOUS']: raise ... > >> Utilizing tokenization in a C macro is all that I've thought up so >> far, considering I'm a self-taught, still studying student of CS. :) > > Not sure if I know what you mean... Well I'm trying to abstract out the flow control of the casting, as decided by the type string given by the rec.dtype.fields[NAME].dtype.str. This can't be done by a function in C (i.e., no c++ like templates). So I assumed a C macro that deposits a type token into the C (cython) source. I'm not well versed in macro abilities so I could very well be wrong here. > > All together I know too little about the problem you have to give a good > answer (is speed or clarity most important? And so on), Yes efficiency is the issue, considering I'm mostly working with iterations for lengths of 10**9 and beyond. Also, I'm avoiding python objects where possible. I'm loading the recarray's data and metadata into C types and iterate the buffer via pointer arithmetic; then manipulating the elements through gnu c functions. > and also this is > a generic programming question and not at all Cython-related. Well kind of, but not necessarily since I'm implementing in cython. Not to mention it's kind of tough feelin' your way around when your self taught, I'd say. So I sincerely thank you for your time. > > Assuming what you want to do is converting the recarray to a Python > representation (to make an example -- what do you really do if you do > not know the types?), what I'd do is create classes for reading each type: > > cdef class ReadNext: > cdef object read_next(char** pptr): pass > > cdef class ReadInt: > cdef object read_next(char** pptr): > int** typed = pptr > result = **pptr > *pptr += 1 # Increment the "reading-head" you use > > ... repeat for all types ... > > cdef class ReadStruct: > cdef __init__(self, list_of_sub_readers): ... > cdef object read_next(char** pptr): > ...iterate subreaders to do your stuff and return a tuple ... > > > Then, "parse" the dtype of the recarray to construct a tree of these > readers (that's only done once per array, so consider it O(1)), and then > you simply feed your buffer to the root reader. > > Lots of polymorphic dispatches though, but unless you know the type at > compile-time... I suppose using if-tests/switches on the type *might* be > faster, but I'm no C/performance expert on that level, and this looks a > lot cleaner. Well I've got a feel for the logic in the example above. Thank you very much. -dieter > > -- > Dag Sverre > _______________________________________________ > Cython-dev mailing list > [email protected] > http://codespeak.net/mailman/listinfo/cython-dev > _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
