Re: Class groups

[Gerhard Niklasch <nikl@mathematik.tu-muenchen.de>]

In response to
> Message-Id: <9806191249.AA00260@rhrz.uni-bonn.de>
> From: Michael Stoll <Michael_Stoll@math.uni-bonn.de>
> Date: 	Fri, 19 Jun 1998 14:49:12 +0200
> 
> Gerhard Niklasch <nikl@mathematik.tu-muenchen.de> writes
> 
> GN> Anybody know which version of the PARI kernel would be included in that
> GN> version of MAGMA?
> The number field algorithms of Magma are based on KANT, not on PARI.

Thanks to John Cannon for clearing this up in an earlier email;
I guess I had been reading your (Michael's) first posting too fast
and believed I saw some PARI function names appearing in what I took
to be MAGMA diagnostic output.  Sorry for any confusion I may have
caused.

[...]
> In what way could the result be wrong? Or does `not guaranteed' mean that
> there might be no result at all?

E.g. if we don't search sufficiently far  (where `sufficiently' depends
on whether one believes in GRH or not ;^),  we might have found generators
only for a proper subgroup of the class group, so  (assuming we caught
all relations)  our computed h will be a proper divisor of the true
value, and we might also have found only a proper subgroup of the group
of units, and thus the computed regulator R will be an integral multiple
of the true value.  (If we might have missed relations, it'll be even
worse!)  Things may conspire to give the correct product hR, and thus
fail to indicate that anything might be wrong.

If some veteran user of one of the systems under discussion has seen
and archived  (or could reproduce)  an example where this actually
happens, perhaps with contrived parameters, I think it would be valuable
if they could post it say here on pari-dev or on pari-users to spread
the knowledge, and to warn later generations not to trust their machines
too blindly.

As far as I could tell  (without correlating the franglais messages to
the code issuing them)  from what gp was doing with x^4+5*239*x^2+5*239^2
at default parameter settings, the problem there was that it kept missing
a relation, and thus the computed class group was always a double cover
of the true one, and hR was twice as large as it should have been.  So
it noticed that something was wrong, and kept increasing the size of the
factor base.  (I may be wrong -- corrections welcome.)

[...]
> My machine has a Pentium 200 S CPU, in case you want to compare timings
> (timings vary, however, because of some probabilistic parts of the
> algorithms, I guess).

This is easily taken care of by initializing the random seed explicitly
(setrand() in gp) before embarking on the computation.

Thanks for the update, Gerhard