The more I look into this the more of a total mess it seems:
sage: pari(1.2345).precision() , pari('1.2345').precision()
(3, 4)
sage: pari(1.2345).python() , pari('1.2345').python()
(1.23449999999999993, 1.2345000000000000000000000000000000000)
sage: pari(1.2345).python().prec() , pari('1.2345').python().prec()
(64, 128)
not to mention this:
sage: pari((1.2345).str()).precision()
210
sage: pari((1.2345).str()).python().parent()
Real Field with 6656 bits of precision
-- that's right, you turn an honest 53-bit real to a string, it turns
into a pari real with precision 210 (words) which gets turned back
into 6656 bits (on 32 bits; for some reason on 64 bit machine it only
comes back with 128 bits precision).
-- and that's after I had become convinced that the mpfr -> pari real
conversion was done via strings!
Karim tells me that in the current (so-called) SVN version the
precision stuff is clearer and, more importantly, the documentation
for the whole of libpari is vastly better. I have not checked it out
yet. But that means that whatever we do now might have to change when
that unstable pari version becomes stable enough for Sage to adopt.
On the other hand, the current situation is so terrible that it just
has to be fixed properly. It would be better if more than one person
did it, perhaps? I don't think we can make this a blocker for 3.1.2
but surely it should be for 3.1.3?
John
2008/9/5 mabshoff <[EMAIL PROTECTED]>:
>
>
>
> 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
-~----------~----~----~----~------~----~------~--~---
