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/