Stefan Behnel wrote:
> Hi,
>
> Dag Sverre Seljebotn wrote:
>> Currently, wherever a C type is used in Cython, it is enough to specify
>> sort-of what kind of class of type it is... the following will work all
>> right:
>>
>> cdef extern ...:
>> ctypedef int int8
>> ctypedef int int16
>> ctypedef int int32
>> ctypedef int int64
>>
>>
>> However, when types are used in buffers:
>>
>> cdef object[int16, 3] x
>>
>> one must translate the type (dtype) into a character representation (as
>> listed in http://docs.python.org/lib/module-struct.html).
>
> What about going the opposite way and either a) replacing the type definition
> in buffers by the type character entirely (not sure, but this might not work
> if you require a specific type name to appear in the C code), or b) by
> requiring users to provide both the type and the character in a suitable
> buffer declaration syntax?
Thanks, new ideas like that I was looking for!
After thinking about it it turns out that it won't really help for the
NumPy "int8/int16/..." types though; it will make the user code
potentially unportable:
cdef ndarray["i", 2] = zeros((10, 10), dtype=int32)
Making it part of the "ctypedef" syntax:
ctypedef int int32 [bufchar "i"]
would still mean #ifdefs in pxd files. In fact, I think it turns out
that the mapping to characters is not the real problem here; the mapping
to exact C types is (since the buffer interface will only carry across
native C types (the fact that they are encoded as characters is not
crucial here)).
I think my solution for now will be simply to drop the bit-size typedefs
from numpy.pxd and require exact ctypedefs. So one can still do
cdef numpy.ndarray[numpy.uint, 2] = ...
but not use "uint8" or any other bit-size-specific types. I can also
insert a simple check for sizeof(numpy.uint) == sizeof(unsigned int) in
the C code at module loading time for all types which are used in
buffers (it should be optimized away if things are ok, and will break
things early if not).
It looks like /usr/include/tgmath.h pulls what I want off; but the code
gets very ugly and only works on some compilers; a warning sign that I
perhaps don't want to do this but should go for the least obscure route
of requiring exact ctypedefs. Though perhaps I can use the floating_type
macro to add to the type check proposed above. Anyway, excerpt (I don't
understand a tenth of it yet though :-) ):
# define __floating_type(type) (((type) 0.25) && ((type) 0.25 - 1))
# define __tgmath_real_type_sub(T, E) \
__typeof__ (*(0 ? (__typeof__ (0 ? (double *) 0 : (void *) (E))) 0
\
: (__typeof__ (0 ? (T *) 0 : (void *) (!(E)))) 0))
...
# define __TGMATH_BINARY_REAL_IMAG(Val1, Val2, Fct, Cfct) \
(__extension__ (((sizeof (__real__ (Val1)) > sizeof (double) \
|| sizeof (__real__ (Val2)) > sizeof (double)) \
&& __builtin_classify_type (__real__ (Val1) \
+ __real__ (Val2)) == 8) \
? ((sizeof (__real__ (Val1)) == sizeof (Val1) \
&& sizeof (__real__ (Val2)) == sizeof (Val2)) \
? (__typeof ((__tgmath_real_type (Val1)) 0 \
+ (__tgmath_real_type (Val2)) 0)) \
__tgml(Fct) (Val1, Val2) \
: (__typeof ((__tgmath_real_type (Val1)) 0 \
+ (__tgmath_real_type (Val2)) 0)) \
...
#define cos(Val) __TGMATH_UNARY_REAL_IMAG (Val, cos, ccos)
--
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
