Re: Backwards-incompatible change to idealappr()

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

* Bill Allombert [2016-10-26 00:25]:
> On Tue, Oct 25, 2016 at 09:25:09AM +0200, Karim Belabas wrote:
>> * Jeroen Demeyer [2016-10-24 22:06]:
>>> In PARI-2.8.1 which was just released, idealappr() no longer takes a "flag"
>>> argument. I thought that PARI/GP cared a lot about backwards compatibility,
>>> so it is surprising to remove this flag, which was never even deprecated. So
>>> it would be more logical to keep the flag, but deprecate it (like the flag
>>> in matkerint).
>> 
>> Indeed, thanks for catching this one: the library function idealappr0
>> had been kept but I mistakenly changed C-Name from idealappr0 to
>> idealappr (and the attached Prototype) in the description file. Fixed in commit
> 
> A similar issue is with nfbasis(,1) in alnuth:
> 
> The code does 
>   if(type(version)!="t_POL" && lex(version(),[2,4,3])>=0,
>     fac = lift(nffactor(f, pol ))
>   , if(poldegree(pol)*3<n,
>       fac = lift(factornf(pol,f));
>     ,
>       nf = nfinit([f, nfbasis(f,1)]);
>       fac = lift(nffactor(nf, pol ))
>   ));
> 
> so actually nfbasis(f,1) is never executed, unfortunately this leads to a
> compilation error.
> 
>   ***   too many arguments: nfbasis(f,1)

This time it was intentional. The construction

      nffactor(nfinit([f, nfbasis(f,1)]), pol ))

is not only unnecessary since 2.4.3 (5 years ago and two stable releases
behind, deprecated in 2.7 already): it does produce wrong results, which
is silly since we have a perfectly safe (and fast = polynomial-time)
alternative already implemented.

I saw no way of allowing such code to run without ruining its intent
(ignoring the flag means wasting infinite time in factorization).

It's better to fail on this, so that the code can be fixed. In this case,
I would advise to drop support for pari versions < 2.5 in alnuth and simply use

     fac = lift(nffactor(f, pol))

There is no way to quickly factor polynomials over number fields [in a reliable
way] in pari < 2.5.

Cheers,

    K.B.

P.S. One could argue that nfdisc(f,1) could be kept even if nfbasis(f,1)
is dumped. I chose to remove both at the same time: the general [T,listP]
interface must be used instead.

--
Karim Belabas, IMB (UMR 5251)  Tel: (+33) (0)5 40 00 26 17
Universite de Bordeaux         Fax: (+33) (0)5 40 00 21 23
351, cours de la Liberation    http://www.math.u-bordeaux.fr/~kbelabas/
F-33405 Talence (France)       http://pari.math.u-bordeaux.fr/  [PARI/GP]
`