Dear R-devel,
Has anyone seen this problem? We tried building R-1.8.1 (and R-1.9.0 alpha
2004-03-17) on an Irix 6.5 box using
./configure CC="cc -64" F77="f77 -64" --with-tcltk=no
--enable-R-shlib
make check failed because NA + 0 gave NaN instead of NA. I've tried both
32- and 64-bit build, with and without --enable-R-shlib. The same symptom
occur in all cases.
Any pointer much appreciated.
Best,
Andy
Andy Liaw, PhD
Biometrics Research PO Box 2000, RY33-300
Merck Research Labs Rahway, NJ 07065
mailto:andy_liaw at merck.com <mailto:andy_liaw at merck.com>
732-594-0820
------------------------------------------------------------------------------
Notice: This e-mail message, together with any attachments,...{{dropped}}
On Wed, 17 Mar 2004, Liaw, Andy wrote:> Dear R-devel, > > Has anyone seen this problem? We tried building R-1.8.1 (and R-1.9.0 alpha > 2004-03-17) on an Irix 6.5 box using > > ./configure CC="cc -64" F77="f77 -64" --with-tcltk=no --enable-R-shlib > > make check failed because NA + 0 gave NaN instead of NA. I've tried both > 32- and 64-bit build, with and without --enable-R-shlib. The same symptom > occur in all cases. >I haven't seen it before, but it looks to me as though arithmetic.c assumes that adding a number to a NaN gives the same NaN back, (NA is the NaN with lower word 1954). That is, we just do #ifdef IEEE_754 REAL(ans)[i] = REAL(s1)[i1] + REAL(s2)[i2]; #else This doesn't look as thought it is guaranteed to work, though it does on most machines. It clearly can't work where both operands are NaN, so under OS X I get> NA+NaN[1] NA> NaN+NA[1] NaN -thomas
> From: Thomas Lumley [mailto:tlumley at u.washington.edu] > > On Wed, 17 Mar 2004, Liaw, Andy wrote: > > > Dear R-devel, > > > > Has anyone seen this problem? We tried building R-1.8.1 > (and R-1.9.0 alpha > > 2004-03-17) on an Irix 6.5 box using > > > > ./configure CC="cc -64" F77="f77 -64" --with-tcltk=no > --enable-R-shlib > > > > make check failed because NA + 0 gave NaN instead of NA. > I've tried both > > 32- and 64-bit build, with and without --enable-R-shlib. > The same symptom > > occur in all cases. > > > > I haven't seen it before, but it looks to me as though arithmetic.c > assumes that adding a number to a NaN gives the same NaN > back, (NA is the > NaN with lower word 1954). That is, we just do > #ifdef IEEE_754 > REAL(ans)[i] = REAL(s1)[i1] + REAL(s2)[i2]; > #else > > This doesn't look as thought it is guaranteed to work, though > it does on > most machines. It clearly can't work where both operands are NaN, so > under OS X I get > > NA+NaN > [1] NA > > NaN+NA > [1] NaN > > > -thomas >On our Opteron I get:> NA+NaN[1] NaN> NaN+NA[1] NA OK, now I'm really confused... Andy ------------------------------------------------------------------------------ Notice: This e-mail message, together with any attachments,...{{dropped}}
Sorry for being dense: So What is the likely source of the problem, then? Is it the compiler, the OS, R itself, or some combination of these? Any suggestion on how to resolve this? Best, Andy> From: Prof Brian Ripley [mailto:ripley at stats.ox.ac.uk] > > I think NA+0 should be special, though. All of mine give > > > NA+NaN > [1] NA > > NaN+NA > [1] NA > > That's with four separate compilers on Sparc-Solaris as well > as Windows > and Linux i686. > > I have long wondered why it works .... > > > On Wed, 17 Mar 2004, Liaw, Andy wrote: > > > > From: Thomas Lumley [mailto:tlumley at u.washington.edu] > > > > > > On Wed, 17 Mar 2004, Liaw, Andy wrote: > > > > > > > Dear R-devel, > > > > > > > > Has anyone seen this problem? We tried building R-1.8.1 > > > (and R-1.9.0 alpha > > > > 2004-03-17) on an Irix 6.5 box using > > > > > > > > ./configure CC="cc -64" F77="f77 -64" --with-tcltk=no > > > --enable-R-shlib > > > > > > > > make check failed because NA + 0 gave NaN instead of NA. > > > I've tried both > > > > 32- and 64-bit build, with and without --enable-R-shlib. > > > The same symptom > > > > occur in all cases. > > > > > > > > > > I haven't seen it before, but it looks to me as though > arithmetic.c > > > assumes that adding a number to a NaN gives the same NaN > > > back, (NA is the > > > NaN with lower word 1954). That is, we just do > > > #ifdef IEEE_754 > > > REAL(ans)[i] = REAL(s1)[i1] + REAL(s2)[i2]; > > > #else > > > > > > This doesn't look as thought it is guaranteed to work, though > > > it does on > > > most machines. It clearly can't work where both operands > are NaN, so > > > under OS X I get > > > > NA+NaN > > > [1] NA > > > > NaN+NA > > > [1] NaN > > > > > > > > > -thomas > > > > > > > On our Opteron I get: > > > > > NA+NaN > > [1] NaN > > > NaN+NA > > [1] NA > > > > OK, now I'm really confused... > > > > Andy > > > > > > > > > -------------------------------------------------------------- > ---------------- > > Notice: This e-mail message, together with any > attachments,...{{dropped}} > > > > ______________________________________________ > > R-help at stat.math.ethz.ch mailing list > > https://www.stat.math.ethz.ch/mailman/listinfo/r-help > > PLEASE do read the posting guide! > http://www.R-project.org/posting-guide.html > > > > > > -- > Brian > D. Ripley, ripley at stats.ox.ac.uk > Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ > University of Oxford, Tel: +44 1865 272861 (self) > 1 South Parks Road, +44 1865 272866 (PA) > Oxford OX1 3TG, UK Fax: +44 1865 272595 > > >------------------------------------------------------------------------------ Notice: This e-mail message, together with any attachments,...{{dropped}}
On Wed, 17 Mar 2004, Liaw, Andy wrote:> Sorry for being dense: So What is the likely source of the problem, then? > Is it the compiler, the OS, R itself, or some combination of these? Any > suggestion on how to resolve this?In a sense it is R itself, making assumptions that hold on many, but not all systems. There are many different NaN values, all of which are guaranteed to give NaN results in arithmetic observations. On many systems, if one operand is NaN and the other is a valid number the result is not only NaN, but *the same NaN* as the operand. In R we call one particular one of these NaN values "NA". The standards guarantee that any operation on NA gives some NaN, but we have assumed it gives the right NaN, the NA one. On Irix this seems not to be the case. The solution is to change arithmetic.c not to make this assumption, which will be slower. It would be nice to detect at build time whether the assumption holds, so as to keep the current behaviour on other systems. It should be rare for the error to make any difference, since is.na() is still true for NaN. AFAICT the only problem would be that is.nan(0+NA) can be TRUE when it should be FALSE. -thomas
> From: Thomas Lumley [mailto:tlumley at u.washington.edu] > > On Wed, 17 Mar 2004, Liaw, Andy wrote: > > > Sorry for being dense: So What is the likely source of the > problem, then? > > Is it the compiler, the OS, R itself, or some combination > of these? Any > > suggestion on how to resolve this? > > In a sense it is R itself, making assumptions that hold on > many, but not > all systems. There are many different NaN values, all of which are > guaranteed to give NaN results in arithmetic observations. On many > systems, if one operand is NaN and the other is a valid > number the result > is not only NaN, but *the same NaN* as the operand. > > In R we call one particular one of these NaN values "NA". > The standards > guarantee that any operation on NA gives some NaN, but we > have assumed it > gives the right NaN, the NA one. On Irix this seems not to > be the case. > > The solution is to change arithmetic.c not to make this > assumption, which > will be slower. It would be nice to detect at build time whether the > assumption holds, so as to keep the current behaviour on > other systems. > > It should be rare for the error to make any difference, since > is.na() is > still true for NaN. AFAICT the only problem would be that > is.nan(0+NA) > can be TRUE when it should be FALSE. > > -thomasThanks very much for the clarification, Thomas. So would it be fairly safe for us to edit that part of reg-tests-1.R so it passes this step, so make check can go on from there? Best, Andy ------------------------------------------------------------------------------ Notice: This e-mail message, together with any attachments,...{{dropped}}