|Bill Allombert on Wed, 26 Oct 2016 14:19:05 +0200|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|Re: Backwards-incompatible change to idealappr()|
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.