Gerhard Niklasch on Tue, 28 Nov 2000 10:57:35 +0100 (MET)


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

Re: Pari 2.1.0 failed two bench tests on my new computer.


In response to:
> Message-Id: <200011280534.eAS5YCf06411@dt0610naf.san.rr.com>
> From: David Cantor <dgc@ccrwest.org>
> To: pari-dev@list.cr.yp.to
> Date: Mon, 27 Nov 2000 21:34:12 -0800

> [...] the bench test found some differences.
> There were the two elliptic curve
> dif tests.  Some of the deifferences were just round-off in the last
> decimal place, but others appear to be more significant.
> 
> I compiled using the included configuration file without changes.

Using which compiler, gcc?  which version?  What commandline
options were chosen?

(You can retrieve them from the dft.config.in file in the
O*-* directory underneath the base directory.)

Notes:
(1) The code exercised for the .sta and .dyn tests is the same.

(2) All the other differences are ultimately caused by the one-bit
round-off difference between 1.999...999 and 2.000...000 in the
result of polroot(), applied to the cubic on the righthand side
of the elliptic curve defining equation.

(All the computations after this point are done with PARI reals,
and are 100% reproducible.)

(3) This discrepancy in polroot() is caused by one or two computations
using the processor's floating-point unit  (and this is where the
compiler commandline options come in -- usually one can choose between
an IEEE-conforming mode, and a faster, devil-may-care mode where the
compiler optimizes away floating-point divisions in favor of multipli-
cations by the inverse, which may occasionally change the least sig-
nificant bit of the result).  As long as all machine FPU computations
are compiled for strict IEEE conformance, polroot() will come up with
2.000...000, exactly, for this cubic.

(4) Karim and I had just been through this with the Sun cc 5.1,
where -- compared to 5.0 -- the default of this particular setting,
in the presence of -fast on the commandline, had changed from "don't
care about floating-point underflow but care about divisions" to
"devil may care", with the exact same bench .dif's as you have been
seeing.

(If anybody besides me wants to compile PARI/gp on sparc with
Sun cc 5.1 or 5.2, use -fast -fsimple=1 to avoid this.)

Hope this helps,
Gerhard