> From: Thomas Lumley [mailto:[EMAIL PROTECTED]
>
> 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
Thanks 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}}
______________________________________________
[EMAIL PROTECTED] 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
