From ripley@stats.ox.ac.uk  Mon Aug  5 17:00:34 2002
From: ripley@stats.ox.ac.uk (ripley@stats.ox.ac.uk)
Date: Mon, 5 Aug 2002 17:00:34 +0100 (BST)
Subject: var(1) -> NaN instead of NA ..
In-Reply-To: <15694.40515.428879.709115@gargle.gargle.HOWL>
Message-ID: <Pine.LNX.4.31.0208051651560.27498-100000@gannet.stats>

For numeric vectors, `NA' is more precise than `NaN', although
is.na/is.nan obfuscate this.

On IEC60559 (aka, incorrectly, IEE754) machines here is a large class of
values which are NaN.  A small subclass of these are NA and are printed
specially.

On other systems, there is a single representation for NA and NaN.

So your proposed change will give different results on different
platforms, a really bad idea and I hope enough to scupper it.

In any case, statistically var(1) is a missing value, whatever the
conventional formula gives in IEC60559 arithmetic.

[The original problem is a faulty compiler: see my post to R-devel
yesterday.]

Brian

On Mon, 5 Aug 2002, Martin Maechler wrote:

> This is not really important,
> but since it was brought up on R-help, we might as well
> clean it up now :
>
> >>>>> "MM" == Martin Maechler <maechler@stat.math.ethz.ch> writes:
>
> >>>>> "ChinShCh" == Chin-Shan Chuang <chinshan.chuang@stanfordalumni.org> writes:
>     ChinShCh> ....
>
>     ChinShCh> A related question -- are NAs and NaNs supposed to
>     ChinShCh> be the same in R?  If they are not, wouldn't it be
>     ChinShCh> more appropriate for var(1) to return NaN
>     ChinShCh> and to take out the test "stopifnot( is.na(var(1)),
>     ChinShCh> !is.nan(var(1)) )"?  (Presumably NA is used to
>     ChinShCh> denote a missing value, and var(1) is not
>     ChinShCh> missing.)
>
>     MM> yes, I think you are right
>     MM> (and it would be the same as S-plus 6.0 does
>     MM>  so there, the difference between NaN and NA
>     MM>  is less visible since "NaN" are printed as "NA").
>
> We currently say explicitly (in the help file)
> that  var(), cor() and cov() return NA when there's only one
> observation.
>
> But given the above, I don't see why we should be more exact and
> return "NaN" instead.  This is not back-compatible in the strict
> sense, but   is.na(var(1))  of course will still be true and I
> cannot imagine why the difference between NA and NaN should
> matter some user's code.
> If it did, his/her code would work differently in R and S-plus.
>
> If I don't hear arguments against, I will change these to return
> NaN as suggested and S-plus compatibly.
>
> Martin Maechler <maechler@stat.math.ethz.ch>	http://stat.ethz.ch/~maechler/
> Seminar fuer Statistik, ETH-Zentrum  LEO C16	Leonhardstr. 27
> ETH (Federal Inst. Technology)	8092 Zurich	SWITZERLAND
> phone: x-41-1-632-3408		fax: ...-1228			<><
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
> r-devel 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-devel-request@stat.math.ethz.ch
> _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
>

-- 
Brian D. Ripley,                  ripley@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 272860 (secr)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel 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-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._


var(1) -> NaN instead of NA ..
ripley@stats.ox.ac.uk