dieter h wrote:
> 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.
If speed is critical, nothing can beat
cdef struct CompleteStruct:
int a
int b
CompleteStruct* typed = <CompleteStruct*>arr.buf
And when it comes to speed, this /has/ to be somehow bound at
compile-time, there's simply no way around it (well, you can dynamically
compile code, i.e. moving the compile-time stage forward a bit). Even
C++ templates can't help you there -- all your C++ templates would need
to be instantiated explicitly at compile-time. So something
super-generic (and at the same time efficient) getting flow control from
rec.dtype.fields[NAME].dtype.str is diffcult no matter what you do.
The best you can do (with either C macros or C++ templates) is to create
a generic library function which allows the user to pass in arbitrary
struct definitions at compile-time.
But yes, the closest thing you will get to C++ templates is using C
macros. I've posted some proposals to add this functionality to Cython
in various ways, and the response was postive, but unfortunately I'm not
close to having the time to follow through on them and actually
implement it. (And even then it wouldn't buy you more than C++
templates, which as I said I do not believe would solve your problem.)
--
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
