[R] More precision problems in testing with Intel compilers

[Samuelson, Frank*]

I've put up the test problems I had with 'alternate' compilers at
http://www.merrill-samuelson.com/tmp

One is the d-p-q-r test output, and one is the complete print-tests.Rout
file.

I also put up a couple of failures from the reg-tests-1 file.
Even if you don't change anything else, one of these _needs_ changing.
There's a == comparison from the output of 2 different glm calls that
fails because the operands differ by
1/2 unit of machine precision.  (I added some digits to the print 
statements for more info.)  I'd recommend an all.equal() here.

And last, all the < 100*.Machine$double.eps comparisons in nafns.R appear to
fail by a factor of about 2.5.  There are some examples with extra prints.

-Frank


-----Original Message-----
From: Martin Maechler [mailto:maechler at stat.math.ethz.ch] 
Sent: Friday, August 20, 2004 6:39 PM
To: Samuelson, Frank*
Cc: 'r-help at stat.math.ethz.ch '
Subject: RE: [R] More precision problems in testing with Intel compilers


>>>>> "FrankSa" == Samuelson, Frank* <Samuelson>
>>>>>     on Thu, 19 Aug 2004 16:22:11 -0400 writes:

    FrankSa> The Intel compiled version also fails the below test:

here you give the desired output.
What does your 'Intel compiled R' return instead?

    >> ###------------ Very big and very small
    >> umach <- unlist(.Machine)[paste("double.x", c("min","max"), sep='')]
    >> xmin <- umach[1]
    >> xmax <- umach[2]
    >> tx <- unique(outer(-1:1,c(.1,1e-3,1e-7)))# 7 values  (out of 9)
    >> tx <- unique(sort(c(outer(umach,1+tx))))# 11 values  (out of 14)
    >> tx <- tx[is.finite(tx)] #-- all kept
    >> (txp <- tx[tx >= 1])#-- Positive exponent -- 4 values
     [1] 1.617924e+308 1.795895e+308 1.797693e+308 1.797693e+308
    >> (txn <- tx[tx <        1])#-- Negative exponent -- 7 values
    [1] 2.002566e-308 2.222849e-308 2.225074e-308 2.225074e-308
2.225074e-308 2.227299e-308 2.447581e-308

    FrankSa> Does anyone really care about being correct to 1
    FrankSa> unit of machine precision?  If you do, you have a
    FrankSa> bad algorithm.  ??

We have had these tests there for a long time now and haven't
heard of failures before..  so this is interesting.
DIG(7) makes us only look at 7 digits which is less than half machine
precision, but then there's cancellation of another 7 digits in
some of those above which gets in the region of machine precision,
(but still leaves a factor of ~= 45).

Can you upload the full print-test.Rout file somewhere?

Regards,
Martin


    FrankSa> -----Original Message-----
    FrankSa> From: Samuelson, Frank* [mailto:FWS4 at cdrh.fda.gov] 
    FrankSa> Sent: Thursday, August 19, 2004 12:11 PM
    FrankSa> To: 'r-help at stat.math.ethz.ch '
    FrankSa> Subject: [R] precision problems in testing with Intel compilers


    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> ...