On Jul 5, 2008, at 2:09 AM, Dag Sverre Seljebotn wrote: > 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).
I think we want to have the actual type of the array (e.g. what is returned on arr[0]) in the type spec rather than forcing users to manually translate between "i" and it. If I understand correctly, the issue here is how to map cython/c types to the "format" string of the buffer. There are three things to match: Numeric type (int/float)--this can be detected at compile time by (<type>1)/(<type>2) == 0 vs the buffer format string Signed--this can be detected at compile time by (<type>-1) < 0 vs the buffer format string Size--this can be detected at compile time by sizeof() vs the "itemsize" field of the buffer, or calcsize from the struct module if you need. All other types are required to match exactly (or something like that, some thought would have to be put into how to handle objects). For hybrid types I think it would be enough to just look at the total size after comparing the structs for (int/float/other and signed/ unsigned). Then you could use numpy.uint and numpy.unit32, etc. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
