sarah manderni
2015-Mar-02 13:46 UTC
[Rd] R-devel does not update the C++ returned variables
Thanks! I went through the online posts which supports the power of .Call over .C. But my probably naive question is why does this work for my code with R but not R-devel? And another question is related to using .Call. Based on the manual page, I do not need to change the function parameters when using .Call. So I can run like this: .Call("sppedUp", D, S, pD, pS, nrow(D), as.integer(N), length(N), ssq[i], i, as.integer(B), overlaps, overlaps.P) But I am receiving the memory(?) related error: terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc Now that I am running the code using .Call. Thanks. On Mon, Mar 2, 2015 at 2:01 PM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote:> On 02/03/2015 3:50 AM, sarah manderni wrote: > > Hi, > > > > Within my R code, I am using a C++ function as below: > > > > overlaps <- matrix(0, nrow=B, ncol=length(N)) > > overlaps.P <- matrix(0, nrow=B, ncol=length(N)) > > > > .C("speedUp", D, S, pD, pS, nrow(D), as.integer(N), length(N), > > ssq[i], i, as.integer(B), overlaps, overlaps.P, DUP=FALSE) > > > > > > the function "speedUp", is supposed to update matrices overlaps and > > overlaps.P and it works with official R versions. > > However, using the same code in R-devel, it does not update matrices and > > they remain all zero without returning any errors. > > See the NEWS: DUP=FALSE is now ignored. It led to too many bugs. Use > the .Call interface if duplication causes problems. > > Duncan Murdoch > > > But, if I store the return values from C function in a variable lets say > > "test" as follows: > > > > test <- .C("speedUp", D, S, pD, pS, nrow(D), as.integer(N), > > length(N), > > ssq[i], i, as.integer(B), overlaps, overlaps.P, DUP=FALSE) > > > > then the corresponding element of test to matrix "overlaps" > > (test[["overlaps"]]) again has the updated values (correct non-zero > values) > > though the overlaps matrix itself is still empty. > > > > I mean in official R, the "overlaps" matrix is updated after calling the > > function but not in R-devel. Also it works in both environment and return > > correct values to variable "test" in R-devel as well. > > Did you face any similar problem so that R-devel does not update the > > variable returned by C++? > > > > Thanks for the help. > > > > [[alternative HTML version deleted]] > > > > ______________________________________________ > > R-devel at r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > >[[alternative HTML version deleted]]
Duncan Murdoch
2015-Mar-02 14:09 UTC
[Rd] R-devel does not update the C++ returned variables
On 02/03/2015 8:46 AM, sarah manderni wrote:> Thanks! I went through the online posts which supports the power of > .Call over .C. But my probably naive question is why does this work > for my code with R but not R-devel?Because of the change mentioned in the NEWS file.> And another question is related to using .Call. Based on the manual > page, I do not need to change the function parameters when using > .Call. So I can run like this: > .Call("sppedUp", D, S, pD, pS, nrow(D), as.integer(N), length(N), > ssq[i], i, as.integer(B), overlaps, overlaps.P) > > But I am receiving the memory(?) related error: > terminate called after throwing an instance of 'std::bad_alloc' > what(): std::bad_alloc > Now that I am running the code using .Call.Code using .Call is quite different from code using .C. My guess would be that you didn't get all the details right. I generally recommend that people use Rcpp, which hides a lot of the details. It will generate your .Call calls for you, and generate the C++ code that receives them; you just need to think about the real problem, not the interface. It has its own learning curve, but I think it is easier than using the low-level code that you need to work with .Call. Duncan Murdoch> > Thanks. > > On Mon, Mar 2, 2015 at 2:01 PM, Duncan Murdoch > <murdoch.duncan at gmail.com <mailto:murdoch.duncan at gmail.com>> wrote: > > On 02/03/2015 3:50 AM, sarah manderni wrote: > > Hi, > > > > Within my R code, I am using a C++ function as below: > > > > overlaps <- matrix(0, nrow=B, ncol=length(N)) > > overlaps.P <- matrix(0, nrow=B, ncol=length(N)) > > > > .C("speedUp", D, S, pD, pS, nrow(D), as.integer(N), > length(N), > > ssq[i], i, as.integer(B), overlaps, overlaps.P, > DUP=FALSE) > > > > > > the function "speedUp", is supposed to update matrices overlaps and > > overlaps.P and it works with official R versions. > > However, using the same code in R-devel, it does not update > matrices and > > they remain all zero without returning any errors. > > See the NEWS: DUP=FALSE is now ignored. It led to too many > bugs. Use > the .Call interface if duplication causes problems. > > Duncan Murdoch > > > But, if I store the return values from C function in a variable > lets say > > "test" as follows: > > > > test <- .C("speedUp", D, S, pD, pS, nrow(D), as.integer(N), > > length(N), > > ssq[i], i, as.integer(B), overlaps, overlaps.P, > DUP=FALSE) > > > > then the corresponding element of test to matrix "overlaps" > > (test[["overlaps"]]) again has the updated values (correct > non-zero values) > > though the overlaps matrix itself is still empty. > > > > I mean in official R, the "overlaps" matrix is updated after > calling the > > function but not in R-devel. Also it works in both environment > and return > > correct values to variable "test" in R-devel as well. > > Did you face any similar problem so that R-devel does not update the > > variable returned by C++? > > > > Thanks for the help. > > > > [[alternative HTML version deleted]] > > > > ______________________________________________ > > R-devel at r-project.org <mailto:R-devel at r-project.org> mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > >
Dirk Eddelbuettel
2015-Mar-02 14:43 UTC
[Rd] R-devel does not update the C++ returned variables
On 2 March 2015 at 09:09, Duncan Murdoch wrote: | I generally recommend that people use Rcpp, which hides a lot of the | details. It will generate your .Call calls for you, and generate the | C++ code that receives them; you just need to think about the real | problem, not the interface. It has its own learning curve, but I think | it is easier than using the low-level code that you need to work with .Call. Thanks for that vote, and I second that. And these days the learning is a lot flatter than it was a decade ago: R> Rcpp::cppFunction("NumericVector doubleThis(NumericVector x) { return(2*x); }") R> doubleThis(c(1,2,3,21,-4)) [1] 2 4 6 42 -8 R> That defined, compiled, loaded and run/illustrated a simple function. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org