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.
David
On Wed, Mar 30, 2011 at 01:48, Simon King <simon.k...@uni-jena.de> wrote:
> Hi Florent,
>
> On 29 Mrz., 21:54, Florent Hivert <florent.hiv...@univ-rouen.fr>
> wrote:
> > So it seems that there is no difference... Well actually I just figured
> out
> > that this has something to do with Cython: if I change
> >
> > class End(object):
> >
> > to
> >
> > class End(SageObject):
> >
> > Then:
> >
> > sage: timeit('obj_long.toto()',number=10^6)
> > 1000000 loops, best of 3: 9.22 s per loop
> > sage: timeit('obj_end.toto()',number=10^6)
> > 1000000 loops, best of 3: 203 ns per loop
>
> I think, the question is (at least on the short run), how one can work
> around.
>
> Taking your example:
> class End(SageObject):
> def toto(self):
> return 1
> sage: c_long = long_mro(500)
> sage: obj_long = c_long()
> sage: obj_end = End()
> sage: timeit("obj_end.toto()")
> 625 loops, best of 3: 963 ns per loop
> sage: timeit("obj_long.toto()")
> 625 loops, best of 3: 22.8 µs per loop
>
> So, as you confirmed, a long mro matters, at least if Cython is
> involved.
>
> But it seems possible to speed things up by offering a short path:
> sage: c_long.toto = End.toto
> sage: timeit("obj_long.toto()")
> 625 loops, best of 3: 2.55 µs per loop
>
> My question is:
> Is it good or at least acceptable practice to do things like
> class MPolynomialRing_polydict( MPolynomialRing_macaulay2_repr,
> PolynomialRing_singular_repr, MPolynomialRing_generic):
> ...
> base_ring = CategoryObject.base_ring
> base = CategoryObject.base
> ...
>
> cdef class MPolynomial(CommutativeRingElement):
> ...
> parent = Element.parent
> ...
>
> The example above indicates that it would very well speed things up.
> Or is there a good reason to avoid that short path?
>
> 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
>
--
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
