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.99345864623195962983200997945250817779758379137013298534052337856325035698668290412039406739705147343584052710494728819414438723737202525437537667109326137530433325059652462521644730690726945107490578063656104457817258171351824279342631324889800869424380208704316693154446424015476558450847785954700795671977773461040730510763
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
-~----------~----~----~----~------~----~------~--~---
