On Jun 9, 3:20 pm, David Harvey <[EMAIL PROTECTED]> wrote:
> On Jun 9, 2008, at 5:17 PM, Jonathan Bober wrote:
>
>
>
>
>
> > On Mon, 2008-06-09 at 10:19 -0700, mabshoff wrote:
>
> >> [...]
> >> No clue. Can you actually compare the gp binary from Sage directly
> >> with the timings from your self builid binary to eliminate the
> >> problem
> >> that libPari is involved here? If the gp binary in Sage is slower
> >> by a
> >> factor of three compared to the one you build this sounds like a bug
> >> to me. But it could also be conversation overhead for example.
>
> > Definitely could be conversion overhead. On my machine (warning: I'm
> > still running the "ridiculously old" Sage 2.10.2) I get
>
> > sage: time y = pari(40000).bernfrac()
> > CPU times: user 4.14 s, sys: 0.00 s, total: 4.14 s
> > Wall time: 4.15
> > sage: type(y)
> > <type 'sage.libs.pari.gen.gen'>
> > sage: time x = Rational(y)
> > CPU times: user 1.50 s, sys: 0.00 s, total: 1.50 s
> > Wall time: 1.50
>
> > It looks like the conversion from sage.lib.pari.gen.gen to
> > sage.rings.rational.Rational just converts y to a string and then
> > parses
> > the resulting string, which is why this takes so long.
>
> This is now
>
> http://trac.sagemath.org/sage_trac/ticket/3387
Good.
> (this ticket does not include the discrepancy in GP timings)
>
> david
Craig Citro did *a lot* of work on pari<->Sage conversation a while
back and there are still some cases open. So once Craig sees this he
might have some explanation what needs to get done since he knows the
code well and might already have something that was never submitted
since it needs cleanup.
Cheers,
Michael
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
