var(1) -> NaN instead of NA ..
ripley@stats.ox.ac.uk
ripley@stats.ox.ac.uk
Mon, 5 Aug 2002 17:00:34 +0100 (BST)
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._