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]
`