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 t
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() inste
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)))
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, th
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 no
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 worryi
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, bu
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] = 1
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 anothe
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
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,
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
12 matches
Mail list logo
