From jmc@research.bell-labs.com  Mon Aug 27 15:31:25 2001
From: jmc@research.bell-labs.com (John Chambers)
Date: Mon, 27 Aug 2001 10:31:25 -0400
Subject: [Rd] Wierd problem comparing numeric values and list using ==
 (PR#1076)
References: <200108271245.OAA16874@pubhealth.ku.dk> <x27kvpwrqi.fsf@blueberry.kubism.ku.dk>
Message-ID: <3B8A59BD.BE5F7188@research.bell-labs.com>

Peter Dalgaard BSA wrote:
 ....
> > As of 1.4, we will have the `identical' function, which is the right way
> > to do such comparisons in any case.
> >
> > So I'd vote for making a use of the comparison operators an error unless
> > the type is correct (or there is a method defined).  There is even code
> > in relop.c (commented out) that looks like the right test.  Any
> > objections?
> 
> Not really, except that I get the usual nagging suspicion that someone
> (who?) meant something by doing it this way...
> 
> The current logic seems to be that if either side of the == is a
> vector of atomic type, try to coerce the list on the other side to a
> similar object and then test. However this has a clear bug in that the
> coercion is to double even when the atomic vector is integer. If there
> are lists on both sides, a pointer comparison is done:
> 
> > x<-2
> > list(x)==list(x)
> [1] FALSE
> > list(.Alias(x))==list(.Alias(x))
> [1] TRUE
> 
> The latter seems highly dubious to me. I'd rather have a recursive
> pairwise application of "==" there. However, none of this is what
> identical does, is it?

identical essentially applies itself recursively until it encounters an
non-recursive element (in which case it does element-wise comparisons or
something specific to the special type, such as a symbol).  

My take is that the "==" operator is for generating data structures that
look like the arguments but with TRUE, FALSE, or NA in the appropriate
elements. Notice, e.g., that identical(1,NA) is FALSE while 1==NA is NA.

It's possible one would like to do == recursively to all the elements of
two lists, suggesting an lapply of the "==" function.  (R doesn't yet
have a recursive apply to do this at all levels of recursion.)

But in most examples I've seen, users really wanted a single TRUE/FALSE
result, in which case they should _not_ be using the "==" operator.

John

-- 
John M. Chambers                  jmc@bell-labs.com
Bell Labs, Lucent Technologies    office: (908)582-2681
700 Mountain Avenue, Room 2C-282  fax:    (908)582-3340
Murray Hill, NJ  07974            web: http://www.cs.bell-labs.com/~jmc
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._


[Rd] Wierd problem comparing numeric values and list using == (PR#1076)
John Chambers