Hi John,
I am about to put up a patch at #4064 (I'm adding a couple more doctests). It
is not perfect (it does not have proper doctests for 64 bit machines since I
don't have access to one), but I hope we can make it work soon.
Basically, I spent two days reading the libs/pari code and despairing about
precision, and then I realized that it is actually mostly ok, but that we're
misusing it terribly from schemes/elliptic_curves. So I did my best to fix
this. Part of this was to make all sage functions on elliptic curves use real
precision in bits, with a default value of RealField.precision() (which
currently is 53 bits).
Here is the post-patch-behavior for the various things you ran into:
sage: E = EllipticCurve('37a1').pari_curve()
sage: E[14].python().prec()
64
[Explanation: pari_curve() uses the default value of 53 bits, which gets bumped
up to 64 (the nearest word on 32-bit machines) by pari. Then it gets sent back
to sage with a precision of 64 bits.]
sage: [a.precision() for a in E]
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4, 4, 4, 4, 4]
[Explanation: the floats want default precision of 53 bits, pari bumps it up to
64 bits, which is 4 words = 2 for the float and 2 for the pari structure.]
sage: E = EllipticCurve('37a')
sage: E.period_lattice().basis(prec=30)[0].parent()
Real Field with 32 bits of precision
sage: E.period_lattice().basis(prec=100)[0].parent()
Real Field with 128 bits of precision
[Self-explanatory.]
Let me know what you think.
Alex
>
> That may well be -- but there is a fundamental *mistake* in the way
> precision in the pari library is handled in Sage. Internally pari
> only uses word-precision (to convert to bits you subtract 2 and
> multiply by 32 or 64), but the interface functions treat it as decimal
> precision. It's only in pari's own gp interface that decimal
> precision is used.
>
> This totally explains this:
> sage: pari.get_real_precision()
> 28
> sage: E = EllipticCurve('37a1').pari_curve()
> sage: E[14].python().prec()
> 256
>
> The variable whose value is returned by pari.get_real_precision() is
> the decimal precision which should only be used by the gp interface,
> But the pari_curve function calls pari's ellinit0 function with (as
> default) *this* number in its prec variable, while the prec variable
> is expecting a word-precision value. So the ellinit uses 28 word
> precision. Somehow that is changed to 10-word precision:
> sage: [a.precision() for a in E]
> [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 10, 10, 10, 10, 10]
> (the only floating point values are the ones at the end of the list)
> and then the conversion back to python computes 32*(10-2)=256.
>
> As you can see I have not quite traced everything through (where did
> those 10s come from?).
>
> Also, in a pevious posting in this thread I wrongly said that Sage
> (mpfr) reals were converted to pari reals via strings; they are not.
> In both directions the conversion is done properly using internal
> formats. So once we get the precisions sorted out it will be perfect.
> !
>
--
Alexandru Ghitza
Lecturer, Pure Mathematics
Department of Mathematics and Statistics
The University of Melbourne
Parkville, VIC, 3010
Australia
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
