identical {base} | R Documentation |
The safe and reliable way to test two objects for being
exactly equal. It returns TRUE
in this case,
FALSE
in every other case.
identical(x, y, num.eq = TRUE, single.NA = TRUE, attrib.as.set = TRUE, ignore.bytecode = TRUE, ignore.environment = FALSE, ignore.srcref = TRUE)
x, y |
any R objects. |
num.eq |
logical indicating if ( |
single.NA |
logical indicating if there is conceptually just one numeric
|
attrib.as.set |
logical indicating if |
ignore.bytecode |
logical indicating if byte code should be ignored when comparing closures. |
ignore.environment |
logical indicating if their environments should be ignored when comparing closures. |
ignore.srcref |
logical indicating if their |
A call to identical
is the way to test exact equality in
if
and while
statements, as well as in logical
expressions that use &&
or ||
. In all these
applications you need to be assured of getting a single logical
value.
Users often use the comparison operators, such as ==
or
!=
, in these situations. It looks natural, but it is not what
these operators are designed to do in R. They return an object like
the arguments. If you expected x
and y
to be of length
1, but it happened that one of them was not, you will not get a
single FALSE
. Similarly, if one of the arguments is NA
,
the result is also NA
. In either case, the expression
if(x == y)....
won't work as expected.
The function all.equal
is also sometimes used to test equality
this way, but was intended for something different: it allows for
small differences in numeric results.
The computations in identical
are also reliable and usually
fast. There should never be an error. The only known way to kill
identical
is by having an invalid pointer at the C level,
generating a memory fault. It will usually find inequality quickly.
Checking equality for two large, complicated objects can take longer
if the objects are identical or nearly so, but represent completely
independent copies. For most applications, however, the computational cost
should be negligible.
If single.NA
is true, as by default, identical
sees
NaN
as different from NA_real_
, but all
NaN
s are equal (and all NA
of the same type are equal).
Character strings are regarded as identical if they are in different marked encodings but would agree when translated to UTF-8.
If attrib.as.set
is true, as by default, comparison of
attributes view them as a set (and not a vector, so order is not
tested).
If ignore.bytecode
is true (the default), the compiled
bytecode of a function (see cmpfun
) will be ignored in
the comparison. If it is false, functions will compare equal only if
they are copies of the same compiled object (or both are
uncompiled). To check whether two different compiles are equal, you
should compare the results of disassemble()
.
You almost never want to use identical
on datetimes of class
"POSIXlt"
: not only can different times in the different
time zones represent the same time and time zones have multiple names,
but several of the components are optional.
Note that identical(x, y, FALSE, FALSE, FALSE, FALSE)
pickily
tests for exact equality.
A single logical value, TRUE
or FALSE
, never NA
and never anything other than a single value.
John Chambers and R Core
Chambers, J. M. (1998) Programming with Data. A Guide to the S Language. Springer.
all.equal
for descriptions of how two objects differ;
Comparison for operators that generate elementwise comparisons.
isTRUE
is a simple wrapper based on identical
.
identical(1, NULL) ## FALSE -- don't try this with == identical(1, 1.) ## TRUE in R (both are stored as doubles) identical(1, as.integer(1)) ## FALSE, stored as different types x <- 1.0; y <- 0.99999999999 ## how to test for object equality allowing for numeric fuzz : (E <- all.equal(x, y)) isTRUE(E) # which is simply defined to just use identical(TRUE, E) ## If all.equal thinks the objects are different, it returns a ## character string, and the above expression evaluates to FALSE ## even for unusual R objects : identical(.GlobalEnv, environment()) ### ------- Pickyness Flags : ----------------------------- ## the infamous example: identical(0., -0.) # TRUE, i.e. not differentiated identical(0., -0., num.eq = FALSE) ## similar: identical(NaN, -NaN) # TRUE identical(NaN, -NaN, single.NA = FALSE) # differ on bit-level ### For functions ("closure"s): ---------------------------------------------- ### ~~~~~~~~~ f <- function(x) x f g <- compiler::cmpfun(f) g identical(f, g) # TRUE, as bytecode is ignored by default identical(f, g, ignore.bytecode=FALSE) # FALSE: bytecode differs ## GLM families contain several functions, some of which share an environment: p1 <- poisson() ; p2 <- poisson() identical(p1, p2) # FALSE identical(p1, p2, ignore.environment=TRUE) # TRUE ## in interactive use, the 'keep.source' option is typically true: op <- options(keep.source = TRUE) # and so, these have differing "srcref" : f1 <- function() {} f2 <- function() {} identical(f1,f2)# ignore.srcref= TRUE : TRUE identical(f1,f2, ignore.srcref=FALSE)# FALSE options(op) # revert to previous state