[19089] in s-news-athena
Re: [S] logical and numeric NA's
daemon@ATHENA.MIT.EDU (Babette Brumback)
Wed Sep 1 18:39:38 1999
Date: Wed, 1 Sep 1999 15:37:14 -0700 (PDT)
From: Babette Brumback <brumback@biostat.washington.edu>
To: Prof Brian D Ripley <ripley@stats.ox.ac.uk>
Cc: s-news@wubios.wustl.edu
In-Reply-To: <Pine.GSO.4.05.9909012305210.10703-100000@auk.stats>
Message-Id: <Pine.GSO.4.10.9909011529530.21632-100000@gibson1>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Many thanks for your detailed reply. I used version 4.5 for the PC.
The logical NA was created by b_NA, whereas the
numerical one was copied from a dataframe that had been
imported into version 4.5 from stata.
What alarms me is that somehow I managed to get by unaware since
the beginning of graduate school (1991)
using the unapproved query a=="NA" (which I must have learned
through trial and error rather than from a manual), and I only
noticed the trouble this can cause a few months ago.
Perhaps these days this behaviour is not only well documented, but also
assigned a special warning message and taught in all (most) introductory
Splus courses. If not, probably it should be...
On Wed, 1 Sep 1999, Prof Brian D Ripley wrote:
> On Wed, 1 Sep 1999, Babette Brumback wrote:
>
> > Does anyone out there know the rationale for having two different types
> > of NA, one "logical" and the other "numeric"? In the past I have used
>
> There are complex ones, too. There must be, logical, numeric and complex
> variables have different modes.
>
> Within `numeric', integer, single and double have different NAs. Single and
> double (and also complex) on most platforms also have NaN (not a number,
> for 0./0., Inf - Inf, etc.)
>
> > the expression a=="NA" to screen for missing data, but recently I
>
> That is definitely not approved! It coerces a to character and then does
> the test.
>
> > noticed that the numeric type of NA returns "F". This oddity is
> > clearly illustrated with the following example:
> >
> > > a
> > [1] NA
> > > b
> > [1] NA
> > is.na(a)
> > [1] T
> > > is.na(b)
> > [1] T
> > > a=="NA"
> > [1] F
> > > b=="NA"
> > [1] T
> > > a==NA
> > [1] NA
> > > b==NA
> > [1] NA
> > > mode(a)
> > [1] "numeric"
> > > mode(b)
> > [1] "logical"
>
> Um, what system is this? On 3.4 and on 5.1 I find
> > a <- NA
> > is.na(a)
> [1] T
> > a=="NA"
> [1] T
> I suspect your a is actually NaN.
>
> > Having wasted a few hours getting to the root of the problem, I
>
> (which is? I suspect you have not got down to the root yet.)
>
> > am left wondering why it is necessary to have two types of NA's.
>
> Because different modes have different representations. Why is
> NA != NaN? Because one is by design and one by computational imprecision.
>
> > Also, am I right to presume that replacing expressions of the
> > type
> > a=="NA"
> > with
> > is.na(a)
> > circumvents all related oddities? Or might there linger other
> > as yet unrevealed types of NA?
>
> Well, there is also NaN for numeric data, but fortunately
>
> > a <- 0/0
> > is.na(a)
> [1] T
> > is.nan(a)
> [1] T
> > a == "NA"
> [1] F
> > as.character(a)
> [1] "NaN"
>
> Summary: in all the S-PLUS systems I have seen (but not necessarily other
> implementations of S) a NaN prints as NA, but it coerces to NaN as a
> character and is.na(NaN) is true, but NaN == "NA" is false.
>
> That is not to say that there may not be more going on here ....
>
> --
> 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
>
>
-----------------------------------------------------------------------
This message was distributed by s-news@wubios.wustl.edu. To unsubscribe
send e-mail to s-news-request@wubios.wustl.edu with the BODY of the
message: unsubscribe s-news
