On Tue, Aug 26, 2008 at 4:23 AM, John Cremona <[EMAIL PROTECTED]> wrote:
>
> I already had a quick look at this when Hakan first posted, but came
> to no instant conclusion --
Given that the first output has the right precision and the second doesn't,
it's surely a simple to fix caching issue.
> except that there are quite a few
> functions in the Sage-pari interface where precision is impossible or
> difficult to set as one would hope.
? I think every Pari C library interface for which precision makes sense
has precision as a parameter. I think the way the wrapper code works
is the same as the way gp works -- you do
sage: old = pari.set_real_precision(100)
sage: pari comp
sage: pari.set_real_precision(old)
>
> For example:
> sage: P=EllipticCurve('37a1').gens()[0]; P.height()
> 0.0511114082399688
>
> The method ellheight of sage.libs.pari.gen.gen has no prec parameter
> though the pari function it calls does. I'm sure there are other
> places where the same happens. We could fix them piecemeal, or fo
> through the whole pari interface systematically, which would be a big
> job!
Or just use pari.set_real_precision. This is orthogonal though to the issue.
In pari when you ask for a given precision it can easily just give you more.
Sage shouldn't do that, so we have to round the output of pari in some cases.
William
>
> John
>
> 2008/8/26 William Stein <[EMAIL PROTECTED]>:
>>
>> On Fri, Aug 15, 2008 at 1:57 AM, Håkan Granath
>> <[EMAIL PROTECTED]> wrote:
>>>
>>> Hi,
>>>
>>> Is this a bug or am I doing something stupid? I get different
>>> precisions the first and second time I run the same command.
>>>
>>> ----------------------------------------------------------------------
>>> | SAGE Version 3.0.6, Release Date: 2008-07-30 |
>>> | Type notebook() for the GUI, and license() for information. |
>>> ----------------------------------------------------------------------
>>>
>>> sage: E = EllipticCurve('37a')
>>> sage: E.period_lattice().basis(prec=30)
>>>
>>> (2.993458646231959629832009979452508177797583791370132985340523378563250356987,
>>>
>>> 2.451389381986790060854224831866525225349617289144796614656471406129152899999*I)
>>> sage: E.period_lattice().basis(prec=30)
>>>
>>> (2.9934586462319596298320099794525081777975837913701329853405233785632503569866829041203940673970514734358405271049472881941443872373720252543753766710932613753043332505965246252164473069072694510749057806365610445781725817135182427934263132488980086942438020870431669315,
>>>
>>> 2.4513893819867900608542248318665252253496172891447966146564714061291528999992568928911321280291810887126842188696618479754751998666167558016789381647830306324546902881738259304962523119593946698932473794558796569481958707269691493740581897037588157844669302474334546641*I)
>>>
>>>
>>> Best regards,
>>>
>>> Håkan
>>
>>
>> This is definitely a bug. The output precision should be as given by
>> the prec option. The bug is caused by a mistake in the caching code,
>> surely. This will likely be easy to fix. This is now
>> trac #3954:
>>
>> http://trac.sagemath.org/sage_trac/ticket/3954
>>
>> >
>>
>
> >
>
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sage-support
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
