Re: [R] Odd behaviour of identical()
Thanks. I was not aware of these subtleties of R, but then again I'm no expert. I had to use isTRUE(all.equal(vec,c(0,0))), but it seems to be working now. Thanks again. -- View this message in context: http://r.789695.n4.nabble.com/Odd-behaviour-of-identical-tp4630118p4630170.html Sent from the R help mailing list archive at Nabble.com. __ R-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] Odd behaviour of identical()
I believe it's coming down to the difference between integers and
doubles (the computer data types, not the math-y meaning of those
terms) -- e.g.,
identical( c(0L, 0L), c(0,0) )
Note that sequences made by `:` provide integers when possible: is.integer(1:5)
You may want to use all.equal() instead.
Best,
Michael
On Tue, May 15, 2012 at 11:45 AM, math_daddy wrote:
> Consider the following code:
>
> test <- function(n)
> {
> for(x in 1:n)
> {
> for(y in 1:n)
> {
> for(r in max(x-1,1):min(x+1,n))
> {
> for(s in max(y-1,1):min(y+1,n))
> {
> vec <- c(x-r,y-s)
> print(c("vec = ", vec))
> print(identical(vec,c(0,0)))
> }
> }
> }
> }
> }
>
> If you run test(2) you'll see a printout of the values of the vector vec
> followed by a logical telling you whether vec is identical to c(0,0), which
> it will be for certain iterations of the nested loop. However, the logical
> is always FALSE. If I don't perform the loop but instead assign the values
> directly to vec, this problem does not arise. Can anyone tell me what is
> happening here?
>
> Thank you very much in advance for any help.
>
>
> --
> View this message in context:
> http://r.789695.n4.nabble.com/Odd-behaviour-of-identical-tp4630118.html
> Sent from the R help mailing list archive at Nabble.com.
>
> __
> R-help@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
__
R-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
[R] Odd behaviour of identical()
Consider the following code:
test <- function(n)
{
for(x in 1:n)
{
for(y in 1:n)
{
for(r in max(x-1,1):min(x+1,n))
{
for(s in max(y-1,1):min(y+1,n))
{
vec <- c(x-r,y-s)
print(c("vec = ", vec))
print(identical(vec,c(0,0)))
}
}
}
}
}
If you run test(2) you'll see a printout of the values of the vector vec
followed by a logical telling you whether vec is identical to c(0,0), which
it will be for certain iterations of the nested loop. However, the logical
is always FALSE. If I don't perform the loop but instead assign the values
directly to vec, this problem does not arise. Can anyone tell me what is
happening here?
Thank you very much in advance for any help.
--
View this message in context:
http://r.789695.n4.nabble.com/Odd-behaviour-of-identical-tp4630118.html
Sent from the R help mailing list archive at Nabble.com.
__
R-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Re: [R] odd behaviour of identical
Berwin A Turlach wrote:
> On Sat, 01 Nov 2008 22:57:38 +0100
> Wacek Kusnierczyk <[EMAIL PROTECTED]> wrote:
>
>
>
>> 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.
>
possibly. i haven't had the problem myself, i learned about it here
because a confused user reported it, and it stroke me as irrational.
the case with identical, where, e.g., identical(1:1, { x<-1:1; x[2]<-2;
x[1] }) is FALSE stroke me as even more irrational.
quite possibly statisticians do not care about the internal
representations, but then they should be protected from incidentally
getting confused, complain, and receive a response of the type 'you need
to cast 1 to the integer type to have it an integer'.
but i do know a number of statisticians who gave r a try, and never came
back. i talked to them and know why, and my comments here are related
to those issues. only that i do care discussing them.
> 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.
>
and storage.mode, while exposes the underlying representation, is at
least named so as not to cause confusion. if is.integer(1) == FALSE
were good design (which it is not, i think) then having the function
named 'is.integer' is bad design, precisely because a user (a
statistician), as you say, does not care about integers as
representations, but integers as numbers. again, this problem was
reported by a user who, presumably, uses r for statistics, and not me,
who uses r to find examples of bad design.
> 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.
>
>
sure, but a good handyman uses the best tools affordable. r certainly
gains a lot because it is open source, but this alone does not make it a
good tool.
vQ
__
R-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Re: [R] odd behaviour of identical
On Sat, 01 Nov 2008 22:57:38 +0100
Wacek Kusnierczyk <[EMAIL PROTECTED]> wrote:
> Patrick Burns wrote:
> > Wacek Kusnierczyk wrote:
> >> smells bad design.
> >>
> >
> > 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
> >>> <[EMAIL PROTECTED]> 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
> day22
> svn rev45424
> language R
> version.string R version 2.7.0 (2008-04-22)
Cheers,
Berwin
=== Full address =
Berwin A TurlachTel.: +65 6516 4416 (secr)
Dept of Statistics and Applied Probability+65 6516 6650 (self)
Faculty of Science FAX : +65 6872 3919
National University of Singapore
6 Science Drive 2, Blk S16, Level 7 e-mail: [EMAIL PROTECTED]
Singapore 117546http://www.stat.nus.edu.sg/~statba
__
R-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Re: [R] odd behaviour of identical
Patrick Burns wrote:
> Wacek Kusnierczyk wrote:
>> smells bad design.
>>
>
> Nonsense.
not really, i'm afraid.
> One of the key design features of R is that it
> hides implementation details from users. They
> are free to think about the substantive issues with
> their data rather than worrying about computational
> trivia.
oops. i wish you were right; unfortunately, you seem not to be. this
might have been the idea, and indeed most often one does not need to
think in terms of the underlying representation, but i have just given
examples of how this abstraction barrier is broken, and these are not
the only ones. for the sake of completeness, i'll try to make the point
clear once again below.
on the side, when i once complained here that is.integer(1) evaluates to
FALSE, the (unnecessarily arogant, and not to the point) response was
that one has to understand how computations are actually done in terms
of the underlying representations. irrespectively of whether i do or
not understand that, demanding that a user does is precisely
contradicting the 'key design feature' you mention above.
if you read jim's response below carefully enough, you'll find another
trace of that your 'nonsense' is nonsense.
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.
with an abstraction barrier in place, is.integer should mean 'is the
number an integer?', and not 'is the number stored in an integer type?'
with an abstraction barrier in place, identical(1:2, c(1,2)) would
evaluate to TRUE.
with consistent typing, sqrt(as.integer(2)) would do the job and
sqrt(-2) would do as well (as in, e.g., sage), OR both would result in
an error (as in a language without implicit typecasting, e.g., f#).
etc. etc.
furthermore,
is.integer(1.0:1.0) # TRUE
is.integer(1.0:1.5) # TRUE
is not particularly appealing as a design, and the second form does not
even stand with what help(":") says (please do read it). one of the
responses made here to the complain that is.integer(1) is not TRUE was
that you need to explicitly say you want 1 to be represented as an
integer (note, 'integer' here means the underlying representation, not
what a user assuming an abstraction barrier would normally think
'integer' means). now, 1.0 would be *explicitly* saying 'not integer',
no? then 1.0:1.0 (and 1.0:1.1, etc.) perform an explicit downcast (from
double to int), which is a rather bad idea. and it's not an
implementational detail, it's the design.
>
> There may have been some, but I don't recall a
> time when I've ever needed to know if a vector in R
> was integer or double.
>
well, if it doesn't really matter, make is.integer(1) evaluate to TRUE.
as the previous communication should convince you, there are people that
get confused by the opposite result. they're right, and the response
should not be that they need to learn the implementational details.
i hope the next time you say 'nonsense', you'll first make an effort to
distinguish dreams from reality. it is true that "one of the key design
features of R *should be* that it hides implementation details from
users. they *should be* free to think about the substantive issues with
their data rather than worrying about computational trivia." but
instead there is a mess which forces the users to learn the details to
understand the odd behavoiur of their programs.
vQ
>
> Patrick Burns
> [EMAIL PROTECTED]
> +44 (0)20 8525 0696
> http://www.burns-stat.com
> (home of S Poetry and "A Guide for the Unwilling S User")
>> jim holtman wrote:
>>
>>> If you want them to be identical, then you have to explicitly assign
>>> an integer to the vector so that conversion is not done:
>>>
>>>
x = 1:10
y = 1:10
all.equal(x,y)
>>> [1] TRUE
>>>
identical(x,y)
>>> [1] TRUE
>>>
y[11] = 11L
y = y[1:10]
all.equal(x,y)
>>> [1] TRUE
>>>
identical(x,y)
>>> [1] TRUE
>>>
>>>
>>> On Sun, Oct 26, 2008 at 6:39 PM, Wacek Kusnierczyk
>>> <[EMAIL PROTECTED]> wrote:
>>>
given what ?identical says, i 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]
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
Re: [R] odd behaviour of identical
Wacek Kusnierczyk wrote: smells bad design. Nonsense. One of the key design features of R is that it hides implementation details from users. They are free to think about the substantive issues with their data rather than worrying about computational trivia. There may have been some, but I don't recall a time when I've ever needed to know if a vector in R was integer or double. Patrick Burns [EMAIL PROTECTED] +44 (0)20 8525 0696 http://www.burns-stat.com (home of S Poetry and "A Guide for the Unwilling S User") jim holtman wrote: If you want them to be identical, then you have to explicitly assign an integer to the vector so that conversion is not done: x = 1:10 y = 1:10 all.equal(x,y) [1] TRUE identical(x,y) [1] TRUE y[11] = 11L y = y[1:10] all.equal(x,y) [1] TRUE identical(x,y) [1] TRUE On Sun, Oct 26, 2008 at 6:39 PM, Wacek Kusnierczyk <[EMAIL PROTECTED]> wrote: given what ?identical says, i 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] 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 day22 svn rev45424 language R version.string R version 2.7.0 (2008-04-22) vQ -- --- Wacek Kusnierczyk, MD PhD Email: [EMAIL PROTECTED] Phone: +47 73591875, +47 72574609 Department of Computer and Information Science (IDI) Faculty of Information Technology, Mathematics and Electrical Engineering (IME) Norwegian University of Science and Technology (NTNU) Sem Saelands vei 7, 7491 Trondheim, Norway Room itv303 Bioinformatics & Gene Regulation Group Department of Cancer Research and Molecular Medicine (IKM) Faculty of Medicine (DMF) Norwegian University of Science and Technology (NTNU) Laboratory Center, Erling Skjalgsons gt. 1, 7030 Trondheim, Norway Room 231.05.060 __ R-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code. __ R-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] odd behaviour of identical
smells bad design. jim holtman wrote: > If you want them to be identical, then you have to explicitly assign > an integer to the vector so that conversion is not done: > > >> x = 1:10 >> y = 1:10 >> >> all.equal(x,y) >> > [1] TRUE > >> identical(x,y) >> > [1] TRUE > >> y[11] = 11L >> y = y[1:10] >> >> all.equal(x,y) >> > [1] TRUE > >> identical(x,y) >> > [1] TRUE > > > > On Sun, Oct 26, 2008 at 6:39 PM, Wacek Kusnierczyk > <[EMAIL PROTECTED]> wrote: > >> given what ?identical says, i 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] >> >> 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 >> day22 >> svn rev45424 >> language R >> version.string R version 2.7.0 (2008-04-22) >> >> >> vQ >> >> -- >> --- >> Wacek Kusnierczyk, MD PhD >> >> Email: [EMAIL PROTECTED] >> Phone: +47 73591875, +47 72574609 >> >> Department of Computer and Information Science (IDI) >> Faculty of Information Technology, Mathematics and Electrical Engineering >> (IME) >> Norwegian University of Science and Technology (NTNU) >> Sem Saelands vei 7, 7491 Trondheim, Norway >> Room itv303 >> >> Bioinformatics & Gene Regulation Group >> Department of Cancer Research and Molecular Medicine (IKM) >> Faculty of Medicine (DMF) >> Norwegian University of Science and Technology (NTNU) >> Laboratory Center, Erling Skjalgsons gt. 1, 7030 Trondheim, Norway >> Room 231.05.060 >> >> __ >> R-help@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-help >> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html >> and provide commented, minimal, self-contained, reproducible code. >> >> > > > > -- --- Wacek Kusnierczyk, MD PhD Email: [EMAIL PROTECTED] Phone: +47 73591875, +47 72574609 Department of Computer and Information Science (IDI) Faculty of Information Technology, Mathematics and Electrical Engineering (IME) Norwegian University of Science and Technology (NTNU) Sem Saelands vei 7, 7491 Trondheim, Norway Room itv303 Bioinformatics & Gene Regulation Group Department of Cancer Research and Molecular Medicine (IKM) Faculty of Medicine (DMF) Norwegian University of Science and Technology (NTNU) Laboratory Center, Erling Skjalgsons gt. 1, 7030 Trondheim, Norway Room 231.05.060 __ R-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] odd behaviour of identical
it's the assignment y[11] = 11 that causes y to become num:
y = 1:10
is(y) # integer vector numeric
y[11] = 11
is(y) # numeric vector
y = (1:11)[1:10]
is(y) # integer vector numeric
anyway, i think this should be considered a bug. the conversion is
irrational in this case.
this touches another issue discussed before, that of literals like '1'
not being treated as representing integers:
is(1) # numeric vector
is(1:1) # integer vector numeric
thus 1:10 is a vector of integers, but 11 is not an integer, and y[11] =
11 makes y not an integer vector.
one could actually defend r along these lines, but then there is an
inconsistency here.
help(":") says, among others, about the value of an expression of the
form 'from:to':
For numeric arguments, a numeric vector. This will be of type
'integer' if 'from' and 'to' are both integers and representable
in the integer type, otherwise of type 'numeric'.
well, since is(1) does not report 1 to be an integer (even if the value
is representable as an integer), then 1:1 should not evalluate to an
integer vector.
the problem here is the notorious confusion between integers as numbers
with integers as representations of numbers, both in the docs and in the
design; the issue has been discussed before.
i think that from the point of view of most r users, this would be
consistent:
is(1) # integer vector numeric
is(1:1) # integer vector numeric
or this:
is(1) # numeric vector
is(1:1) # numeric vector
i find the following confused:
is(1.0) # numeric vector
is(1.0:1.0) # integer vector numeric
and the following a bug:
is(1.0:1.1) # integer vector numeric
(1.1 is certainly *not* an integer and certainly *not* representable in
an integer type)
and back to the original problem, even though you can explain it away
with the implicit conversion, i still find the behaviour of identical
irrational, since:
identical(1, 1.0)
[1] TRUE
so that there should be nothing wrong in identical(x,y) returning TRUE
after y = y[1:10].
vQ
[EMAIL PROTECTED] wrote:
> the str function shows that x is an int and y is a num so it's
> probably not a bug. or maybe the conversion to num is but probably
> not the identical.
>
> x = 1:10
> y = 1:10
>
> all.equal(x,y)
> identical(x,y)
>
> y[11] = 11
> y = y[1:10]
>
> all.equal(x,y)
> identical(x,y)
>
> print(str(y))
> print(str(x))
__
R-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Re: [R] odd behaviour of identical
If you want them to be identical, then you have to explicitly assign an integer to the vector so that conversion is not done: > x = 1:10 > y = 1:10 > > all.equal(x,y) [1] TRUE > > identical(x,y) [1] TRUE > > > y[11] = 11L > y = y[1:10] > > all.equal(x,y) [1] TRUE > > identical(x,y) [1] TRUE > On Sun, Oct 26, 2008 at 6:39 PM, Wacek Kusnierczyk <[EMAIL PROTECTED]> wrote: > given what ?identical says, i 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] > > 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 > day22 > svn rev45424 > language R > version.string R version 2.7.0 (2008-04-22) > > > vQ > > -- > --- > Wacek Kusnierczyk, MD PhD > > Email: [EMAIL PROTECTED] > Phone: +47 73591875, +47 72574609 > > Department of Computer and Information Science (IDI) > Faculty of Information Technology, Mathematics and Electrical Engineering > (IME) > Norwegian University of Science and Technology (NTNU) > Sem Saelands vei 7, 7491 Trondheim, Norway > Room itv303 > > Bioinformatics & Gene Regulation Group > Department of Cancer Research and Molecular Medicine (IKM) > Faculty of Medicine (DMF) > Norwegian University of Science and Technology (NTNU) > Laboratory Center, Erling Skjalgsons gt. 1, 7030 Trondheim, Norway > Room 231.05.060 > > __ > R-help@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide http://www.R-project.org/posting-guide.html > and provide commented, minimal, self-contained, reproducible code. > -- Jim Holtman Cincinnati, OH +1 513 646 9390 What is the problem that you are trying to solve? __ R-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] odd behaviour of identical
the str function shows that x is an int and y is a num so it's probably not a bug. or maybe the conversion to num is but probably not the identical. x = 1:10 y = 1:10 all.equal(x,y) identical(x,y) y[11] = 11 y = y[1:10] all.equal(x,y) identical(x,y) print(str(y)) print(str(x)) On Sun, Oct 26, 2008 at 5:39 PM, Wacek Kusnierczyk wrote: given what ?identical says, i 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] 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-gnustatusmajor 2 minor 7.0 year 2008 month 04 day22 svn rev45424 language R version.string R version 2.7.0 (2008-04-22) vQ -- --- Wacek Kusnierczyk, MD PhD Email: [EMAIL PROTECTED] Phone: +47 73591875, +47 72574609 Department of Computer and Information Science (IDI) Faculty of Information Technology, Mathematics and Electrical Engineering (IME) Norwegian University of Science and Technology (NTNU) Sem Saelands vei 7, 7491 Trondheim, Norway Room itv303 Bioinformatics & Gene Regulation Group Department of Cancer Research and Molecular Medicine (IKM) Faculty of Medicine (DMF) Norwegian University of Science and Technology (NTNU) Laboratory Center, Erling Skjalgsons gt. 1, 7030 Trondheim, Norway Room 231.05.060 __ R-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code. __ R-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
[R] odd behaviour of identical
given what ?identical says, i 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] 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 day22 svn rev45424 language R version.string R version 2.7.0 (2008-04-22) vQ -- --- Wacek Kusnierczyk, MD PhD Email: [EMAIL PROTECTED] Phone: +47 73591875, +47 72574609 Department of Computer and Information Science (IDI) Faculty of Information Technology, Mathematics and Electrical Engineering (IME) Norwegian University of Science and Technology (NTNU) Sem Saelands vei 7, 7491 Trondheim, Norway Room itv303 Bioinformatics & Gene Regulation Group Department of Cancer Research and Molecular Medicine (IKM) Faculty of Medicine (DMF) Norwegian University of Science and Technology (NTNU) Laboratory Center, Erling Skjalgsons gt. 1, 7030 Trondheim, Norway Room 231.05.060 __ R-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
