# [R] odd behaviour of identical

Berwin A Turlach berwin at maths.uwa.edu.au
Sun Nov 2 03:52:43 CET 2008

```On Sat, 01 Nov 2008 22:57:38 +0100
Wacek Kusnierczyk <Waclaw.Marcin.Kusnierczyk at idi.ntnu.no> wrote:

> Patrick Burns wrote:
> > Wacek Kusnierczyk wrote:
> >>
> >
> > Nonsense.
>
> not really, i'm afraid.
>
[...]
> to the point:
>
> is.integer(1) # FALSE
> is.integer(1:1) # TRUE
>
> is not particularly appealing as a design, though it can be defended
> along the line that : uses 1 as the increase step, thus if it starts
> at an integer, the vector contains integers (just like it says in
> help(":")).  the problem here is that 1:1 is *obviously* an integer
> vector, while 1 is *obviously* a number vector, but *obviously* not an
> integer vector.  do a poll on how obvious it is to r's users, i'd bet
> you lose.

Probably you are right, but the set of useRs would be the wrong
reference base.  Most useRs are using R for the purpose it was
designed; namely, statistical analyses.  And I cannot remember any
statistical analyses that I ever done where it mattered whether a
number was stored as an integer or not; or whether is.integer()
returned FALSE or TRUE.

I can see a use of is.integer() only when you use R for programming.
Personally, the only use I can see for is.integer() is for checking
that a user has not by accident passed a vector stored in integer mode
to a routine in which I pass this vector down to C or FORTRAN code that
expects double or DOUBLE PRECISION, respectively.  But in such
situation, rather than testing with is.integer(), I typically just use
storage.mode() to ensure the proper storage mode.

In summary, if one uses R as a programming language then, as with
any other programming language, one should become familiar with the
language and its idiosyncrasies; and perhaps also with some features of
binary computing and the constraints imposed by these feature.  In my
experience, every language has idiosyncrasies that one has to get used
to (and which one may or may not consider design flaws).  As the saying
goes, a good handyman does not blame her/his tools.

> >>> On Sun, Oct 26, 2008 at 6:39 PM, Wacek Kusnierczyk
> >>> <Waclaw.Marcin.Kusnierczyk at idi.ntnu.no> wrote:
> >>>
> >>>> given what ?identical says, i find the following odd:

Given that the example section of the help page for identical starts
with:

Examples:

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

I find it odd that you find the following odd.  :)

> >>>> x = 1:10
> >>>> y = 1:10
> >>>>
> >>>> all.equal(x,y)
> >>>> [1] TRUE
> >>>> identical(x,y)
> >>>> [1] TRUE
> >>>>
> >>>> y[11] = 11
> >>>> y = y[1:10]

Vectors can only hold objects of one type; and from the previous
discussion and example you know that 11 has storage mode double.  So
you should not be surprised that all elements of y are promoted to
storage mode double.

And if you think that R's promotion rules are hard to understand; try
to figure out the rules how objects of different types are promoted in
expressions by C; in particular if some objects are unsigned integers.

> >>>> all.equal(x,y)
> >>>> [1] TRUE
> >>>> identical(x,y)
> >>>> [1] FALSE
> >>>>
> >>>> y
> >>>> [1] 1 2 3 4 5 6 7 8 9 10
> >>>> length(y)
> >>>> [1] 10
> >>>>
> >>>>
> >>>> looks like a bug.
> >>>>
> >>>> platform       i686-pc-linux-gnu
> >>>> arch           i686
> >>>> os             linux-gnu
> >>>> system         i686, linux-gnu
> >>>> status
> >>>> major          2
> >>>> minor          7.0
> >>>> year           2008
> >>>> month          04
> >>>> day            22
> >>>> svn rev        45424
> >>>> language       R
> >>>> version.string R version 2.7.0 (2008-04-22)

Cheers,

Berwin