identical                package:base                R Documentation

_T_e_s_t _O_b_j_e_c_t_s _f_o_r _E_x_a_c_t _E_q_u_a_l_i_t_y

_D_e_s_c_r_i_p_t_i_o_n:

     The safe and reliable way to test two objects for being _exactly_
     equal.  It returns 'TRUE' in this case, 'FALSE' in every other
     case.

_U_s_a_g_e:

     identical(x, y)

_A_r_g_u_m_e_n_t_s:

    x, y: any R objects.

_D_e_t_a_i_l_s:

     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 wasn't, 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 it was intended for something different.  First, it
     tries to allow for "reasonable" differences in numeric results.
     Second, it returns a descriptive character vector instead of
     'FALSE' when the objects do not match.  Therefore, it is not the
     right function to use for reliable testing either.  (If you _do_
     want to allow for numeric fuzziness in comparing objects, you can
     combine 'all.equal' and 'identical', as shown in the examples
     below.)

     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.

     As from R 1.6.0, 'identical' sees 'NaN' as different from
     'as.double(NA)', but all 'NaN's are equal (and all 'NA' of the
     same type are equal).

_V_a_l_u_e:

     A single logical value, 'TRUE' or 'FALSE', never 'NA' and never
     anything other than a single value.

_A_u_t_h_o_r(_s):

     John Chambers

_R_e_f_e_r_e_n_c_e_s:

     Chambers, J. M. (1998) _Programming with Data. A Guide to the S
     Language_. Springer.

_S_e_e _A_l_s_o:

     'all.equal' for descriptions of how two objects differ; Comparison
     for operators that generate elementwise comparisons.

_E_x_a_m_p_l_e_s:

     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
     identical(all.equal(x, y), TRUE)
     ## If all.equal thinks the objects are different, it returns a
     ## character string, and this expression evaluates to FALSE

     # even for unusual R objects :
     identical(.GlobalEnv, environment())

