[Rd] Inconsistent results from .C()
Robin Evans
rje42 at cam.ac.uk
Mon May 20 17:12:16 CEST 2013
Hello,
I've run into a problem which is both maddening and rather hard to
replicate, therefore I wondered if someone might know of a plausible
explanation for it. I couldn't find anything in the archives, though
maybe I'm searching for the wrong thing.
I'm calling some C code using .C, and get the vector I'm interested in
back as the 7th location in the returned list. However I find that if
I try to inspect the contents of this entry in the list in some ways,
I get one answer, and if I look at it in others I get a different
answer. It's quite possible that there's something wrong with the C
code, but this doesn't seem to explain why this phenomenon would occur
in R.
The problem does not always occur - I have to run the code a few times
and then call the console when it does, but the commands below show
what can happen when it does. I apologise for not being able to get a
cleaner example. Full code and output is below, but here is a
stylised version:
The following all give one answer (which is the wrong answer as far as
I'm concerned) :
* printing the whole list :
.C(...) # and looking at the 7th entry
* applying c() to the 7th element of the list
c(.C(...)[[7]])
* assigning the 7th element to a vector:
x = .C(...)[[7]];
x
these give a different answer (which is the answer I would hope the C
code returns):
* using dput on the 7th entry:
dput(.C(...)[[7]])
* applying c() and then dput()
dput(c(.C(...)[[7]]))
* just printing the 7th entry of the list
.C(...)[[7]]
The answers are consistent in the sense that I always get the same
answers from running the same command in the console. I have tried
inspecting the returned objects to see if the objects are somehow of a
different class than I expect, or are just being printed oddly, but
have not found anything untoward.
Any suggestions would be much appreciated!
Regards,
Robin
# THESE COMMANDS GIVE ONE ANSWER
# [the correct answer always begins with 1, the incorrect with -1]
> .C("oneMargin", c(1L,1L,1L,1L,1L), c(1L,1L,1L,1L,1L), 1L, c(2L,2L,2L,2L,2L), 5L, ptr1, ptr2)[[7]]
[1] 1 -1 -1 1 -1 1 1 -1 -1 1 1 -1 1 -1 -1 1 -1 1 1 -1 1 -1
-1 1 1 -1 -1 1 -1 1 1 -1
> dput(.C("oneMargin", c(1L,1L,1L,1L,1L), c(1L,1L,1L,1L,1L), 1L, c(2L,2L,2L,2L,2L), 5L, ptr1, ptr2)[[7]])
c(1L, -1L, -1L, 1L, -1L, 1L, 1L, -1L, -1L, 1L, 1L, -1L, 1L, -1L,
-1L, 1L, -1L, 1L, 1L, -1L, 1L, -1L, -1L, 1L, 1L, -1L, -1L, 1L,
-1L, 1L, 1L, -1L)
> x=dput(c(.C("oneMargin", c(1L,1L,1L,1L,1L), c(1L,1L,1L,1L,1L), 1L, c(2L,2L,2L,2L,2L), 5L, ptr1, ptr2)[[7]]))
c(1L, -1L, -1L, 1L, -1L, 1L, 1L, -1L, -1L, 1L, 1L, -1L, 1L, -1L,
-1L, 1L, -1L, 1L, 1L, -1L, 1L, -1L, -1L, 1L, 1L, -1L, -1L, 1L,
-1L, 1L, 1L, -1L)
> x
[1] 1 -1 -1 1 -1 1 1 -1 -1 1 1 -1 1 -1 -1 1 -1 1 1 -1 1 -1
-1 1 1 -1 -1 1 -1 1 1 -1
# THESE ALL GIVE A DIFFERENT ONE!
> .C("oneMargin", c(1L,1L,1L,1L,1L), c(1L,1L,1L,1L,1L), 1L, c(2L,2L,2L,2L,2L), 5L, ptr1, ptr2)
# (OTHER ELEMENTS OF LIST REMOVED)
[[7]]
[1] -1 -1 1 1 1 1 -1 -1 1 1 -1 -1 -1 -1 1 1 1 1 -1 -1 -1 -1
1 1 -1 -1 1 1 1 1 -1 -1
> c(.C("oneMargin", c(1L,1L,1L,1L,1L), c(1L,1L,1L,1L,1L), 1L, c(2L,2L,2L,2L,2L), 5L, ptr1, ptr2)[[7]])
[1] -1 -1 1 1 1 1 -1 -1 1 1 -1 -1 -1 -1 1 1 1 1 -1 -1 -1 -1
1 1 -1 -1 1 1 1 1 -1 -1
> x = .C("oneMargin", c(1L,1L,1L,1L,1L), c(1L,1L,1L,1L,1L), 1L, c(2L,2L,2L,2L,2L), 5L, ptr1, ptr2)[[7]]
> x
[1] -1 -1 1 1 1 1 -1 -1 1 1 -1 -1 -1 -1 1 1 1 1 -1 -1 -1 -1
1 1 -1 -1 1 1 1 1 -1 -1
--
Robin Evans
Statistical Laboratory
University of Cambridge
blog: itsastatlife.blogspot.com
web: www.statslab.cam.ac.uk/~rje42
Causal Inference Workshop July 15th:
http://www.statslab.cam.ac.uk/~rje42/uai13/main.htm
More information about the R-devel
mailing list