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