On Fri, Sep 5, 2008 at 2:48 PM, John Cremona <[EMAIL PROTECTED]> wrote:
>
> 2008/9/5 Carl Witty <[EMAIL PROTECTED]>:
>>
>> On Sep 5, 9:40 am, "John Cremona" <[EMAIL PROTECTED]> wrote:
>>> The more I look into this the more of a total mess it seems:
>> ...
>>> 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).
>>
>> On my Sage 3.1.1 build (Debian testing, 32-bit x86), I get:
>> sage: pari((1.2345).str()).precision()
>> 5
>> sage: pari((1.2345).str()).python().parent()
>> Real Field with 96 bits of precision
>>
>> which is not nearly so wrong.
>>
>> Are your results repeatable if you restart Sage? Maybe something is
>> setting the Pari precision and forgetting to reset it?
>
> That may well be -- but there is a fundamental *mistake* in the way
> precision in the pari library is handled in Sage.
Yep, no doubt due to yours truly.
> 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.
> !
Excellent. I very very very much hope you will get this sorted out.
-- William
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
