[Cython] -dagss merge? + what next

[Dag Sverre Seljebotn]

Dag Sverre Seljebotn wrote:
> Robert Bradshaw wrote:
>> On Jul 29, 2008, at 2:25 AM, Dag Sverre Seljebotn wrote:
>>
>>> Those are the big tasks, but there are also a few smaller nice-haves I
>>> can go for (a "cython.shape" builtin that allows you to retrieve the
>>> shape information of a buffer, and so on).
>> I saw you mention shape (and other "magic" functions), and I'm  
>> curious. Could you elaborate?
> 
> When acquiring a buffer, you get hold of a lot of information that is 
> not currently exported -- shape is most important. For NumPy this is ok 
> as ndarray exports its shape field for efficient access, but without 
> another mechanism you can't write generic algorithms that work with all 
> buffers without passing the shape explicitly. This even leads to less 
> clean test case code...
> 
> I haven't thought much about the list (add as needed) but something like:
> 
> - shape(buf) -- Returns a tuple containing the shape of the buffer. 
> However, shape(buf)[0] should compile directly to __pyx_bshape0_buf. (I 
> thought about shape(buf, 0) as well but decided against, how about you?)
> 
> This would be the primary for-loop mechanism:
> 
> from cython import shape
> ...
> cdef int i
> for i in range(shape(buf)[0]): buf[i] = 9
> 
> - buffer(buf), strides(buf), suboffsets(buf) -- Could have these to 
> allow low-level access (buffer gets a void* directly, strides and 
> suboffsets probably). For contiguous arrays this could be more efficient 

...strides and suboffsets probably Py_ssize_t*. Sorry.



-- 
Dag Sverre