Re: Preparing bugfix release 2.1.5

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

On Thu, 12 Dec 2002, Bill Allombert wrote:
> As some of you may have gathered form the CVS, I am preparing behind the scene
> a 2.1.5 bug fix release, so if you are aware of bugs in 2.1.4 that are not
> yet fixed in the CVS, please report them to me.
>
> I try to fix 2.2.4 F32:
>  32- polredabs fails to reduce
>    x^8-2*x^7-34*x^6+78*x^5+265*x^4-628*x^3-389*x^2+1237*x-449
>    [typo in chk_gen_init: skipfirst not initialized properly]
>
> I have some questions:
> 1) I do not thing the bracketed comment is accurate. I think the skipfirst
> problem was fixed a long time ago in 2.2.3 F28 and 2.1.4 F7.

It is correct, though not highly accurate. It is a "skipfirst" problem,
caused by a typo [ picking the first element of compositum(,) instead of the
last ], so that the skipfirst parameter was initialized with too large a
value.

[ skipfirst := the 'skipfirst' basis elements of the order generate a strict
subfield of the splitting field of the polynomial ]

> 2) The patch responsible of the fix is as follow:
>
> --- src/basemath/base1.c	2002/07/15 13:29:58	1.99
> +++ src/basemath/base1.c	2002/08/03 15:37:29	1.100
> @@ -1771,7 +1771,8 @@
>      if (prev && degpol(prev) < N && !gegal(prev,P))
>      {
>        if (degpol(prev) * degpol(P) > 64) continue; /* too expensive */
> -      P = (GEN)compositum(prev,P)[1];
> +      P = compositum(prev,P);
> +      P = (GEN)P[lg(P)-1];
>        if (degpol(P) == N) continue;
>        if (DEBUGLEVEL>2 && degpol(P) != degpol(prev))
>          fprintferr("chk_gen_init: subfield %Z\n",P);
>
> This assume the output of polcompositum is sorted by degree.

Indeed.

> Is it true for 2.1.4 ?

Yes. [ sort_factor() called at the end of compositum()->factor()->factpol() ]

> Here the current list of bugs in 2.2 that may need to be investigated in 2.1

(18:40) vintsy-karim% diff -ru pari pari.stable | wc
 142277  642902 4589839

Given the differences between the two branches, I would stick to absolute
minimal changes until we merge them, which should be done ASAP. The source
code is more or less stable now, but we have ideas/material for further
massive changes. So I guess we should freeze it now and postpone:

* Ilya's sizeof(long) and t_EXT patches
* your description system + gmp kernel patches
* install() support on MacOS X  [ too bad, it nearly works now... ]

so that we can add and debug them at the _beginning_ of the next development
cycle ?

I can prepare a final 2.2.5 snapshot for later this evening [ had been
meaning to do it anyway, only need to tune t_REAL Karatsuba multiplication,
and include Ilya's final readline patches ].

Assuming all is well, we can freeze to 2.2.6-beta just before Christmas
holidays, say.

Opinions ?

    Karim.
-- 
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/