Re: precision issue

[John Cremona <john.cremona@gmail.com>]

I'm travelling and will not be able to test this soon, but thanks anyway,

John

On 26 July 2010 20:05, Karim Belabas <Karim.Belabas@math.u-bordeaux1.fr> wrote:
> * John Cremona [2010-07-19 15:31]:
>> Thanks, Karim (and also Charles Greathouse who replied off-list for
>> some reason).  OK, so I did not recognise 2^63-1 and read the wrong
>> version of the manual, sorry.
>>
>> On the main point -- it would be very good to have this done well.  I
>> am using it to compute some Hilbert class polynomials (and yes, I know
>> there are many other methods).
>
> I implemented what I think is the right algorithm (express in terms of
> Delta(2x)/Delta(x), use modularity for the two arguments x & 2x independently).
> Does it behave in a better way now ?
>
> Cheers,
>
>  K.B.
>
> P.S: I have modified all related routines (weber(), eta(), quadhilbert())
> in an analogous way.
>
>> On 19 July 2010 14:01, Karim Belabas <Karim.Belabas@math.u-bordeaux1.fr> wrote:
>> > * John Cremona [2010-07-19 14:35]:
>> >> Consider the following (using a recent svn on a 64-bit machine):
>> >>
>> >> ? D = -37*4
>> >> %1 = -148
>> >> ? tau = (2+sqrt(D))/4
>> >> %2 = 1/2 + 3.0413812651491098444998421226010335310*I
>> >> ? ellj(tau)
>> >> %3 = -199147904.00096667436353951991474362130 + 4.733165431326070833 E-30*I
>> >> ? real(ellj(tau))
>> >> %4 = -199147904.00096667436353951991474362130
>> >> ? precision(real(ellj(tau)))
>> >> %5 = 38
>> >> ? precision(imag(ellj(tau)))
>> >> %6 = 19
>> >> ? real(tau)
>> >> %7 = 1/2
>> >> ? precision(real(tau))
>> >> %8 = 9223372036854775807
>> >> ? precision(imag(tau))
>> >> %9 = 38
>> >>
>> >> I don't like the way that j(tau)'s imaginary part only has half the
>> >> precision of the real part.  Since tau is known to have real part
>> >> *exactly* 1/2 we know that j(tau) is real, so could we not set the
>> >> imaginary par of the returned value to exact 0?  (similarly when
>> >> Re(tau)=0).  This must be quite a common special case.
>> >
>> > 1) Trying to answer your question, I just had a look at the code, and it
>> > must be rewritten anyway. (Correct algorithm in terms of \eta(tau),
>> > implemented in a highly inefficient way.)
>> >
>> > 2) This is analogous to
>> >
>> >  (14:44) precision((1.+1e-30) - 1.)
>> >  %2 = 19
>> >
>> >
>> > I'll see what I can do.
>> >
>> > Cheers,
>> >
>> >    K.B.
>> >
>> > P.S:
>> >> And secondly, why that bizarre value for precision(real(tau))?  I even get
>> >>
>> >> ? precision(0)
>> >> %12 = 9223372036854775807
>> >>
>> >> while looks like a bug since I thought that exact objects had precision 0.
>> >
>> > The documented behaviour is :
>> >
>> > (14:38) gp > ??precision
>> > precision(x,{n}):
>> >
>> >   gives the precision in decimal digits of the PARI object x. If x is an exact
>> > object, the largest single precision integer is returned.
> --
> Karim Belabas, IMB (UMR 5251)  Tel: (+33) (0)5 40 00 26 17
> Universite Bordeaux 1          Fax: (+33) (0)5 40 00 69 50
> 351, cours de la Liberation    http://www.math.u-bordeaux.fr/~belabas/
> F-33405 Talence (France)       http://pari.math.u-bordeaux.fr/  [PARI/GP]
> `
>