Re: Backwards-incompatible change to idealappr()

[Bill Allombert <Bill.Allombert@math.u-bordeaux.fr>]

On Wed, Oct 26, 2016 at 12:29:30PM +0200, Karim Belabas wrote:
> * 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 have sent a patch to the Alnuth maintainers to remove the
compatibility code.

Cheers,
Bill.