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)))
}
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()
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
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
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
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
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,
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
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
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,
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
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]
12 matches
Mail list logo
