[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