Robert Bradshaw wrote:
> On Jul 29, 2008, at 1:00 PM, Dag Sverre Seljebotn wrote:
>
>> There's a lot of email today but as I finished one part I'm staking
>> out
>> the course again.
>>
>> I'm thinking about letting the class author specify default buffer
>> options. Something like this:
>>
>> cdef extern class Image ...:
>> __cythonbufferdefaults__ = {'ndim' : 2}
>> __cythonbuffermandatory__ = {'dtype': unsigned char, indirect=True}
>> __cythonbufferalways__ = True
>>
>> [1]
>>
>> I think this makes a lot of sense, as the author of the Image class
>> might export exactly this kind of buffer and nothing else. With the
>> above settings, one would automatically get efficient indexing on all
>> "cdef Image" instances.
>>
>> NumPy is kind of special in the flexibility it provides, but even
>> there,
>> setting indirect=False can provide a speedup transparently. Once the
>> indirect option is implemented at all, that is :-) but that *must*
>> happen to make NumPy as efficient as possible.
>>
>> As for priority, I guess this is below most of what I've talked
>> about so
>> far. Though it might suddenly look like a low hanging fruit that I go
>> for when I need a break from other stuff.
>>
>> [1] (Well, I consider custom parsing for that last line better than
>> inventing a wholly new syntax...and we've been talking about new
>> Python-style type references as well, which fits in here)
>
> This almost seems to magical for me, if one wants to use a buffer
> perhaps it is better to be explicit. But I'm curious to hear what
> other people think.
Let me just give one more concrete example for NumPy then. If you do
cdef ndarray[int, 2] buf
currently, then it is going to create code for checking whether it should
do indirect access, which is one if-test per dimension per lookup -- and
you *know* that for ndarrays, you can always get around with strided
access, i.e. something like
cdef ndarray[int, 2, 'strided'] buf
Now, I would kind of like to be able to tell people to use "object[int,
2]" to write a generic buffer algorithm, but "ndarray[int, 2]" to write
something that only works with NumPy in an optimized fashion, and that is
it -- and the proposal kind of grew out of that, it is a way of letting
the users not have to type mode="strided" all the time.
(BTW, do you like mode=different strings for this, or should I go with
"strided=True", "c=True", "fortran=True", etc? There will be two modes at
first: "full" and "strided", although if cython.buffer.bufptr is
introduced than "c", "fortran", "contig" will be useful as well.)
Of course I could only do this for the mode, but this doesn't seem to be a
special case --
though most buffer usecases seems to be even more fixed (if you have a
JPEG library why bother to specify the ndim and so on).
As for an option for automatically retrieving a buffer, I might agree.
Also I see the downside that it allows syntax like "JPEGImage[]" and
"MultiDimImage[3]".
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
