This should be of interest to anyone who has ever had to manage
precision issues between Sage and pari real and complex numbers (e.g.
Alex Ghitza). Others can move on.
In the conversion of a pari complex number back to Sage (in
sage/libs/pari/gen_py.py in the function python(z)), the precision of
the ComplexField in which the returned value should lie is taken to be
the *minimum* of the precisions of the real and imaginary parts of the
pari complex. Here I am assuming that both real and imaginary parts
are inexact, otherwise there is no issue; and note that a pari gen
object (type t_COMPLEX) can have different types, and also different
precisions, for the real and imaginary parts. And we *are* converting
properly between pari's precision measured in words and Sage's
measured in bits.
I propose to change this to the *maximum* of the two precisions.
I have been experimenting with the wrapping of the pari functions
ellwp0(), which essentially takes ((w1,w2),z) where (w1,w2) is a pair
of complex numbers defining a lattice L in C and z represents and
element of C/L, and returns the pair (P(z),P'(z)) where P() is the
Weierstrass P function. In some cases I find that the real and
imaginary parts returned by pari's function can have very different
precisions.
Example (using code now developed, so this will not work in the
released version of Sage):
sage: E = EllipticCurve([1,1,1,-8,6])
sage: P = E(0,2)
sage: L = E.period_lattice()
sage: z = L.elliptic_logarithm(P, prec=129)
Using the current min of the precisions (the exact value should be (0,2)):
sage: L.elliptic_exponential(z)
(-3.8805107275644938151041666666176877354e-11 -
2.7369110631344083416479093423631174439e-48*I,
2.0000000000194025536378224690755208333 +
4.1053665947016125124718640135446761659e-48*I)
Using the proposed max:
sage: L.elliptic_exponential(z)
(8.8162076311671563097655240291668425836e-39 -
2.7369110631344083416479093423631174439e-48*I,
2.0000000000000000000000000000000000000 +
4.1053665947016125124718640135446761659e-48*I)
I swear that the only change between those two is changing line 166 of
sage/libs/pari/gen_py.py from
prec =
min(gen.prec_words_to_bits(xprec),gen.prec_words_to_bits(yprec))
to
prec =
max(gen.prec_words_to_bits(xprec),gen.prec_words_to_bits(yprec))
Note that in this example I started with 129 bits precision; at 128 bits we get
sage: z = L.elliptic_logarithm(P, prec=128)
sage: L.elliptic_exponential(z)
(8.6692708373143703712694319620140618739e-38,
1.9999999999999999999999999999999999999)
(using min)
and the identical
sage: L.elliptic_exponential(z)
(8.6692708373143703712694319620140618739e-38,
1.9999999999999999999999999999999999999)
(using max)
which are the same. Here 128 bits is an exact number of words, while
129 forces pari to use an extra word most of which is garbage on
input, and somehow the effect is to catastrophically reduce the
precision of the output!
I just checked (using testall) that this change has no effect at all
on any doctests, so I propose to include it in my upcoming patch
(which implements the complex elliptic exponential for elliptic
curves, by a simple call to the already wrapped pari.ellwp0(), but
which has taken ages to sort out the precision properly.
John
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
