[R] precision problems in testing with Intel compilers
Martin Maechler
maechler at stat.math.ethz.ch
Sat Aug 21 00:49:32 CEST 2004
Thank you for the report.
Your points are quite valid (see below).
Note that these precision tests were a bit stringent on purpose
because pchisq() eventually needs some accuracy improvements
which I had been investigating (when I did some minor
improvements).
>>>>> "FrankSa" == Samuelson, Frank* <Samuelson>
>>>>> on Thu, 19 Aug 2004 12:11:00 -0400 writes:
FrankSa> I compiled the 1.9.1 src.rpm with the standard gnu tools and it works.
FrankSa> I tried compiling the 1.9.1 src.rpm with the Intel 8 C and FORTRAN
FrankSa> compilers and it bombs out during the testing phase:
FrankSa> comparing 'd-p-q-r-tests.Rout' to './d-p-q-r-tests.Rout.save' ...267c267
FrankSa> < df = 0.5[1] "Mean relative difference: 5.001647e-10"
FrankSa> ---
>> df = 0.5[1] TRUE
FrankSa> make[3]: *** [d-p-q-r-tests.Rout] Error 1
FrankSa> make[3]: Leaving directory `/usr/src/redhat/BUILD/R-1.9.1/tests'
FrankSa> make[2]: *** [test-Specific] Error 2
FrankSa> make[2]: Leaving directory `/usr/src/redhat/BUILD/R-1.9.1/tests'
FrankSa> make[1]: *** [test-all-basics] Error 1
FrankSa> make[1]: Leaving directory `/usr/src/redhat/BUILD/R-1.9.1/tests'
FrankSa> make: *** [check-all] Error 2
FrankSa> error: Bad exit status from /var/tmp/rpm-tmp.63044 (%build)
FrankSa> looking at the differences between the failed file and the standard, I get:
FrankSa> fws wolf tests] diff d-p-q-r-tests.Rout.save d-p-q-r-tests.Rout.fail
FrankSa> 3c3
FrankSa> < Version 1.9.0 Patched (2004-04-19), ISBN 3-900051-00-3
FrankSa> ---
>> Version 1.9.1 (2004-06-21), ISBN 3-900051-00-3
FrankSa> 281c281
FrankSa> < df = 0.5[1] TRUE
FrankSa> ---
>> df = 0.5[1] "Mean relative difference: 5.001647e-10"
FrankSa> 935c935
FrankSa> < Time elapsed: 7.83 0.04 16.1 0 0
FrankSa> ---
>> Time elapsed: 2.49 0.01 2.55 0 0
FrankSa> Besides being 3 times faster, it's stopping on the following code:
(intel's new C compiler, what hardware?)
FrankSa> for(df in c(0.1, 0.5, 1.5, 4.7, 10, 20,50,100)) {
FrankSa> cat("df =", formatC(df, wid=3))
FrankSa> xx <- c(10^-(5:1), .9, 1.2, df + c(3,7,20,30,35,38))
FrankSa> pp <- pchisq(xx, df=df, ncp = 1) #print(pp)
FrankSa> dtol <- 1e-12 *(if(2 < df && df <= 50) 64 else if(df > 50) 20000 else 500)
FrankSa> print(all.equal(xx, qchisq(pp, df=df, ncp=1), tol = dtol))# TRUE
FrankSa> ##or print(mapply(rErr, xx, qchisq(pp, df=df,ncp=1)), digits = 3)
FrankSa> }
FrankSa> Where dtol used by all.equal is set to be 5e-10,
FrankSa> which the intel compiler misses by 1.6e-13.
FrankSa> This tolerance value seems a bit arbitrary.
indeed. Replacing 500 by 501 above would already let pass your setup
FrankSa> The gcc compiled version's passes the test with a 9.3e-11 error.
FrankSa> I am using the -mp option for the intel compilers, which was recommended
FrankSa> on this mailing list previously and would make sense given the docs:
(still be interested to hear what happens with the test when you
do *not* set "-mp")
FrankSa> Floating Point Optimization Options
FrankSa> -mp Maintain floating-point precision (disables some
FrankSa> optimizations). The -mp option restricts optimiza-
FrankSa> tion to maintain declared precision and to ensure
FrankSa> that floating-point arithmetic conforms more
FrankSa> closely to the ANSI and IEEE standards. For most
FrankSa> programs, specifying this option adversely affects
FrankSa> performance. If you are not sure whether your
FrankSa> application needs this option, try compiling and
FrankSa> running your program both with and without it to
FrankSa> evaluate the effects on both performance and preci-
FrankSa> sion.
FrankSa> Has anyone else encountered this?
More information about the R-help
mailing list