Re: compatibility broken

[Karim Belabas <Karim.Belabas@math.u-bordeaux1.fr>]

* Igor Schein [2007-03-05 22:59]:
> I just wanted to raise a huge (for me) problem in CVS:
> 
> *** rnfkummer: x not coprime to pr in famat_makecoprime:
> 
> A lot of my code written long time ago is broken now, I have to
> rewrite it all.  Before I do that, I wanted to run it by people.  I
> know which bug was being addressed with this change, and I do realize
> that it wasn't supposed to work the way I was using it before anyway

Actually, your code was entirely correct.

In order to fix a BIB (input to ideallog or bnrisprincipal not coprime
to the modulus), I broke a perfectly legitimate use (given non coprime
inputs, make them coprime using "canonical" local uniformizers).


More details:
[ Sorry for the confusing explanation to follow, this is a bit of a hack: ]

Initially, I wrote famat_makecoprime() to handle inputs in factored
form, where it was not assumed that the factors were coprime to the
modulus. But their product was ! (ASSUMPTION)

Then I noticed, that 

1) the routine was in fact called with inputs modified to make them
coprime to a fixed modulus (multiply by a suitable product of local
uniformizers)

2) the effect of the code on the UNMODIFIED inputs was exactly the 
same as on modified inputs, since we multiplied by local uniformizers
whose effects in fact cancelled the modification !

3) So I just dropped the ASSUMPTION, and a perfectly "canonical" output
is obtained from these invalid inputs. On non coprime inputs, the
discrete log of a (canonical, valid) related ideal is computed instead.
This was used extensively in rnfkummer, leading to noticeable performance
improvements, and was broken by the BIB fix [ those ideals are not
coprime to the modulus, let's raise an error ]

Since I do not know how to fix the BIB without a silly performance penalty,
I'm leaving it as is.

> but I was wondering if there're any other considerations out there,
> and if there may be another solution which wouldn't compromise the
> integrity but at the same time would be more backward
> compatibility-friendly.  For the time being I am reverting to the CVS
> version just before the change.

Current CVS no longer raises an error in those cases.

NB: current CVS _is_ broken in another area though, so don't update just
yet [ FpY_FpXY_resultant stopped working, the reason is known and will
be fixed soon ]

Cheers,

    K.B.
--
Karim Belabas                  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]
`