[R] R on the Zaurus

[Peter Dalgaard BSA]

"Stuart Leask" <stuart.leask at nottingham.ac.uk> writes:

> (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)
> 
> > 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
> > > x<-NA
> > > is.na(x)
> > [1] TRUE
> > > x+1
> > [1] NA
> > > 2*x
> > [1] NA
> >
> > Zaurus OZ3
> > > x<-NA
> > > is.na(x)
> > [1] TRUE
> > > x+1
> > [1] 1
> > > 2*x
> > [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)?

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.

-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk)             FAX: (+45) 35327907
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._