On Mon, Dec 22, 2008 at 3:37 PM, John Cremona <john.crem...@gmail.com> wrote:
>
> 2008/12/22 William Stein <wst...@gmail.com>:
>>
>> On Mon, Dec 22, 2008 at 1:51 PM, M. Yurko <myu...@gmail.com> wrote:
>>>
>>> First, about my issues with PARI's precision. I just tested the
>>> following:
>>> -pari(-10).eint1().n(150)
>>> and got 2492.2289762418777541164160993503173813223839 which is
>>> inaccurate after the 14th decimal place. As Stein said, Its quite
>>> likely that I didn't call PARI correctly, as this is the first time
>>> that I have directly used that interface.
>>
>> Yes, you're using the interface incorrectly.
>>
>> sage: pari.set_real_precision(150)
>> sage: -pari(-10).eint1(precision=150)
>> 2492.228976241877759138440143998524848989647101430942345358
>> sage: timeit('-pari(-10).eint1(precision=150)')
>> 625 loops, best of 3: 41.8 µs per loop
>>
>
> Using the precision= parameter of eint1 works here since -10 has been
> converted to pari format as exact quantity, so its eint can be
> computed to any precision. (Here the precision is measured in bits.)
> It is perhaps safer to give pari a value which is already at the
> desired precision, like this:
>
> sage: pari(RealField(150)(-10)).eint1()
> -2492.22897624188
>
> Now that looks as if it has low precision, but in fact it is only
> printing a feault small number of digits. (William's
> pari.set_real_precision() nly has the effect of changing the number of
> digits output). The other thing about the output of the previous line
> is that its type is still in pari-land:
>
> sage: type(pari(RealField(150)(-10)).eint1())
> <type 'sage.libs.pari.gen.gen'>
> sage: pari(RealField(150)(-10)).eint1().type()
> 't_REAL'
>
> and to do more with it in Sage you should convert back to Sage/python:
>
> sage: pari(RealField(150)(-10)).eint1().python()
> -2492.2289762418777591384401439985248489896471013
>
> where now all the relevant digits are displayed. If you had wanted
> 500 bits, that's just
>
> sage: pari(RealField(500)(-10)).eint1().python()
> -2492.22897624187775913844014399852484898964710143094234538818526713774122742888744417794599665663156560488342454657568480015672868779475213684965774390402
>
> I'm not sure why Sage is not using pari's eint1 by default here.
> pari's function does not handle complex arguments, but seems better
> for real arguments than scipy.
There was a recent trac ticket to change sage to use Pari's eint1 when
it can, since not only does scipy's only do doubles, it is buggy,
changing the branch it uses depending on where you evaluate it. See
http://trac.sagemath.org/sage_trac/ticket/4807
William
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to
sage-support-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sage-support
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
