Skip to content

R on the Zaurus

3 messages · Simon Pickering, root, Peter Dalgaard

Original
Simon Pickering
# 
Hello All,

I have a working port of R on my SL5500. I've not tested the X windowing
support yet, but was more concerned about the accuracy of the fp emulation.

The following is the result of the test which Stuart Leask recommended I
should try:

Mandrake 8.2
[1] TRUE
[1] NA
[1] NA

Zaurus OZ3
[1] TRUE
[1] 1
[1] 8.29488e-311

Presumably this is the wrong answer. The question is whether it's the fault
of the Zaurus' fp emulation, or some sort of incompatibility with the way R
is written. Does anyone know for certain which it might be?

If it is a bug in the Zaurus' fp implementation then I don't see any real
troubles getting it fixed (I'm sure people will be keen to get this right).

I notice that there are two types of NaNs in the ieee 754 standard, QNaN
(Quiet NaN) and SNaN (Signalling NaN). Does 8.29488e-311 look familiar (I
didn't think so)?

Regards,


Simon

--------------------------------------------
Simon Pickering MEng
Dept. of Mechanical Engineering
University of Bath
Bath, BA2 7AY, UK

Tel: +44 (0)1225 383314
Fax: +44 (0)1225 386928
--------------------------------------------


-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-help-request at stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
root
# 
(Actually, I believe this little test was suggested by Peter Dalgaard... I
sent Simon the 'correct results' to compare with the Zaurus output...

Stuart Leask)
emulation.
fault
R
right).
-.-.-
http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._.
_._

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-help-request at stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
Peter Dalgaard
# 
"Stuart Leask" <stuart.leask at nottingham.ac.uk> writes:
The basic issue lies in these routines from the start of arithmetic.c:


static double R_ValueOfNA(void)
{
    ieee_double x;
    x.word[hw] = 0x7ff00000;
    x.word[lw] = 1954;
    return x.value;
}

int R_IsNA(double x)
{
    if (isnan(x)) {
        ieee_double y;
        y.value = x;
        return (y.word[lw] == 1954);
    }
    return 0;
}

(Notice that the system isnan() function/macro is used in the second routine)

I believe that the IEEE standard prescribes that *anything* with 0x7ff
in the exponent field of a floating point number is a NaN, and that
arithmetic on a NaN gives a NaN result. R's NA value is merely a
special NaN with the 1954 code in the low word. 

Now, it is certainly possible to get the byte-order wrong for a given
architecture, but then our NA wouldn't be a NaN, and the is.na(NA)
test should fail, but it doesn't. So it seems that NA really is a NaN
value on the Zaurus, but arithmetic on it gives a non-NA result, which
sort of indicates that the Z. is not treating all NaN's equally,
possibly only applying IEEE rules to NaN's that are like the ones
generated invalid calculations. It might be instructive to see what
the bit pattern of 0./0. is on this machine.