On Sep 5, 7:56 am, "John Cremona" <[EMAIL PROTECTED]> wrote:
Hi John,
> I had some useful confirmation from Karim.
Nice.
> The pari library always and only measures precision in
> number-of-codewords, and the prec parameter in pari library functions
> always denotes this.
>
> For the gp interface (to pari) decimal precisions are used, as they
> are supposed to make more sense to humans (which they do).
>
> Sage interfaces with *both* libpari and gp, in different places. When
> it interfaces with libpari it needs to work with word lengths; for
> example in a function like the elliptic curve function pari_curve(),
> it makes no sense at all for the prec parameter of that function to be
> in decimal in the belief that that is what the pari library wants.
> It should be in bits, as in the rest of Sage, and that function can
> convert it to word-precision before calling the pari library function.
8)
> It seems that #4064, which most of you ignored as it was about
> elliptic curves ;) has some far-reaching consequences (since the pari
> library is used all over the place). I think a new ticket is
> therefore required (and I don't mind trying to take care of it). Or
> am I making a mountain out of a molehill?
Nope, I guess this is the root cause for
#3760 sage -t -long ell_finite_field.py fails with an out of memory
error on 32-bit intel os x.
too.
> John
Cheers,
Michael
> 2008/9/5 John Cremona <[EMAIL PROTECTED]>:
>
> > I think this is at the heart of the precision weirdness in converting
> > to/from pari reals.
>
> > Example:
>
> > sage: E = EllipticCurve('37a')
> > sage: E_pari = E.pari_curve()
> > sage: om = E_pari.omega()[0]
> > sage: om
> > 2.9934586462319596298320099794525081778
> > sage: om.precision()
> > 19
> > sage: om.python()
> > 2.9934586462319596298320099794525081777975837913701329853405233785632503569
> > 866829041203940673970514734358405271049472881941443872373720252543753766710
> > 932613753043332505965246252164473069072694510749057806365610445781725817135
> > 182427934263132488980086942438020870431669315444642401547655845084778595470
> > 0795671977773461040730510763
> > sage: om.python().prec()
> > 1088
> > sage: 1088 == (19-2)*64
> > True
>
> > The pari_curve object has been created with a *decimal* precision of
> > 19 *decimal* digits, but the conversion back to python reals has
> > interpreted this as 19 *words*, which is 1088 bits.
>
> > This is behind #4064 and who knows what else...
>
> > John
>
> > ---------- Forwarded message ----------
> > From: Bill Allombert <[EMAIL PROTECTED]>
> > Date: 2008/9/5
> > Subject: Re: precision() in pari
> > To: John Cremona <[EMAIL PROTECTED]>
> > Cc: Karim Belabas <[EMAIL PROTECTED]>
>
> > On Fri, Sep 05, 2008 at 03:13:44PM +0100, John Cremona wrote:
> >> Am I right in thinking that in the pari library, if x is a t_REAL,
> >> precision0(x) returns the decimal digit precision of x, just as the gp
> >> function precision (without the 0), while precision(x) returns the
> >> word length?
>
> > Yes! Actually there is the relation:
> > precision0(x)=(precision(x)-2)*log(2^32)/log(10)
> > (or 2^64 on a 64bit system)
>
> > Cheers,
> > Bill.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
