Karim Belabas on Tue, 27 Jul 2010 02:20:01 +0200 |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
Re: precision issue |
* 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] `