Bill Allombert on Fri, 19 Sep 2014 13:00:10 +0200

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

pari-2.7.2(STABLE) released

Dear PARI lovers,

I would like to announce the release of pari-2.7.2 (STABLE). The sources
and a basic Windows binary are available from

This is a BUGFIX release for the stable branch. 
This release addresses all significant problems that could be fixed in a
simple, harmless way. However we strongly encourage you to upgrade since it
fixes a number of cases where PARI was returning an incorrect result. 
In particular this release fixes a rounding issue when multiplying floating
points numbers which can lead to slightly different results from 2.7.1.

  --- For Windows users: ---

An installer package is available at:

  --- For Android users: ---

  An updated PariDroid package will be available soon.


Thanks to all those who reported problems, on the mailing lists or through
our Bug Tracking System. ( See ), or
who tested the preleases.

This release is dedicated to the GCC developers.

Have fun,

  Bill and Karim

P.S: The Changelog:

Done for version 2.7.2 (released 19/09/2014):
[last column crossreferences current development release 2.8.0]

    1- gaffsg(0, t_PADIC): wrong valuation                                [F21]
    2- (t_INTMOD with word-sized modulus)^(huge negative power) [#1584]   [F24]
    3- (gp -p N) or (primelimit=N in gprc_ for N >= 436273290 resulted in an
       incorrect primetable. N.B. Such commands are now useless: needed primes
       are produced dynamically anyway.                                   [F25]
    4- monomial(exact zero, d, v) returned an invalid t_POL / t_RFRAC     [F26]
    5- contfracpnqn(v, n) returned partial quotients p[-1]/q[-1] ...
       p[n-1]/q[n-1], instead of the documented p[0]/q[0] ... p[n]/q[n]   [F27]
    6- factor((3+4*I)/25) -> factor 2+I had 0 exponent [#1586]            [F29]
BA  7- iferr() could crash if some component of the t_ERROR were clones.  [F31]
    8- nffactor() could overflow the stack when default accuracy too low  [F32]
BA  9- obsolete use of E=[a1,a2,a3,a4,a6] in ellmul crashed  [#1589]      [F33]
   10- incorrect rounding in mulrr/divrr for one-word precision reals     [F34]
BA 11- multiif did not handle correctly return() in conditions [#1590]    [F35]
   12- [0..5] -> [0,0,0,0,0] on some architectures                        [F36]
   13- is_gener_Fp could return wrong results                             [F37]
   14- Fq_sqrtn(t_INT,..,&zeta) could return a wrong root of 1            [F38]
   15- bnfinit: SEGV due to precision issues [#1592]                      [F39]
   16- zm_zc_mul only worked for square zm matrices                       [F40]
   17- genus2red(0,27*x^5+97*x^4+118*x^3+60*x^2+13*x+1,3) -> bug [#1596]  [F41]
   18- [gphelp] oo loop when $COLUMNS too small [#1594]                   [F42]
   19- genus2red(x,-x^6-3*x^4-10*x^2-1,3) -> impossible inverse [#1597]   [F43]
   20- factoru(1) returned a t_MAT instead of the expected "matsmall"     [F44]
   21- FpM_charpoly wrong in small characteristic [#1602]                 [F45]
   22- when compatible = 3; series() used a random precision              [F50]
   23- genus2red(0,6*x^6+5*x^4+x^2+1,7) -> impossible inverse [#1597]     [F51]
   24- isprime() could crash on large input [#1604]                       [F52]
   25- genus2red(x^3+1,1) -> type error [#1597]                           [F53]
   26- gphelp did not handle === correctly [#1603]                        [F54]
   27- FpXY_evaly() wrong when evaluating at 0                            [F56]
   28- [mingw] gp could crash at start up [#1607]                         [F57]