On May 13, 2008, at 8:28 AM, Lisandro Dalcin wrote:
> On 5/13/08, Robert Bradshaw <[EMAIL PROTECTED]>
>
>> I am having trouble understanding exactly what you're trying to
>> accomplish
>> here--what is the correspondence between strides and cstrides, and
>> how will
>> they be kept in sync?
>
> I'm just introducing a naming convention for faster access to C-level
> atributes that is simple to remind. And the sync between cshape and
> shape is in charge of numpy. Of course, if you modify 'cshape' and do
> not update yourself 'cstrides', then you get what you deserve (and a
> good point for the future Cython to support something like 'const')
>
>> Why not let a.ndim be the c attribute that gets
>> coerced to a python attribute when needed?
>
> Well, that is easy, a ndim is just an integer!
>
> For some types where coercion is
>> not possible (e.g. the int* shape) then it could transform the
>> above to
>> (<object>a).shape and be implemented via the property: __get__
>> mechanism as
>> at
>> http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/version/
>> Doc/Manual/extension_types.html#Properties
>> (if it exists?).
>
> And then you get a tuple, not a plain C array...
You get a tuple *only* if you try and use it as a python object.
Otherwise it's C access as usual.
>> Not having two names that point to the same thing is one of
>> the whole points of cpdef functions, this seems to be going
>> backwards with
>> attributes.
>
> Agreed, but I believe that in the case of 'cshape'/'shape', they are
> not actually similar, one is a pointer, and other is a tuple. Of
> course, if we can make Cython to coerce the 'cshape' to a tuple ONLY
> when it is requiered, ie, ' cdef object s = ary.cshape ', then that
> would be great.
Exactly.
>
> Also, taking Python code and having to change all the names to
>> get Cython to optimize it (thus rendering it incompatible with
>> pure Python)
>> seems like an undesirable thing too. Maybe I'm missing something...
>
> You are talking about optimization, but you are proposing that
> 'a.shape' being accessed to the descriptor mechanism, which will
> always return a tuple. At this point, I'm a bit confused about your
> comments. The descriptor saves you the attribute lookup, but still get
> a Python-level object, and their access is not as fast as a plain
> C-array.
>
> Furthermore, you commented about 'cpdef' functions. Well, If we want
> to take advantage of them, we DO HAVE to change pure-python source
> code to take advantage of it. However, I remember that there were
> comments about making this automatic.
Yes. But the point was before there were (in our codebase at least)
starting to be lots of instances of
def foo(self, ...):
return foo_c(self, ...)
def foo_c(self, ...):
...
and one would have to remember which one to call from python vs. cython.
> However, I do not see why my proposal interferes with the yours. For
> numpy arrays, 'shape' could be still looked up via the descriptor way,
> returning a tuple, but 'cshape' can be still there for power users
> that want to get even faster access.
My proposal is that for someone coming from using NumPy from Python,
they only need declare their object (say x) as being a numpy array,
and then all access to x.shape is suddenly faster rather than having
to remember a new way to access shape, ndim, etc.
- Robert
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
