Karim BELABAS on Sat, 16 Nov 2002 13:49:41 +0100 (MET) |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
Re: Bug rnfconductor |
On Fri, 15 Nov 2002, Igor Schein wrote: > On Fri, Nov 15, 2002 at 10:07:45AM -0500, Igor Schein wrote: >> On Fri, Nov 15, 2002 at 02:31:13PM +0100, Karim BELABAS wrote: >>> On 1 Oct 2002, I wrote: >> [snip] >>> I've implemented these changes in both conductor() and discrayrelall(). This >> [snip] >>> Anything broken so far ? Igor ? >> >> Yes. >> >> ? quadhilbert(3173); >> *** bug in GP (Segmentation Fault), please report > And more: > > ? quadhilbert(689); > *** bug in ComputeArtinNumber, please report > ? quadhilbert(6508); > \\ Infinite loop These are all fixed now. Same cause: wrong result in conductor(), due to my misunderstanding the horrible format of idealstar() [ = (O_K/f)^* ]. More precisely the last 3 components of idealstar(,,1 or 2). I have a backward compatibility problem here: the format is * undocumented (it is documented in the source code) * needed for a single routine: ideallog * painful to use as it stands: lists of lists of lists of ..., where you access different layers at the same time depending on the information you need. * lacking needed data [nfmodprinit, exponent of (O_K/P^e)^* for each P | f ] that I have to recompute each time I use it. When the modulus has no huge prime divisors, this recomputation dominates computation time in ideallog :-(. Currently, I basically translate it on the fly to something usable, recomputing missing data, _each time_ I use it (i.e each time an ideallog() is computed). So I would like to change it to something more palatable, and clean up the current mess (in particular remove hardwired code and define a clean interface). Unfortunately, this would prevent reading in old bnr / idealstar data. I do not want to maintain two different (large) sets of subroutines. This is probably not a big problem, since the only data (from the number fields module) worth storing is base field data, in my opinion. Not data related to (abelian) extensions thereof (cheap to compute, infinitely many extensions to handle...) Opinions ? Karim. P.S: All clear now, Igor ? -- Karim Belabas Tel: (+33) (0)1 69 15 57 48 Dép. de Mathématiques, Bât. 425 Fax: (+33) (0)1 69 15 60 19 Université Paris-Sud Email: Karim.Belabas@math.u-psud.fr F-91405 Orsay (France) http://www.math.u-psud.fr/~belabas/ -- PARI/GP Home Page: http://www.parigp-home.de/