Hi David,

On 30 Mrz., 08:00, David Roe <r...@math.harvard.edu> wrote:
> I think that base_ring and parent are cpdef'd methods (I don't want to look
> it up at the moment).  You want to be a little careful overriding such
> methods with Python functions living in the dictionary, because then the
> functions called by Cython code that knows the type of your object, and the
> code called by Python code will be different.

"base" is a Python method (I looked it up), and if one makes the class
End in Florent's example derive from Parent, then defining
  c_long.base = Parent.base
would still allow to do obj_long.base(), but makes the access to
"base()" almost 15 times faster.

I did some test with has_coerce_map_from. That method *is* cpdef. With
the patches from #9944, I get:

sage: R.<x,y> = ZZ['t'][]
sage: timeit("R.has_coerce_map_from")
625 loops, best of 3: 903 ns per loop
sage: R.__class__.has_coerce_map_from = Parent.has_coerce_map_from
sage: timeit("R.has_coerce_map_from")
625 loops, best of 3: 326 ns per loop
sage: R.has_coerce_map_from(ZZ)
True

So, providing the short path makes the attribute lookup almost 3 times
faster, but the method still works. Of course, that's not a proof that
it'll always work...

On the other hand, I remember that I have seen compiler warnings of
the type "overriding a Cython method by a Python method" or so. If
there are compiler warning then one should better not use short paths.

But what else?

Cheers,
Simon

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Reply via email to