That's great, Alex, I also spent a lot of yesterday looking at the
same code. I look forward to seeing your patch and will test it on
both 32 and 64 bit machines.
John
2008/9/5 William Stein <[EMAIL PROTECTED]>:
>
> 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
-~----------~----~----~----~------~----~------~--~---
