From edd at debian.org Wed Oct 1 14:06:38 2014 From: edd at debian.org (Dirk Eddelbuettel) Date: Wed, 1 Oct 2014 07:06:38 -0500 Subject: [Rcpp-devel] statement about rcpp11 ? In-Reply-To: <5429C43F.4070501@thon.cc> References: <5429C43F.4070501@thon.cc> Message-ID: <21547.61006.875033.93261@max.nulle.part> Jonathon, You asked me about Rcpp11 -- but I don't think I should take that question, or at least not in this forum (ask me somewhere else one day, preferably over a cold drink). Why, you ask? Two reasons: First, this is the rcpp-devel list dedicated to deployment and development of Rcpp. Second, I am not involved in Rcpp11, and am probably not the person you want speaking about it. Now, there were two related follow-ups regarding Rcpp, and I address those below. | (because presumably Rcpp doesn't support C++11... but of course it does). Indeed. We said it several times, but it bears repeating: Rcpp has supported C++11 for years, and will continue to do so. Similarly, support for C++14, C++17, ... will be added as compiler (mainly g++ and clang++) support grows. The Rcpp team strives to keep all options open going forward as both compilers and the R build system support them -- but without foregoing backwards compatibility which is important to us as well. To us, this arrangement offers the best of both worlds. New C++ language features are available to all, yet users of existing code can be assurred that it ought to run as it has before. | what is the future of rcpp? Rcpp is being actively developed by several of us, and we plan on adding lots more features and refinements in the years ahead. And usage of Rcpp is equally vibrant: we passed the '200 packages on CRAN' mark in April, and are now already more than a third higher at 274 on CRAN, plus 27 more on BioC [release, more in dev], much more on GitHub etc pp. Hope this helps, Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org From jon at thon.cc Wed Oct 1 14:38:09 2014 From: jon at thon.cc (Jonathon Love) Date: Wed, 01 Oct 2014 14:38:09 +0200 Subject: [Rcpp-devel] statement about rcpp11 ? In-Reply-To: <21547.61006.875033.93261@max.nulle.part> References: <5429C43F.4070501@thon.cc> <21547.61006.875033.93261@max.nulle.part> Message-ID: <542BF5B1.3050503@thon.cc> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 thanks dirk, i appreciate you taking the time to respond; and this makes things clearer for me going forward. cheers jonathon > | what is the future of rcpp? > > Rcpp is being actively developed by several of us, and we plan on > adding lots more features and refinements in the years ahead. > > And usage of Rcpp is equally vibrant: we passed the '200 packages > on CRAN' mark in April, and are now already more than a third > higher at 274 on CRAN, plus 27 more on BioC [release, more in dev], > much more on GitHub etc pp. > > Hope this helps, Dirk > - -- JASP - A Fresh Way to Do Statistics http://jasp-stats.org/ - -- How happy is he born and taught, That serveth not another's will; Whose armour is his honest thought, And simple truth his utmost skill This man is freed from servile bands Of hope to rise, or fear to fall: Lord of himself, though not of lands, And, having nothing, yet hath all. -- Sir Henry Wotton -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUK/WxAAoJEH277gjmPGDYoEcP/2AW7wD87WjmCfw9/Jho+f+a ZcrgyzLKE9zskZE8UbqrAAAHxexL2fSQWsMFsqbRzktVfNoyF/EPYQvf4x2BIwgY yC782OXaY5xU/hkpR6xcKjX5SOWUFWk7ygT3MyXRd5dq0EEBys3IHXu+BHuIS1UN 0S8xUq8pmqlPdTAcEuO4cvqO1DGsVvJzZfAAF392K7puTn0mt7C+zuAiqoQu9QOP zdqMQ43lqe8EB+/awGrKAeV4I02lM6xkwyJPb/8OKgW6h7tIZOJdWeSdpGAdNpOH sKnsQ+x+ko86ooegD9UIyFUjZP30z31dD/PLQ49DKQ1LyhBTD32gweDK25+VTcB/ kbqsRqEjAVpcluPW9KPn6xWIMGmVLZsd0Mv45r+AiMXZzcm22DAopnA/WMZhDoTZ W5hIe9GhIvIeUWsPEQOFm1DA8IxxsEov4oH0xwSU5C/hsqR3VcudH83QyhbuP1bA Q+thibpElo42gXbJunn5r2clxNAzjyPh5rN7jvJIhmMfr/+GTfQlOHvrGUax62RQ eXxcxyocPeCU+FZ4PifGg0w/kLd5Nr7+aM/pf1p8WFM9Mv6aYYEvKJsnwknm6bSs B+KRgwkWTFEVoc1mlZNK1tWYs7V4VpFmyjj7AtG+dHJNPQryCjhDfIF6oqUyZS1B UDopvEJMukOEGEMkiwxY =OBtn -----END PGP SIGNATURE----- From shaniw_21 at yahoo.com Thu Oct 2 14:08:45 2014 From: shaniw_21 at yahoo.com (Shanika Wickramasuriya) Date: Thu, 2 Oct 2014 05:08:45 -0700 Subject: [Rcpp-devel] MappedSparseMatrix in RcppEigen package Message-ID: <1412251725.83441.YahooMailNeo@web160703.mail.bf1.yahoo.com> Hi, I want to post the following post to the list. I want to use conjugate gradient algorithm implemented in RcppEigen package for solving large sparse matrices. Since I am new to Rcpp and C++, I just started with the dense matrices. // [[Rcpp::depends(RcppEigen)]] #include #include #include using Eigen::SparseMatrix; using Eigen::MappedSparseMatrix; using Eigen::Map; using Eigen::MatrixXd; using Eigen::VectorXd; using Rcpp::as; using Eigen::ConjugateGradient; typedef Eigen::MappedSparseMatrix MSpMat; // [[Rcpp::export]] VectorXd getEigenValues(SEXP As, SEXP bs) { const Map A(as > (As)); const Map b(as > (bs)); ConjugateGradient cg; cg.compute(A); VectorXd x=cg.solve(b); return x; } This works as expected. Therefore, I thought to extend this to suit to sparse matrices. // [[Rcpp::depends(RcppEigen)]] #include #include #include using Eigen::SparseMatrix; using Eigen::MappedSparseMatrix; using Eigen::Map; using Eigen::MatrixXd; using Eigen::VectorXd; using Rcpp::as; using Eigen::ConjugateGradient; typedef Eigen::MappedSparseMatrix MSpMat; // [[Rcpp::export]] VectorXd getEigenValues(SEXP As, SEXP bs) { const MSpMat A = as(As); const Map b(as > (bs)); ConjugateGradient > cg; cg.compute(A); VectorXd x=cg.solve(b); return x; } However, this tends to give really strange results. The code in itself is also not giving any errors. Hope someone could help me to correct this error. Thanks. Regards, Shanika Wickramasuriya -------------- next part -------------- An HTML attachment was scrubbed... URL: From lafaye at DMS.UMontreal.CA Fri Oct 3 18:04:14 2014 From: lafaye at DMS.UMontreal.CA (Pierre Lafaye de Micheaux) Date: Fri, 03 Oct 2014 12:04:14 -0400 Subject: [Rcpp-devel] Rcpp: Error: not compatible with requested type Message-ID: <542EC8FE.7060407@dms.umontreal.ca> Dear members of the list, I have a problem using Rcpp in one of my packages. It tried the best I could to simplify my code so that the error is reproducible and this is what I was able to obtain. The code is self contain (really, I checked) and as minimal as possible (at least for me, sorry for not being able to simplify it further). I work under Linux with R 3.1.1. I have this C++ code: |#include #include using namespace Rcpp; extern"C" { SEXP gensampleRcpp2( Function rlawfunc, SEXP n) { Rcpp::RNGScope __rngScope; return Rcpp::List::create(Rcpp::Named("sample") = rlawfunc(n), Rcpp::Named("law.name") = "", Rcpp::Named("law.pars") = R_NilValue); } RcppExport SEXP gensampleRcpp(SEXP rlawfuncSEXP, SEXP nSEXP) { BEGIN_RCPP Function rlawfunc= Rcpp::as(rlawfuncSEXP); IntegerVector n= Rcpp::as(nSEXP); SEXP __result= gensampleRcpp2(rlawfunc, n); return Rcpp::wrap(__result); END_RCPP } SEXP compquantRcpp2(IntegerVector n, IntegerVector M, Function Rlaw) { int i; GetRNGstate(); for (i=1;i<=M[0];i++) { List resultsample= gensampleRcpp2(Rlaw, n); NumericVector mysample= Rcpp::as(resultsample["sample"]); } PutRNGstate(); return Rcpp::List::create(Rcpp::Named("law.pars") = ""); } RcppExport SEXP compquantRcpp(SEXP nSEXP, SEXP MSEXP, SEXP RlawSEXP) { BEGIN_RCPP IntegerVector n= Rcpp::as(nSEXP); IntegerVector M= Rcpp::as(MSEXP); Function Rlaw= Rcpp::as(RlawSEXP); SEXP __result= compquantRcpp2(n, M, Rlaw); return Rcpp::wrap(__result); END_RCPP } }| and this R code: |compquant<- function(n=50,M=10^3,Rlaw=rnorm) { out<- .Call("compquantRcpp",n=as.integer(n),M=as.integer(M),as.function(Rlaw),PACKAGE="PoweR") return(out) }| in a package called PoweR (in fact the above codes are simplifications of my own code so do no try to understand the statistical purpose of it). When I compile my package (under Linux and R version 3.1.0) and issue the following R command in the console: |require(PoweR) compquant() | I get the following error: *Error: not compatible with requested type* Do you have any idea on what could be the problem and how to solve it? Or any idea on simplifying further? Many thanks in advance for any idea. Best regards, Pierre Lafaye de Micheaux -------------- next part -------------- An HTML attachment was scrubbed... URL: From edd at debian.org Fri Oct 3 18:36:36 2014 From: edd at debian.org (Dirk Eddelbuettel) Date: Fri, 3 Oct 2014 11:36:36 -0500 Subject: [Rcpp-devel] Rcpp: Error: not compatible with requested type In-Reply-To: <542EC8FE.7060407@dms.umontreal.ca> References: <542EC8FE.7060407@dms.umontreal.ca> Message-ID: <21550.53396.616019.476282@max.nulle.part> Pierre, It is not clear what your code is actually trying to do. The following should be equivalent (as best as I can tell), works (!!) and makes life a lot easier via Attributes. ------- save this as eg /tmp/pierre.cpp ------------------------------------- #include // [[Rcpp::export]] Rcpp::List newCompQuant(int n, int M, Rcpp::Function f) { Rcpp::Rcout << "n : " << n << std::endl << "M : " << M << std::endl; return Rcpp::List::create(Rcpp::Named("sample") = f, Rcpp::Named("law.name") = " ", Rcpp::Named("law.pars") = R_NilValue); } /*** R res <- newCompQuant(n=50, M=10^3, f=norm) print(str(res)) */ ----------------------------------------------------------------------------- In R, then do R> Rcpp::sourceCpp("/tmp/pierre.cpp") for which I then get: R> sourceCpp("/tmp/pierre.cpp") R> res <- newCompQuant(n=50, M=10^3, f=rnorm) n : 50 M : 1000 R> print(str(res)) List of 3 $ sample :function (n, mean = 0, sd = 1) $ law.name: chr " " $ law.pars: NULL NULL R> Attributes also take care of RNGScope, and past discussions here have seen it help with repeated calls (with a 'big' N of number of repeats) where manually dealing with scope and temp objects may otherwise create a wrinkle. Hth, Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org From edd at debian.org Fri Oct 3 18:49:50 2014 From: edd at debian.org (Dirk Eddelbuettel) Date: Fri, 3 Oct 2014 11:49:50 -0500 Subject: [Rcpp-devel] Rcpp: Error: not compatible with requested type In-Reply-To: <21550.53396.616019.476282@max.nulle.part> References: <542EC8FE.7060407@dms.umontreal.ca> <21550.53396.616019.476282@max.nulle.part> Message-ID: <21550.54190.910917.608343@max.nulle.part> Oh, and I missed one call to a subordinate function. So add // [[Rcpp::export]] SEXP newCompQuant2(int n, int M, Rcpp::Function f) { SEXP res = compquantRcpp2(n, M, f); return res; } and at the bottom call it: res <- newCompQuant2(n=50, M=10^3, f=rnorm) print(str(res)) and then the result is R> res <- newCompQuant2(n=50, M=10^3, f=rnorm) R> print(str(res)) List of 1 $ law.pars: chr "" NULL R> just like you were told as well on StackOverflow. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org From lafaye at dms.umontreal.ca Sat Oct 4 00:19:05 2014 From: lafaye at dms.umontreal.ca (Pierre Lafaye de Micheaux) Date: Fri, 03 Oct 2014 18:19:05 -0400 Subject: [Rcpp-devel] Rcpp: Error: not compatible with requested type In-Reply-To: <21550.54190.910917.608343@max.nulle.part> References: <542EC8FE.7060407@dms.umontreal.ca> <21550.53396.616019.476282@max.nulle.part> <21550.54190.910917.608343@max.nulle.part> Message-ID: <542F20D9.3090302@dms.umontreal.ca> Dear Dirk, Thank you very much for this. I modified slightly your own code so that it is very similar (for the names of the arguments) to the one on StackOverflow: http://stackoverflow.com/questions/26181068/rcpp-error-not-compatible-with-requested-type This gives me this code saved in /tmp/pierre.cpp: ----------------------------------------------------------------------------------------------- #include // [[Rcpp::export]] Rcpp::List gensampleRcpp2(Rcpp::Function rlawfunc, Rcpp::IntegerVector n) { Rcpp::RNGScope __rngScope; return Rcpp::List::create(Rcpp::Named("sample") = rlawfunc(n), Rcpp::Named("law.name") = " ", Rcpp::Named("law.pars") = R_NilValue); } // [[Rcpp::export]] Rcpp::List compQuantRcpp2(Rcpp::IntegerVector n, Rcpp::IntegerVector M, Rcpp::Function Rlaw) { int i; GetRNGstate(); for (i=1;i<=M[0];i++) { Rcpp::List resultsample = gensampleRcpp2(Rlaw, n); Rcpp::NumericVector mysample = resultsample["sample"]; } PutRNGstate(); return Rcpp::List::create(Rcpp::Named("law.pars") = ""); } /*** R res <- compQuantRcpp2(n=50, M=10^3, Rlaw=rnorm) print(str(res)) */ ----------------------------------------------------------------------------------------------- Please have a look to compare both codes. They are very similar. I then issue this command in R: for (i in 1:100) Rcpp::sourceCpp("tmp/pierre.cpp") Magic! No error occur. So now I will try to implement all this in a package (I guess I should read more carefully the Attributes vignette that you told me about. Am I right? Is it the good document to read for that purpose?). By the way, since both codes are such similar, would you have an explanation on what goes wrong with what I have written on StackOverflow? Regards, Pierre L. Le 03/10/2014 12:49, Dirk Eddelbuettel a ?crit : > Oh, and I missed one call to a subordinate function. So add > > // [[Rcpp::export]] > SEXP newCompQuant2(int n, int M, Rcpp::Function f) { > SEXP res = compquantRcpp2(n, M, f); > return res; > } > > and at the bottom call it: > > res <- newCompQuant2(n=50, M=10^3, f=rnorm) > print(str(res)) > > and then the result is > > R> res <- newCompQuant2(n=50, M=10^3, f=rnorm) > > R> print(str(res)) > List of 1 > $ law.pars: chr "" > NULL > R> > > just like you were told as well on StackOverflow. > > Dirk > From edd at debian.org Sat Oct 4 00:57:29 2014 From: edd at debian.org (Dirk Eddelbuettel) Date: Fri, 3 Oct 2014 17:57:29 -0500 Subject: [Rcpp-devel] Rcpp: Error: not compatible with requested type In-Reply-To: <542F20D9.3090302@dms.umontreal.ca> References: <542EC8FE.7060407@dms.umontreal.ca> <21550.53396.616019.476282@max.nulle.part> <21550.54190.910917.608343@max.nulle.part> <542F20D9.3090302@dms.umontreal.ca> Message-ID: <21551.10713.176177.975093@max.nulle.part> Hi Pierre, On 3 October 2014 at 18:19, Pierre Lafaye de Micheaux wrote: | Dear Dirk, | | Thank you very much for this. I modified slightly your own code so that | it is very similar (for the names of the arguments) to the one on | StackOverflow: | http://stackoverflow.com/questions/26181068/rcpp-error-not-compatible-with-requested-type | | This gives me this code saved in /tmp/pierre.cpp: | | ----------------------------------------------------------------------------------------------- | #include | | // [[Rcpp::export]] | Rcpp::List gensampleRcpp2(Rcpp::Function rlawfunc, Rcpp::IntegerVector n) { | Rcpp::RNGScope __rngScope; ^^^^^^^^^^^^^^^^^^^^^^^^^^ Not needed. Rcpp Attributes adds that for your, and better. | return Rcpp::List::create(Rcpp::Named("sample") = rlawfunc(n), | Rcpp::Named("law.name") = " ", | Rcpp::Named("law.pars") = R_NilValue); | } | | // [[Rcpp::export]] | Rcpp::List compQuantRcpp2(Rcpp::IntegerVector n, Rcpp::IntegerVector M, | Rcpp::Function Rlaw) { | int i; | GetRNGstate(); Not needed. Rcpp Attributes deals with that via RNGScope. | for (i=1;i<=M[0];i++) { | Rcpp::List resultsample = gensampleRcpp2(Rlaw, n); | Rcpp::NumericVector mysample = resultsample["sample"]; | } | PutRNGstate(); Ditto. So try without, and for kicks add verbose=TRUE to the call to sourceCpp(). | return Rcpp::List::create(Rcpp::Named("law.pars") = ""); | } | | | /*** R | res <- compQuantRcpp2(n=50, M=10^3, Rlaw=rnorm) | print(str(res)) | */ | ----------------------------------------------------------------------------------------------- | | Please have a look to compare both codes. They are very similar. | | I then issue this command in R: | for (i in 1:100) Rcpp::sourceCpp("tmp/pierre.cpp") | | Magic! No error occur. | | So now I will try to implement all this in a package (I guess I should | read more carefully the Attributes vignette that you told me about. Am I | right? Is it the good document to read for that purpose?). | | By the way, since both codes are such similar, would you have an | explanation on what goes wrong with what I have written on StackOverflow? I don't have time to drill through it function by function. The gist of it is that you were doing A LOT of forced manual conversions, and one of them goes bad. If you really want to know, add prints statements (or step through) and simplify. What you sent, even after your numerous prior emails was still not a __minimally__ reproducible example. The more complex the code is that you submit, the less likely it is volunteers will spend _their_ going through it for you. Dirk | Regards, | | Pierre L. | | | | Le 03/10/2014 12:49, Dirk Eddelbuettel a ?crit : | > Oh, and I missed one call to a subordinate function. So add | > | > // [[Rcpp::export]] | > SEXP newCompQuant2(int n, int M, Rcpp::Function f) { | > SEXP res = compquantRcpp2(n, M, f); | > return res; | > } | > | > and at the bottom call it: | > | > res <- newCompQuant2(n=50, M=10^3, f=rnorm) | > print(str(res)) | > | > and then the result is | > | > R> res <- newCompQuant2(n=50, M=10^3, f=rnorm) | > | > R> print(str(res)) | > List of 1 | > $ law.pars: chr "" | > NULL | > R> | > | > just like you were told as well on StackOverflow. | > | > Dirk | > | | _______________________________________________ | Rcpp-devel mailing list | Rcpp-devel at lists.r-forge.r-project.org | https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel -- http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org From Pierre.Gloaguen at ifremer.fr Sat Oct 4 01:57:01 2014 From: Pierre.Gloaguen at ifremer.fr (Pierre.Gloaguen at ifremer.fr) Date: Sat, 04 Oct 2014 01:57:01 +0200 Subject: [Rcpp-devel] R session crashes when largely using a Rcpp sourced function Message-ID: <20141004015701.1317100ree0hhbyl@vdmz1mail.ifremer.fr> Hello everyone, I am a new user of Rcpp, I use it to rewrite a whole R program. at the end of the program, my "final function is the following" #include #include #define _USE_MATH_DEFINES #include using namespace Rcpp; // [[Rcpp::depends("RcppArmadillo")]] List main_function_C(arma::vec X0,arma::vec XF,double t0, double tF, arma::mat Gamma, NumericVector piks,arma::mat muks, List Cks, int max_iter = 500){ List bounds = bounds_fun_C(piks,Cks,Gamma); double sup_bound = 0.5 *(as(bounds["alpha_bar"]) + as(bounds["delta_max"]) - as(bounds["delta_min"])); bool accept = false; int kappa = 0; arma::mat omegas(2,2);//arbitrary size, will change in loop NumericVector Psi(5);//arbitrary size, will change in loop for(int i = 0; i < max_iter; ++i){ kappa = rpois(1,(tF-t0)*sup_bound)[0]; if(kappa > 0){ Psi = stl_sort(runif(kappa,t0,tF)); NumericVector Upsilon = runif(kappa, 0, sup_bound); omegas = rubb_it_C(X0, XF, t0, tF, Psi); NumericVector phi_omega(kappa); for(int i = 1; i < kappa+2; i++){ phi_omega[i-1] = phi_C(arma::trans(omegas.row(i)), piks,muks,Cks,Gamma); } accept = all_C((phi_omega < Upsilon)); }//end if kappa >0 else{ accept = true; } if(accept){ break; } }//end for arma::mat res(kappa+2,3);//result matrix, if(kappa > 0){ res.submat(0,0,kappa+1,1) = omegas; res(0,2) = t0; for(int i =1; i < kappa+1;++i){ res(i,2) = Psi[i-1]; //Psi is of size kappa the index then goes till kappa-1 } res(kappa+1,2) = tF; } else{ res(0,arma::span(0,1)) = trans(X0); res(1,arma::span(0,1)) = trans(XF); res(0,2) = t0; res(kappa+1,2) = tF; } return List::create(Named("skel") = res, Named("accepted") = accept); } This function calls other funtion that I have written, all of them are attached on the cpp_funcs.cpp file. The sourceCpp performs well and I can, from R obtain the following result sourceCpp("cpp_funcs.cpp") X0 <- c(0.5,0.5) XF <- c(1,1) t0 <- 0 tF <- 1 Gam <- diag(0.1,2) ncomp=2 pis <- c(0.5,0.5) mu <- matrix(c(-1,1, 1,1),ncol=2,nrow=ncomp) cov <- list(diag(0.5,2),diag(1,2)) set.seed(123) test <- main_function_C(X0,XF,t0,tF,Gam,pis,mu,cov) test #$skel [,1] [,2] [,3] #[1,] 0.5000000 0.500000 0.0000000 #[2,] -0.1261731 1.313880 0.4089769 #[3,] 0.5564577 1.069211 0.7883051 #[4,] 1.0000000 1.000000 1.0000000 #$accepted #[1] TRUE PROBLEM: When I run the exact same code as above a large number of times, as this for(i in 1:1000){ ## same code as above } The r session aborts all the time, giving no error message but "R encountered a fatal error". I do not encounter this problem with the intermediate functions in the attached file (and, of course, I'm not asking for a debugging of those), I only have it with this one Is this a problem with my code? with how the loop is written?The List object? Is this a problem of the memory? It does it either on Rstudio or Rgui I work on windows 7, with R version 3.0.2 Rcpp 0.11.2 and RcppArmadillo 0.4.450.1.0 I also attach a R debugging file giving parameters for all intermediate functions. Sorry for the length of the function, I'm pretty sure the problem comes from the main function, but it sadly depends on others (which, as far as I know, don't pose problems) Thanks in advance for any help, Pierre Gloaguen -------------- next part -------------- library(Rcpp) library(RcppArmadillo) library(gtools) #At the beginning, all cpp_funcs.cpp functions should be commented #they are tested equentially # test all_C --------------------------------------------------------------- #adding allC function sourceCpp("cpp_funcs.cpp") for(i in 1:1000){ x <- sample(c(TRUE,FALSE),size=4,replace=T) test <- all_C(x) } # SEEMS OK # test trace_C ------------------------------------------------------------- #adding traceC sourceCpp("cpp_funcs.cpp") for(i in 1:1000){ x <- matrix(sample(100),nrow=10,ncol=10) test <- traceC(x) } #what if x is non square? If ncol > nrow, noprob x <- matrix(sample(20),nrow=5,ncol=4) test <- traceC(x) #Normal error message, so that would no be this #SEEMS OK # test stl_sort ------------------------------------------------------------ #adding stl_sort sourceCpp("cpp_funcs.cpp") for(i in 1:1000){ x <- runif(1000) test <- stl_sort(x) } #seems OK # test Mahalanobis ------------------------------------------------------------ #adding Mahalanobis sourceCpp("cpp_funcs.cpp") for(i in 1:1000){ x <- matrix(rnorm(100),ncol=2,nrow=50) y <- rnorm(2) cov <- rWishart(1,2,diag(1,2))[,,1] test <- Mahalanobis(x,y,cov) } #SEEMS OK # test dmvnorm_C ------------------------------------------------------------ #This function depends on Mahalanobis #adding dmvnorm_C sourceCpp("cpp_funcs.cpp") for(i in 1:1000){ x <- matrix(rnorm(100),ncol=2,nrow=50) y <- rnorm(2) cov <- rWishart(1,2,diag(1,2))[,,1] test <- dmvnorm_C(x,y,cov,log=FALSE) } #SEEMS OK # test bounds_fun_C ------------------------------------------------------------ #This function depends on trace_C #adding bounds_fun_C sourceCpp("cpp_funcs.cpp") for(i in 1:10000){ ncomp<- sample(1:5,size=1) pis <- rdirichlet(1,rep(1,ncomp))[1,] tmp <- rWishart(ncomp,2,diag(1,2)) cov <- lapply(1:ncomp,function(i) tmp[,,i]) Gam <- rWishart(ncomp,2,diag(1,2))[,,1] test <- bounds_fun_C(pis,cov,Gam) } #SEEMS OK # test phi_C ------------------------------------------------------------ #This function depends on trace_C, dmvnorm_C and bounds_fun_C #adding bounds_fun_C sourceCpp("cpp_funcs.cpp") for(i in 1:1000){ ncomp<- sample(1:5,size=1) x <- rnorm(2) pis <- rdirichlet(1,rep(1,ncomp))[1,] tmp <- rWishart(ncomp,2,diag(1,2)) mu <- matrix(rnorm(2*ncomp),ncol=2,nrow=ncomp) cov <- lapply(1:ncomp,function(i) tmp[,,i]) Gam <- rWishart(ncomp,2,diag(1,2))[,,1] test <- phi_C(x,pis,mu,cov,Gam) } #SEEMS OK BUT there was an unexplained abort at some point # test rubb_it_C ------------------------------------------------------------ #uses bounds_fun_C, stl_sort,phi_C,all_C #adding rubb_it_C sourceCpp("cpp_funcs.cpp") for(i in 1:10000){ ntime <- sample(1000,size=1) t0= 0 tF = 1 tmp_times <- sort(runif(ntime,t0,tF)) X0 <- rnorm(2) XF <- rnorm(2) test <- rubb_it_C(X0,XF,t0,tF,tmp_times) } #SEEMS OK # test simu_ea_seg_C ------------------------------------------------------------ #uses bounds_fun_C, stl_sort,phi_C,all_C,rubb_it_C #adding simu_ea_segC sourceCpp("cpp_funcs.cpp") for(i in 1:1000){ X0 <- c(0.5,0.5) XF <- c(1,1) t0 <- 0 tF <- 1 Gam <- diag(0.1,2) ncomp=2 pis <- c(0.5,0.5) mu <- matrix(c(-1,1, 1,1),ncol=2,nrow=ncomp) cov <- list(diag(0.5,2),diag(1,2)) set.seed(123) test <- main_function_C(X0,XF,t0,tF,Gam,pis,mu,cov) } -------------- next part -------------- #include #include #define _USE_MATH_DEFINES #include using namespace Rcpp; // [[Rcpp::depends("RcppArmadillo")]] // [[Rcpp::export]] bool all_C(LogicalVector x){// Equivalent to all function in R LogicalVector::iterator n = x.end(); for(LogicalVector::iterator i = x.begin(); i != n; ++i){ if(!x[*i]) return false; } return true; } // [[Rcpp::export]] double trace_C(arma::mat x){// Computing the trace of a squared matrix int n = x.n_rows; double out=0.0; for(int i=0;i < n;++i){ out += x(i,i); } return out; } // [[Rcpp::export]] arma::vec Mahalanobis(arma::mat x, arma::rowvec center, arma::mat cov){ int n = x.n_rows; arma::mat x_cen; x_cen.copy_size(x); for (int i=0; i < n; ++i) { x_cen.row(i) = x.row(i) - center; } return sum((x_cen * cov.i())%x_cen, 1); } // [[Rcpp::export]] arma::vec dmvnorm_C (arma::mat x,arma::rowvec mean, arma::mat sigma, bool log){ arma::vec distval = Mahalanobis(x, mean, sigma); double logdet = sum(arma::log(arma::eig_sym(sigma))); double log2pi = 1.8378770664093454835606594728112352797227949472755668; arma::vec logretval = -( (x.n_cols * log2pi + logdet + distval)/2 ) ; if(log){ return logretval; } else { return exp(logretval);} } // [[Rcpp::export]] NumericVector stl_sort(NumericVector x) {//function to sort a Numeric vector NumericVector y = clone(x); std::sort(y.begin(), y.end()); return y; } // [[Rcpp::export]] List bounds_fun_C(NumericVector piks, List Cks, arma::mat Gamma){//intermediate function IntegerVector is = (seq_along(piks)-1); IntegerVector::iterator ncomp_it = is.end(); int ncomp = Cks.size(); NumericVector dets(ncomp); NumericVector norms_Cinv(ncomp); NumericVector traces(ncomp); NumericVector maxeigen(ncomp); NumericVector norms_GiCinv(ncomp); arma::mat Gi = arma::inv(Gamma); for(IntegerVector::iterator i=is.begin(); i!=ncomp_it;++i){ arma::mat Ck = Cks[*i]; arma::mat Cki = arma::inv(Ck); dets[*i] = arma::det(2*M_PI*Ck); norms_Cinv[*i] = arma::norm(Cki,2); maxeigen[*i] = arma::norm(Ck,2); traces[*i] = trace_C(Cki); norms_GiCinv[*i] = arma::norm(Gi*Cki,2); } double delta_min = -sum(piks * pow(dets,-0.5) * traces); double delta_max = 2*exp(-1)*sum(piks * pow(norms_Cinv,2) * pow(dets,-0.5) * maxeigen); double alpha_bar = exp(-1)*sum(piks * pow(norms_GiCinv,2) * maxeigen/dets); return List::create(Named("delta_min") = delta_min, Named("delta_max") = delta_max, Named("alpha_bar") = alpha_bar); } // [[Rcpp::export]] double phi_C(arma::vec X, NumericVector piks,arma::mat muks, List Cks, arma::mat Gamma){//intermediate function int ncomp = piks.size(); List tmp=bounds_fun_C(piks,Cks,Gamma); double delta_min = as(tmp["delta_min"]); arma::vec GX = Gamma*X; arma::mat Xtmp(1,2);//to go in dmvnorm function Xtmp(0,0) = GX[0]; Xtmp(0,1) = GX[1]; arma::vec pi_gaus_dens(ncomp); arma::vec traces(ncomp); arma::vec norms_C_Ix(ncomp); arma::mat Gi = arma::inv(Gamma); arma::vec alpha(2); alpha.fill(0); double lapl_H = 0.0; for(int i = 0; i < ncomp;++i){ arma::rowvec mu = muks.row(i); arma::mat Ck = Cks[i]; arma::mat Cki = arma::inv(Ck); pi_gaus_dens[i] = piks[i]*dmvnorm_C(Xtmp,mu,Ck,false)[0]; traces[i] = trace_C(Cki); norms_C_Ix[i] = pow(arma::norm(Cki*(GX-arma::trans(mu)),2),2); lapl_H += pi_gaus_dens[i]*(norms_C_Ix[i]-traces[i]); alpha += pi_gaus_dens[i]*Gi*Cki*(GX-arma::trans(mu)); } double norm_alpha = pow(arma::norm(alpha,2),2); double res = 0.5*(norm_alpha+lapl_H-delta_min); return res; } arma::mat rubb_it_C(arma::vec X0,arma::vec XF,//Simulating a brownian bridge double t0, double tF,NumericVector times) { double XF1 = XF[0]; double XF2 = XF[1]; int n = times.size(); arma::vec X1(n+2); arma::vec X2(n+2); NumericVector ts(n+1);//times series for the loop ts[0] = t0; X1[0] = X0[0]; X2[0] = X0[1]; X1[n+1] = XF1; X2[n+1] = XF2; for(int i=1; i < (n+1); ++i){ ts[i] = times[i-1]; double tar = tF-ts[i];//time before the arrival double tdeb = ts[i]-ts[i-1];//time since the departure double ttot = tF-ts[i-1];//overall time X1[i] = (tar*X1[i-1]+tdeb*XF1)/ttot + rnorm(1,0,pow((tar*tdeb)/ttot,0.5))[0]; X2[i] = (tar*X2[i-1]+tdeb*XF2)/ttot + rnorm(1,0,pow((tar*tdeb)/ttot,0.5))[0]; } arma::mat res(n+2,2); res.col(0) = X1; res.col(1) = X2; return res; } // [[Rcpp::export]] List main_function_C(arma::vec X0,arma::vec XF,double t0, double tF, arma::mat Gamma, NumericVector piks,arma::mat muks, List Cks, int max_iter = 500){ List bounds = bounds_fun_C(piks,Cks,Gamma); double sup_bound = 0.5 *(as(bounds["alpha_bar"]) + as(bounds["delta_max"]) - as(bounds["delta_min"])); bool accept = false; int kappa = 0; arma::mat omegas(2,2);//arbitrary size, will change in loop NumericVector Psi(5);//arbitrary size, will change in loop for(int i = 0; i < max_iter; ++i){ kappa = rpois(1,(tF-t0)*sup_bound)[0]; if(kappa > 0){ Psi = stl_sort(runif(kappa,t0,tF)); NumericVector Upsilon = runif(kappa, 0, sup_bound); omegas = rubb_it_C(X0, XF, t0, tF, Psi); NumericVector phi_omega(kappa); for(int i = 1; i < kappa+2; i++){ phi_omega[i-1] = phi_C(arma::trans(omegas.row(i)), piks,muks,Cks,Gamma); } accept = all_C((phi_omega < Upsilon)); } else{ accept = true; } if(accept){ break; } } arma::mat res(kappa+2,3);//result matrix, if(kappa > 0){ res.submat(0,0,kappa+1,1) = omegas; res(0,2) = t0; for(int i =1; i < kappa+1;++i){ res(i,2) = Psi[i-1]; //Psi is of size kappa the index then goes till kappa-1 } res(kappa+1,2) = tF; } else{ res(0,arma::span(0,1)) = trans(X0); res(1,arma::span(0,1)) = trans(XF); res(0,2) = t0; res(kappa+1,2) = tF; } return List::create(Named("skel") = res, Named("accepted") = accept); } From lafaye at dms.umontreal.ca Sat Oct 4 20:36:17 2014 From: lafaye at dms.umontreal.ca (Pierre Lafaye de Micheaux) Date: Sat, 04 Oct 2014 14:36:17 -0400 Subject: [Rcpp-devel] Rcpp: Error: not compatible with requested type In-Reply-To: <21551.10713.176177.975093@max.nulle.part> References: <542EC8FE.7060407@dms.umontreal.ca> <21550.53396.616019.476282@max.nulle.part> <21550.54190.910917.608343@max.nulle.part> <542F20D9.3090302@dms.umontreal.ca> <21551.10713.176177.975093@max.nulle.part> Message-ID: <54303E21.1020405@dms.umontreal.ca> Thank you very much. That helped a lot. Have a nice day. Pierre L. Le 03/10/2014 18:57, Dirk Eddelbuettel a ?crit : > Hi Pierre, > > On 3 October 2014 at 18:19, Pierre Lafaye de Micheaux wrote: > | Dear Dirk, > | > | Thank you very much for this. I modified slightly your own code so that > | it is very similar (for the names of the arguments) to the one on > | StackOverflow: > | http://stackoverflow.com/questions/26181068/rcpp-error-not-compatible-with-requested-type > | > | This gives me this code saved in /tmp/pierre.cpp: > | > | ----------------------------------------------------------------------------------------------- > | #include > | > | // [[Rcpp::export]] > | Rcpp::List gensampleRcpp2(Rcpp::Function rlawfunc, Rcpp::IntegerVector n) { > | Rcpp::RNGScope __rngScope; > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Not needed. Rcpp Attributes adds that for your, and better. > > | return Rcpp::List::create(Rcpp::Named("sample") = rlawfunc(n), > | Rcpp::Named("law.name") = " ", > | Rcpp::Named("law.pars") = R_NilValue); > | } > | > | // [[Rcpp::export]] > | Rcpp::List compQuantRcpp2(Rcpp::IntegerVector n, Rcpp::IntegerVector M, > | Rcpp::Function Rlaw) { > | int i; > | GetRNGstate(); > > Not needed. Rcpp Attributes deals with that via RNGScope. > > | for (i=1;i<=M[0];i++) { > | Rcpp::List resultsample = gensampleRcpp2(Rlaw, n); > | Rcpp::NumericVector mysample = resultsample["sample"]; > | } > | PutRNGstate(); > > Ditto. > > So try without, and for kicks add verbose=TRUE to the call to sourceCpp(). > > | return Rcpp::List::create(Rcpp::Named("law.pars") = ""); > | } > | > | > | /*** R > | res <- compQuantRcpp2(n=50, M=10^3, Rlaw=rnorm) > | print(str(res)) > | */ > | ----------------------------------------------------------------------------------------------- > | > | Please have a look to compare both codes. They are very similar. > | > | I then issue this command in R: > | for (i in 1:100) Rcpp::sourceCpp("tmp/pierre.cpp") > | > | Magic! No error occur. > | > | So now I will try to implement all this in a package (I guess I should > | read more carefully the Attributes vignette that you told me about. Am I > | right? Is it the good document to read for that purpose?). > | > | By the way, since both codes are such similar, would you have an > | explanation on what goes wrong with what I have written on StackOverflow? > > I don't have time to drill through it function by function. The gist of it is > that you were doing A LOT of forced manual conversions, and one of them goes > bad. If you really want to know, add prints statements (or step through) and > simplify. > > What you sent, even after your numerous prior emails was still not a > __minimally__ reproducible example. > > The more complex the code is that you submit, the less likely it is > volunteers will spend _their_ going through it for you. > > Dirk > > | Regards, > | > | Pierre L. > | > | > | > | Le 03/10/2014 12:49, Dirk Eddelbuettel a ?crit : > | > Oh, and I missed one call to a subordinate function. So add > | > > | > // [[Rcpp::export]] > | > SEXP newCompQuant2(int n, int M, Rcpp::Function f) { > | > SEXP res = compquantRcpp2(n, M, f); > | > return res; > | > } > | > > | > and at the bottom call it: > | > > | > res <- newCompQuant2(n=50, M=10^3, f=rnorm) > | > print(str(res)) > | > > | > and then the result is > | > > | > R> res <- newCompQuant2(n=50, M=10^3, f=rnorm) > | > > | > R> print(str(res)) > | > List of 1 > | > $ law.pars: chr "" > | > NULL > | > R> > | > > | > just like you were told as well on StackOverflow. > | > > | > Dirk > | > > | > | _______________________________________________ > | Rcpp-devel mailing list > | Rcpp-devel at lists.r-forge.r-project.org > | https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel > From jeff.ct.wong at gmail.com Sun Oct 5 07:51:25 2014 From: jeff.ct.wong at gmail.com (Jeffrey Wong) Date: Sat, 4 Oct 2014 22:51:25 -0700 Subject: [Rcpp-devel] Grid Search in RcppParallel Message-ID: I am trying to use RcppParallel to do a fast grid search. The idea is to construct a matrix using R's expand.grid, then for each row of that matrix, x, call f(x). For simplicity the function f will always return a double. Since Rcpp can call an R function I was hoping RcppParallel would allow me to use a parallelFor to process the rows of the grid quickly. However, it keeps crashing R, and I am wondering if this is because an R function cannot be passed to RcppParallel? require(Rcpp) require(RcppParallel) grid = as.matrix(expand.grid(a = 1:5, b = 1:5)) foo = function(pars) {pars[1]^2 + pars[2]^2} RcppParallelGridSearch(grid, foo) in .cpp file #include using namespace Rcpp; // [[Rcpp::depends(RcppParallel)]] #include using namespace RcppParallel; struct GridSearch : public Worker { // source matrix const RMatrix grid; const Function f; // destination vector RVector output; // initialize with source and destination GridSearch(const NumericMatrix grid, const Function f, NumericVector output) : grid(grid), f(f), output(output) {} // take the square root of the range of elements requested void operator()(std::size_t begin, std::size_t end) { for (std::size_t i = begin; i < end; i++) { RMatrix::Row parameters = grid.row(i); output[i] = as(f(parameters)); } } }; // [[Rcpp::export]] NumericVector RcppParallelGridSearch(NumericMatrix grid, Function f) { // allocate the output matrix NumericVector output(grid.nrow()); // SquareRoot functor (pass input and output matrixes) GridSearch gridSearch(grid, f, output); // call parallelFor to do the work parallelFor(0, grid.nrow(), gridSearch); // return the output matrix return output; } -- Jeffrey Wong My portfolio: http://jeffreycwong.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From romain at r-enthusiasts.com Sun Oct 5 08:40:31 2014 From: romain at r-enthusiasts.com (Romain Francois) Date: Sun, 5 Oct 2014 08:40:31 +0200 Subject: [Rcpp-devel] Grid Search in RcppParallel In-Reply-To: References: Message-ID: <2D7175F0-8131-4E04-BD49-C7494DF49ACF@r-enthusiasts.com> Envoy? de mon iPhone > Le 5 oct. 2014 ? 07:51, Jeffrey Wong a ?crit : > > I am trying to use RcppParallel to do a fast grid search. The idea is to construct a matrix using R's expand.grid, then for each row of that matrix, x, call f(x). For simplicity the function f will always return a double. Since Rcpp can call an R function I was hoping RcppParallel would allow me to use a parallelFor to process the rows of the grid quickly. However, it keeps crashing R, and I am wondering if this is because an R function cannot be passed to RcppParallel? You definitely cannot call an R function concurrently. > require(Rcpp) > require(RcppParallel) > > grid = as.matrix(expand.grid(a = 1:5, b = 1:5)) > > foo = function(pars) {pars[1]^2 + pars[2]^2} > > RcppParallelGridSearch(grid, foo) > > in .cpp file > > #include > using namespace Rcpp; > > // [[Rcpp::depends(RcppParallel)]] > #include > using namespace RcppParallel; > > struct GridSearch : public Worker > { > // source matrix > const RMatrix grid; > const Function f; > > // destination vector > RVector output; > > // initialize with source and destination > GridSearch(const NumericMatrix grid, const Function f, NumericVector output) > : grid(grid), f(f), output(output) {} > > // take the square root of the range of elements requested > void operator()(std::size_t begin, std::size_t end) { > > for (std::size_t i = begin; i < end; i++) { > RMatrix::Row parameters = grid.row(i); > output[i] = as(f(parameters)); > } > } > }; > > // [[Rcpp::export]] > NumericVector RcppParallelGridSearch(NumericMatrix grid, Function f) { > > // allocate the output matrix > NumericVector output(grid.nrow()); > > // SquareRoot functor (pass input and output matrixes) > GridSearch gridSearch(grid, f, output); > > // call parallelFor to do the work > parallelFor(0, grid.nrow(), gridSearch); > > // return the output matrix > return output; > } > > -- > Jeffrey Wong > My portfolio: http://jeffreycwong.com > > _______________________________________________ > Rcpp-devel mailing list > Rcpp-devel at lists.r-forge.r-project.org > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From jj.allaire at gmail.com Sun Oct 5 12:39:50 2014 From: jj.allaire at gmail.com (JJ Allaire) Date: Sun, 5 Oct 2014 06:39:50 -0400 Subject: [Rcpp-devel] Grid Search in RcppParallel In-Reply-To: References: Message-ID: For executing R code in parallel you you may want to take a look at multicore (part of the parallel package built in to R). On Sun, Oct 5, 2014 at 1:51 AM, Jeffrey Wong wrote: > I am trying to use RcppParallel to do a fast grid search. The idea is to > construct a matrix using R's expand.grid, then for each row of that matrix, > x, call f(x). For simplicity the function f will always return a double. > Since Rcpp can call an R function I was hoping RcppParallel would allow me > to use a parallelFor to process the rows of the grid quickly. However, it > keeps crashing R, and I am wondering if this is because an R function cannot > be passed to RcppParallel? > > require(Rcpp) > require(RcppParallel) > > grid = as.matrix(expand.grid(a = 1:5, b = 1:5)) > > foo = function(pars) {pars[1]^2 + pars[2]^2} > > RcppParallelGridSearch(grid, foo) > > in .cpp file > > #include > using namespace Rcpp; > > // [[Rcpp::depends(RcppParallel)]] > #include > using namespace RcppParallel; > > struct GridSearch : public Worker > { > // source matrix > const RMatrix grid; > const Function f; > > // destination vector > RVector output; > > // initialize with source and destination > GridSearch(const NumericMatrix grid, const Function f, NumericVector > output) > : grid(grid), f(f), output(output) {} > > // take the square root of the range of elements requested > void operator()(std::size_t begin, std::size_t end) { > > for (std::size_t i = begin; i < end; i++) { > RMatrix::Row parameters = grid.row(i); > output[i] = as(f(parameters)); > } > } > }; > > // [[Rcpp::export]] > NumericVector RcppParallelGridSearch(NumericMatrix grid, Function f) { > > // allocate the output matrix > NumericVector output(grid.nrow()); > > // SquareRoot functor (pass input and output matrixes) > GridSearch gridSearch(grid, f, output); > > // call parallelFor to do the work > parallelFor(0, grid.nrow(), gridSearch); > > // return the output matrix > return output; > } > > -- > Jeffrey Wong > My portfolio: http://jeffreycwong.com > > > _______________________________________________ > Rcpp-devel mailing list > Rcpp-devel at lists.r-forge.r-project.org > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel From Pierre.Gloaguen at ifremer.fr Mon Oct 6 23:36:38 2014 From: Pierre.Gloaguen at ifremer.fr (Pierre.Gloaguen at ifremer.fr) Date: Mon, 06 Oct 2014 23:36:38 +0200 Subject: [Rcpp-devel] R session crashes when largely using a Rcpp sourced function In-Reply-To: <20141004015701.1317100ree0hhbyl@vdmz1mail.ifremer.fr> References: <20141004015701.1317100ree0hhbyl@vdmz1mail.ifremer.fr> Message-ID: <20141006233638.344549nfud9jit7q@vdmz1mail.ifremer.fr> Hello, I have found out that the problem was in the R loop, the garbage collection of R wasn't perform efficiently. Indeed, when I force the garbage collection to be done, using R function gc(), the Rsession won't crash, although the execution of the loop will be slower. This leads me to another question. Is there anyway to force the garbage collection inside a Rcpp function? like this NumericVector myfunction(NumericVector x){ for(int= i = 0; i < x.size; ++i){ //do my stuff; gc(); } } Thanks for any help! Pierre Gloaguen pgloague at ifremer.fr a ?crit?: > Hello everyone, > > I am a new user of Rcpp, I use it to rewrite a whole R program. > at the end of the program, my "final function is the following" > > #include > #include > #define _USE_MATH_DEFINES > #include > using namespace Rcpp; > > // [[Rcpp::depends("RcppArmadillo")]] > > List main_function_C(arma::vec X0,arma::vec XF,double t0, > double tF, arma::mat Gamma, > NumericVector piks,arma::mat muks, List Cks, > int max_iter = 500){ > List bounds = bounds_fun_C(piks,Cks,Gamma); > double sup_bound = 0.5 *(as(bounds["alpha_bar"]) > + as(bounds["delta_max"]) > - as(bounds["delta_min"])); > bool accept = false; > int kappa = 0; > arma::mat omegas(2,2);//arbitrary size, will change in loop > NumericVector Psi(5);//arbitrary size, will change in loop > for(int i = 0; i < max_iter; ++i){ > kappa = rpois(1,(tF-t0)*sup_bound)[0]; > if(kappa > 0){ > Psi = stl_sort(runif(kappa,t0,tF)); > NumericVector Upsilon = runif(kappa, 0, sup_bound); > omegas = rubb_it_C(X0, XF, t0, tF, Psi); > NumericVector phi_omega(kappa); > for(int i = 1; i < kappa+2; i++){ > phi_omega[i-1] = phi_C(arma::trans(omegas.row(i)), > piks,muks,Cks,Gamma); > } > accept = all_C((phi_omega < Upsilon)); > }//end if kappa >0 > else{ > accept = true; > } > if(accept){ > break; > } > }//end for > arma::mat res(kappa+2,3);//result matrix, > if(kappa > 0){ > res.submat(0,0,kappa+1,1) = omegas; > res(0,2) = t0; > for(int i =1; i < kappa+1;++i){ > res(i,2) = Psi[i-1]; > //Psi is of size kappa the index then goes till kappa-1 > } > res(kappa+1,2) = tF; > } > else{ > res(0,arma::span(0,1)) = trans(X0); > res(1,arma::span(0,1)) = trans(XF); > res(0,2) = t0; > res(kappa+1,2) = tF; > } > return List::create(Named("skel") = res, > Named("accepted") = accept); > } > > This function calls other funtion that I have written, all of them > are attached on the cpp_funcs.cpp file. > The sourceCpp performs well and I can, from R obtain the following result > > sourceCpp("cpp_funcs.cpp") > X0 <- c(0.5,0.5) > XF <- c(1,1) > t0 <- 0 > tF <- 1 > Gam <- diag(0.1,2) > ncomp=2 > pis <- c(0.5,0.5) > mu <- matrix(c(-1,1, > 1,1),ncol=2,nrow=ncomp) > cov <- list(diag(0.5,2),diag(1,2)) > set.seed(123) > test <- main_function_C(X0,XF,t0,tF,Gam,pis,mu,cov) > test > #$skel > [,1] [,2] [,3] > #[1,] 0.5000000 0.500000 0.0000000 > #[2,] -0.1261731 1.313880 0.4089769 > #[3,] 0.5564577 1.069211 0.7883051 > #[4,] 1.0000000 1.000000 1.0000000 > > #$accepted > #[1] TRUE > > PROBLEM: > > When I run the exact same code as above a large number of times, as this > > for(i in 1:1000){ > ## same code as above > } > > The r session aborts all the time, giving no error message but "R > encountered a fatal error". > I do not encounter this problem with the intermediate functions in > the attached file (and, of course, I'm not asking for a debugging > of those), I only have it with this one > > Is this a problem with my code? with how the loop is written?The List object? > Is this a problem of the memory? > > It does it either on Rstudio or Rgui > I work on windows 7, with R version 3.0.2 > Rcpp 0.11.2 and RcppArmadillo 0.4.450.1.0 > > I also attach a R debugging file giving parameters for all > intermediate functions. > > Sorry for the length of the function, I'm pretty sure the problem > comes from the main function, but it sadly depends on others (which, > as far as I know, don't pose problems) > > Thanks in advance for any help, > > Pierre Gloaguen > From edd at debian.org Mon Oct 6 23:58:11 2014 From: edd at debian.org (Dirk Eddelbuettel) Date: Mon, 6 Oct 2014 16:58:11 -0500 Subject: [Rcpp-devel] Rcpp: Error: not compatible with requested type In-Reply-To: <54303E21.1020405@dms.umontreal.ca> References: <542EC8FE.7060407@dms.umontreal.ca> <21550.53396.616019.476282@max.nulle.part> <21550.54190.910917.608343@max.nulle.part> <542F20D9.3090302@dms.umontreal.ca> <21551.10713.176177.975093@max.nulle.part> <54303E21.1020405@dms.umontreal.ca> Message-ID: <21555.4211.41382.963250@max.nulle.part> On 4 October 2014 at 14:36, Pierre Lafaye de Micheaux wrote: | Thank you very much. That helped a lot. Our pleasure, and very nice to see that it already made it to CRAN! | Have a nice day. You too, cheers, Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org From edd at debian.org Tue Oct 7 00:10:22 2014 From: edd at debian.org (Dirk Eddelbuettel) Date: Mon, 6 Oct 2014 17:10:22 -0500 Subject: [Rcpp-devel] R session crashes when largely using a Rcpp sourced function In-Reply-To: <20141006233638.344549nfud9jit7q@vdmz1mail.ifremer.fr> References: <20141004015701.1317100ree0hhbyl@vdmz1mail.ifremer.fr> <20141006233638.344549nfud9jit7q@vdmz1mail.ifremer.fr> Message-ID: <21555.4942.183138.546361@max.nulle.part> On 6 October 2014 at 23:36, Pierre.Gloaguen at ifremer.fr wrote: | Hello, | | I have found out that the problem was in the R loop, the garbage | collection of R wasn't perform efficiently. Indeed, when I force the | garbage collection to be done, using R function gc(), the Rsession | won't crash, although the execution of the loop will be slower. | This leads me to another question. Is there anyway to force the | garbage collection inside a Rcpp function? Yes, the Rcpp::Function() class allows you to call R functions from C++. Part of me thinks, though, that once you are in C++ you may be able to just control your memory, not call back, compute your result and then report it back to R. But such an idealised situation may not work in your case -- and sorry that I did not have time to work through your code in any detail. Dirk | like this | NumericVector myfunction(NumericVector x){ | for(int= i = 0; i < x.size; ++i){ | //do my stuff; | gc(); | } | } | | Thanks for any help! | | Pierre Gloaguen | | pgloague at ifremer.fr a ?crit?: | | > Hello everyone, | > | > I am a new user of Rcpp, I use it to rewrite a whole R program. | > at the end of the program, my "final function is the following" | > | > #include | > #include | > #define _USE_MATH_DEFINES | > #include | > using namespace Rcpp; | > | > // [[Rcpp::depends("RcppArmadillo")]] | > | > List main_function_C(arma::vec X0,arma::vec XF,double t0, | > double tF, arma::mat Gamma, | > NumericVector piks,arma::mat muks, List Cks, | > int max_iter = 500){ | > List bounds = bounds_fun_C(piks,Cks,Gamma); | > double sup_bound = 0.5 *(as(bounds["alpha_bar"]) | > + as(bounds["delta_max"]) | > - as(bounds["delta_min"])); | > bool accept = false; | > int kappa = 0; | > arma::mat omegas(2,2);//arbitrary size, will change in loop | > NumericVector Psi(5);//arbitrary size, will change in loop | > for(int i = 0; i < max_iter; ++i){ | > kappa = rpois(1,(tF-t0)*sup_bound)[0]; | > if(kappa > 0){ | > Psi = stl_sort(runif(kappa,t0,tF)); | > NumericVector Upsilon = runif(kappa, 0, sup_bound); | > omegas = rubb_it_C(X0, XF, t0, tF, Psi); | > NumericVector phi_omega(kappa); | > for(int i = 1; i < kappa+2; i++){ | > phi_omega[i-1] = phi_C(arma::trans(omegas.row(i)), | > piks,muks,Cks,Gamma); | > } | > accept = all_C((phi_omega < Upsilon)); | > }//end if kappa >0 | > else{ | > accept = true; | > } | > if(accept){ | > break; | > } | > }//end for | > arma::mat res(kappa+2,3);//result matrix, | > if(kappa > 0){ | > res.submat(0,0,kappa+1,1) = omegas; | > res(0,2) = t0; | > for(int i =1; i < kappa+1;++i){ | > res(i,2) = Psi[i-1]; | > //Psi is of size kappa the index then goes till kappa-1 | > } | > res(kappa+1,2) = tF; | > } | > else{ | > res(0,arma::span(0,1)) = trans(X0); | > res(1,arma::span(0,1)) = trans(XF); | > res(0,2) = t0; | > res(kappa+1,2) = tF; | > } | > return List::create(Named("skel") = res, | > Named("accepted") = accept); | > } | > | > This function calls other funtion that I have written, all of them | > are attached on the cpp_funcs.cpp file. | > The sourceCpp performs well and I can, from R obtain the following result | > | > sourceCpp("cpp_funcs.cpp") | > X0 <- c(0.5,0.5) | > XF <- c(1,1) | > t0 <- 0 | > tF <- 1 | > Gam <- diag(0.1,2) | > ncomp=2 | > pis <- c(0.5,0.5) | > mu <- matrix(c(-1,1, | > 1,1),ncol=2,nrow=ncomp) | > cov <- list(diag(0.5,2),diag(1,2)) | > set.seed(123) | > test <- main_function_C(X0,XF,t0,tF,Gam,pis,mu,cov) | > test | > #$skel | > [,1] [,2] [,3] | > #[1,] 0.5000000 0.500000 0.0000000 | > #[2,] -0.1261731 1.313880 0.4089769 | > #[3,] 0.5564577 1.069211 0.7883051 | > #[4,] 1.0000000 1.000000 1.0000000 | > | > #$accepted | > #[1] TRUE | > | > PROBLEM: | > | > When I run the exact same code as above a large number of times, as this | > | > for(i in 1:1000){ | > ## same code as above | > } | > | > The r session aborts all the time, giving no error message but "R | > encountered a fatal error". | > I do not encounter this problem with the intermediate functions in | > the attached file (and, of course, I'm not asking for a debugging | > of those), I only have it with this one | > | > Is this a problem with my code? with how the loop is written?The List object? | > Is this a problem of the memory? | > | > It does it either on Rstudio or Rgui | > I work on windows 7, with R version 3.0.2 | > Rcpp 0.11.2 and RcppArmadillo 0.4.450.1.0 | > | > I also attach a R debugging file giving parameters for all | > intermediate functions. | > | > Sorry for the length of the function, I'm pretty sure the problem | > comes from the main function, but it sadly depends on others (which, | > as far as I know, don't pose problems) | > | > Thanks in advance for any help, | > | > Pierre Gloaguen | > | | | | _______________________________________________ | Rcpp-devel mailing list | Rcpp-devel at lists.r-forge.r-project.org | https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel -- http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org From Pierre.Gloaguen at ifremer.fr Tue Oct 7 00:31:06 2014 From: Pierre.Gloaguen at ifremer.fr (Pierre.Gloaguen at ifremer.fr) Date: Tue, 07 Oct 2014 00:31:06 +0200 Subject: [Rcpp-devel] R session crashes when largely using a Rcpp sourced function In-Reply-To: <21555.4942.183138.546361@max.nulle.part> References: <20141004015701.1317100ree0hhbyl@vdmz1mail.ifremer.fr> <20141006233638.344549nfud9jit7q@vdmz1mail.ifremer.fr> <21555.4942.183138.546361@max.nulle.part> Message-ID: <20141007003106.12955bk55jorvodm@vdmz1mail.ifremer.fr> Dirk Eddelbuettel a ?crit?: > > On 6 October 2014 at 23:36, Pierre.Gloaguen at ifremer.fr wrote: > | Hello, > | > | I have found out that the problem was in the R loop, the garbage > | collection of R wasn't perform efficiently. Indeed, when I force the > | garbage collection to be done, using R function gc(), the Rsession > | won't crash, although the execution of the loop will be slower. > | This leads me to another question. Is there anyway to force the > | garbage collection inside a Rcpp function? > > Yes, the Rcpp::Function() class allows you to call R functions from C++. > Ok, i will try this, thank you for the help! > Part of me thinks, though, that once you are in C++ you may be able to just > control your memory, not call back, compute your result and then report it > back to R. But such an idealised situation may not work in your case -- and > sorry that I did not have time to work through your code in any detail. No worries! I'm glad I found out by myself after all this times Have a nice day, Pierre > > Dirk > > > | like this > | NumericVector myfunction(NumericVector x){ > | for(int= i = 0; i < x.size; ++i){ > | //do my stuff; > | gc(); > | } > | } > | > | Thanks for any help! > | > | Pierre Gloaguen > | > | pgloague at ifremer.fr a ?crit?: > | > | > Hello everyone, > | > > | > I am a new user of Rcpp, I use it to rewrite a whole R program. > | > at the end of the program, my "final function is the following" > | > > | > #include > | > #include > | > #define _USE_MATH_DEFINES > | > #include > | > using namespace Rcpp; > | > > | > // [[Rcpp::depends("RcppArmadillo")]] > | > > | > List main_function_C(arma::vec X0,arma::vec XF,double t0, > | > double tF, arma::mat Gamma, > | > NumericVector piks,arma::mat muks, List Cks, > | > int max_iter = 500){ > | > List bounds = bounds_fun_C(piks,Cks,Gamma); > | > double sup_bound = 0.5 *(as(bounds["alpha_bar"]) > | > + as(bounds["delta_max"]) > | > - as(bounds["delta_min"])); > | > bool accept = false; > | > int kappa = 0; > | > arma::mat omegas(2,2);//arbitrary size, will change in loop > | > NumericVector Psi(5);//arbitrary size, will change in loop > | > for(int i = 0; i < max_iter; ++i){ > | > kappa = rpois(1,(tF-t0)*sup_bound)[0]; > | > if(kappa > 0){ > | > Psi = stl_sort(runif(kappa,t0,tF)); > | > NumericVector Upsilon = runif(kappa, 0, sup_bound); > | > omegas = rubb_it_C(X0, XF, t0, tF, Psi); > | > NumericVector phi_omega(kappa); > | > for(int i = 1; i < kappa+2; i++){ > | > phi_omega[i-1] = phi_C(arma::trans(omegas.row(i)), > | > piks,muks,Cks,Gamma); > | > } > | > accept = all_C((phi_omega < Upsilon)); > | > }//end if kappa >0 > | > else{ > | > accept = true; > | > } > | > if(accept){ > | > break; > | > } > | > }//end for > | > arma::mat res(kappa+2,3);//result matrix, > | > if(kappa > 0){ > | > res.submat(0,0,kappa+1,1) = omegas; > | > res(0,2) = t0; > | > for(int i =1; i < kappa+1;++i){ > | > res(i,2) = Psi[i-1]; > | > //Psi is of size kappa the index then goes till kappa-1 > | > } > | > res(kappa+1,2) = tF; > | > } > | > else{ > | > res(0,arma::span(0,1)) = trans(X0); > | > res(1,arma::span(0,1)) = trans(XF); > | > res(0,2) = t0; > | > res(kappa+1,2) = tF; > | > } > | > return List::create(Named("skel") = res, > | > Named("accepted") = accept); > | > } > | > > | > This function calls other funtion that I have written, all of them > | > are attached on the cpp_funcs.cpp file. > | > The sourceCpp performs well and I can, from R obtain the following result > | > > | > sourceCpp("cpp_funcs.cpp") > | > X0 <- c(0.5,0.5) > | > XF <- c(1,1) > | > t0 <- 0 > | > tF <- 1 > | > Gam <- diag(0.1,2) > | > ncomp=2 > | > pis <- c(0.5,0.5) > | > mu <- matrix(c(-1,1, > | > 1,1),ncol=2,nrow=ncomp) > | > cov <- list(diag(0.5,2),diag(1,2)) > | > set.seed(123) > | > test <- main_function_C(X0,XF,t0,tF,Gam,pis,mu,cov) > | > test > | > #$skel > | > [,1] [,2] [,3] > | > #[1,] 0.5000000 0.500000 0.0000000 > | > #[2,] -0.1261731 1.313880 0.4089769 > | > #[3,] 0.5564577 1.069211 0.7883051 > | > #[4,] 1.0000000 1.000000 1.0000000 > | > > | > #$accepted > | > #[1] TRUE > | > > | > PROBLEM: > | > > | > When I run the exact same code as above a large number of times, as this > | > > | > for(i in 1:1000){ > | > ## same code as above > | > } > | > > | > The r session aborts all the time, giving no error message but "R > | > encountered a fatal error". > | > I do not encounter this problem with the intermediate functions in > | > the attached file (and, of course, I'm not asking for a debugging > | > of those), I only have it with this one > | > > | > Is this a problem with my code? with how the loop is written?The > List object? > | > Is this a problem of the memory? > | > > | > It does it either on Rstudio or Rgui > | > I work on windows 7, with R version 3.0.2 > | > Rcpp 0.11.2 and RcppArmadillo 0.4.450.1.0 > | > > | > I also attach a R debugging file giving parameters for all > | > intermediate functions. > | > > | > Sorry for the length of the function, I'm pretty sure the problem > | > comes from the main function, but it sadly depends on others (which, > | > as far as I know, don't pose problems) > | > > | > Thanks in advance for any help, > | > > | > Pierre Gloaguen > | > > | > | > | > | _______________________________________________ > | Rcpp-devel mailing list > | Rcpp-devel at lists.r-forge.r-project.org > | https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel > > -- > http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org > From Pierre.Gloaguen at ifremer.fr Wed Oct 8 01:20:01 2014 From: Pierre.Gloaguen at ifremer.fr (Pierre.Gloaguen at ifremer.fr) Date: Wed, 08 Oct 2014 01:20:01 +0200 Subject: [Rcpp-devel] R session crashes when largely using a Rcpp sourced function In-Reply-To: <20141007003106.12955bk55jorvodm@vdmz1mail.ifremer.fr> References: <20141004015701.1317100ree0hhbyl@vdmz1mail.ifremer.fr> <20141006233638.344549nfud9jit7q@vdmz1mail.ifremer.fr> <21555.4942.183138.546361@max.nulle.part> <20141007003106.12955bk55jorvodm@vdmz1mail.ifremer.fr> Message-ID: <20141008012001.17881f6rhr4xh1y9@vdmz1mail.ifremer.fr> Hello Dirk, and everyone, I sadly was too optimistic thinking that a gc() would solve the problem. The main_function_C I wrote was putted in a more general function named simu_cond_ea_C List simu_cond_ea_C(arma::vec X0,arma::vec XF, double t0, double tF, NumericVector times, arma::mat Gamma, NumericVector piks, arma::mat muks,List Cks, int max_iter = 500, bool do_Lamp=true){ arma::vec X0_tmp = X0; arma::vec XF_tmp = XF; if(do_Lamp){ arma::mat Gi = arma::inv(Gamma); X0_tmp = Gi*X0_tmp; XF_tmp = Gi*XF_tmp; } List tmp = main_function_C(X0,XF,t0,tF,Gamma,piks,muks,Cks,max_iter); arma::mat skeleton = tmp["skel"]; bool accept = as(tmp["accepted"]); arma::vec tmp_vec = skeleton.col(2); NumericVector skel_times(tmp_vec.begin(),tmp_vec.end()); IntegerVector segmentation = findInterval_C(times,skel_times); arma::mat res(skeleton); IntegerVector idx_seg= unique(segmentation); IntegerVector::iterator end_loop = idx_seg.end(); for(IntegerVector::iterator it=idx_seg.begin();it!=end_loop;++it){ NumericVector times_tmp = times[segmentation==*it]; arma::mat tmp_bb = rubb_it_C(arma::trans(skeleton(*it-1,arma::span(0,1))), arma::trans(skeleton(*it,arma::span(0,1))), skel_times[*it-1], skel_times[*it], times_tmp); int n_tmp = times_tmp.size(); arma::mat tmp_res(n_tmp,3); tmp_res.col(2) = as(times_tmp); tmp_res.submat(0,0,n_tmp-1,1) = tmp_bb.submat(1,0,n_tmp,1); res = rbind_C(res,tmp_res); } arma::mat out(res); arma::uvec indx_time = sort_index(res.col(2)); int nobs = res.n_rows; for(int i=0;i < nobs;++i){ out.row(i) = res.row(indx_time[i]); } return List::create(Named("skel") = out, Named("accepted") = accept); } (again all the functions needed for its compilation are attached). The loop for(i in 1:10000){ test <- simu_cond_ea_C(myparameters) gc() } seems to work, but it somehow leads to an instable R session. And, moreover, when I embed it in my Rprogram in a function (where there is a loop also): simu_mc_xus_R <- function(X,theta0,Gamma,N,do_Lamp=F){ t0.glob <- X[1,3] tF.glob <- X[nrow(X),3] us <- stl_sort(runif(N,t0.glob,tF.glob)) which.seg <- findInterval_C(us,X[,3]) xus_tmp <- matrix(nrow=N,ncol=3) xus_tmp[,3] <- us for(i in 1:N){ X0 <- X[which.seg[i],1:2] XF <- X[which.seg[i]+1,1:2] t0 <- X[which.seg[i],3] tF <- X[which.seg[i]+1,3] tmp <- simu_cond_ea_C(X0,XF,t0=t0,tF=tF,times=us[i], Gamma=Gamma, Cks=theta0$Cks, muks=theta0$muks, piks=theta0$piks,do_Lamp=do_Lamp)$skel xus_tmp[i,1:2] <- tmp[tmp[,3]==us[i],1:2] gc() } xus_tmp } then I encounter a problem for a big N (10000 for instance), it either 1) crash the R session with no message but "r encountered a fatal error" 2) or print this message Error in gc() : GC encountered a node (0x000000000ce11a10) with an unknown SEXP type: at memory.c:1636 I don't have much experience in dealing with memory, so I don't know where the problem could come from. My cpp code? R intern memory problem? It's worth noting the object that I stock are not big, I wrote this program before in R, it was slower but it never failed for memory reasons. I run on R 3.1.1, platform x86_64-w64-mingw32/x64 (64-bit) I work on windows 7. I attach the cpp_functions, the R_programm that embeds the last function, and a R file debug_test wich gives R code to test the functions and lead to my problems. Any clue about the origin of this problem would be welcomed! Pierre Gloaguen Pierre.Gloaguen at ifremer.fr a ?crit?: > Dirk Eddelbuettel a ?crit?: > >> >> On 6 October 2014 at 23:36, Pierre.Gloaguen at ifremer.fr wrote: >> | Hello, >> | >> | I have found out that the problem was in the R loop, the garbage >> | collection of R wasn't perform efficiently. Indeed, when I force the >> | garbage collection to be done, using R function gc(), the Rsession >> | won't crash, although the execution of the loop will be slower. >> | This leads me to another question. Is there anyway to force the >> | garbage collection inside a Rcpp function? >> >> Yes, the Rcpp::Function() class allows you to call R functions from C++. >> > Ok, i will try this, thank you for the help! >> Part of me thinks, though, that once you are in C++ you may be able to just >> control your memory, not call back, compute your result and then report it >> back to R. But such an idealised situation may not work in your case -- and >> sorry that I did not have time to work through your code in any detail. > > No worries! I'm glad I found out by myself after all this times > Have a nice day, > > Pierre >> >> Dirk >> >> >> | like this >> | NumericVector myfunction(NumericVector x){ >> | for(int= i = 0; i < x.size; ++i){ >> | //do my stuff; >> | gc(); >> | } >> | } >> | >> | Thanks for any help! >> | >> | Pierre Gloaguen >> | >> | pgloague at ifremer.fr a ?crit?: >> | >> | > Hello everyone, >> | > >> | > I am a new user of Rcpp, I use it to rewrite a whole R program. >> | > at the end of the program, my "final function is the following" >> | > >> | > #include >> | > #include >> | > #define _USE_MATH_DEFINES >> | > #include >> | > using namespace Rcpp; >> | > >> | > // [[Rcpp::depends("RcppArmadillo")]] >> | > >> | > List main_function_C(arma::vec X0,arma::vec XF,double t0, >> | > double tF, arma::mat Gamma, >> | > NumericVector piks,arma::mat muks, List Cks, >> | > int max_iter = 500){ >> | > List bounds = bounds_fun_C(piks,Cks,Gamma); >> | > double sup_bound = 0.5 *(as(bounds["alpha_bar"]) >> | > + as(bounds["delta_max"]) >> | > - as(bounds["delta_min"])); >> | > bool accept = false; >> | > int kappa = 0; >> | > arma::mat omegas(2,2);//arbitrary size, will change in loop >> | > NumericVector Psi(5);//arbitrary size, will change in loop >> | > for(int i = 0; i < max_iter; ++i){ >> | > kappa = rpois(1,(tF-t0)*sup_bound)[0]; >> | > if(kappa > 0){ >> | > Psi = stl_sort(runif(kappa,t0,tF)); >> | > NumericVector Upsilon = runif(kappa, 0, sup_bound); >> | > omegas = rubb_it_C(X0, XF, t0, tF, Psi); >> | > NumericVector phi_omega(kappa); >> | > for(int i = 1; i < kappa+2; i++){ >> | > phi_omega[i-1] = phi_C(arma::trans(omegas.row(i)), >> | > piks,muks,Cks,Gamma); >> | > } >> | > accept = all_C((phi_omega < Upsilon)); >> | > }//end if kappa >0 >> | > else{ >> | > accept = true; >> | > } >> | > if(accept){ >> | > break; >> | > } >> | > }//end for >> | > arma::mat res(kappa+2,3);//result matrix, >> | > if(kappa > 0){ >> | > res.submat(0,0,kappa+1,1) = omegas; >> | > res(0,2) = t0; >> | > for(int i =1; i < kappa+1;++i){ >> | > res(i,2) = Psi[i-1]; >> | > //Psi is of size kappa the index then goes till kappa-1 >> | > } >> | > res(kappa+1,2) = tF; >> | > } >> | > else{ >> | > res(0,arma::span(0,1)) = trans(X0); >> | > res(1,arma::span(0,1)) = trans(XF); >> | > res(0,2) = t0; >> | > res(kappa+1,2) = tF; >> | > } >> | > return List::create(Named("skel") = res, >> | > Named("accepted") = accept); >> | > } >> | > >> | > This function calls other funtion that I have written, all of them >> | > are attached on the cpp_funcs.cpp file. >> | > The sourceCpp performs well and I can, from R obtain the >> following result >> | > >> | > sourceCpp("cpp_funcs.cpp") >> | > X0 <- c(0.5,0.5) >> | > XF <- c(1,1) >> | > t0 <- 0 >> | > tF <- 1 >> | > Gam <- diag(0.1,2) >> | > ncomp=2 >> | > pis <- c(0.5,0.5) >> | > mu <- matrix(c(-1,1, >> | > 1,1),ncol=2,nrow=ncomp) >> | > cov <- list(diag(0.5,2),diag(1,2)) >> | > set.seed(123) >> | > test <- main_function_C(X0,XF,t0,tF,Gam,pis,mu,cov) >> | > test >> | > #$skel >> | > [,1] [,2] [,3] >> | > #[1,] 0.5000000 0.500000 0.0000000 >> | > #[2,] -0.1261731 1.313880 0.4089769 >> | > #[3,] 0.5564577 1.069211 0.7883051 >> | > #[4,] 1.0000000 1.000000 1.0000000 >> | > >> | > #$accepted >> | > #[1] TRUE >> | > >> | > PROBLEM: >> | > >> | > When I run the exact same code as above a large number of times, as this >> | > >> | > for(i in 1:1000){ >> | > ## same code as above >> | > } >> | > >> | > The r session aborts all the time, giving no error message but "R >> | > encountered a fatal error". >> | > I do not encounter this problem with the intermediate functions in >> | > the attached file (and, of course, I'm not asking for a debugging >> | > of those), I only have it with this one >> | > >> | > Is this a problem with my code? with how the loop is >> written?The List object? >> | > Is this a problem of the memory? >> | > >> | > It does it either on Rstudio or Rgui >> | > I work on windows 7, with R version 3.0.2 >> | > Rcpp 0.11.2 and RcppArmadillo 0.4.450.1.0 >> | > >> | > I also attach a R debugging file giving parameters for all >> | > intermediate functions. >> | > >> | > Sorry for the length of the function, I'm pretty sure the problem >> | > comes from the main function, but it sadly depends on others (which, >> | > as far as I know, don't pose problems) >> | > >> | > Thanks in advance for any help, >> | > >> | > Pierre Gloaguen >> | > >> | >> | >> | >> | _______________________________________________ >> | Rcpp-devel mailing list >> | Rcpp-devel at lists.r-forge.r-project.org >> | https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel >> >> -- >> http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org >> > > > > -------------- next part -------------- #include #include #define _USE_MATH_DEFINES #include using namespace Rcpp; // [[Rcpp::depends("RcppArmadillo")]] // [[Rcpp::export]] bool all_C(LogicalVector x){// Equivalent to all function in R LogicalVector::iterator n = x.end(); for(LogicalVector::iterator i = x.begin(); i != n; ++i){ if(!*i) return false; } return true; } // [[Rcpp::export]] arma::mat rbind_C(arma::mat x, arma::mat y){// rbind two matrices int nx = x.n_rows; int ny = y.n_rows; int ncol = x.n_cols; arma::mat out(nx+ny,ncol); out.submat(0,0,nx-1,ncol-1)=x; out.submat(nx,0,nx+ny-1,ncol-1)=y; return out; } // [[Rcpp::export]] double trace_C(arma::mat x){// Computing the trace of a squared matrix int n = x.n_rows; double out=0.0; for(int i=0;i < n;++i){ out += x(i,i); } return out; } // [[Rcpp::export]] IntegerVector findInterval_C(NumericVector x, NumericVector breaks) {// equivalent of findIntervalfunction IntegerVector out(x.size()); NumericVector::iterator it, pos; IntegerVector::iterator out_it; for(it = x.begin(), out_it = out.begin(); it != x.end(); ++it, ++out_it) { pos = std::upper_bound(breaks.begin(), breaks.end(), *it); *out_it = std::distance(breaks.begin(), pos); } return out; } // [[Rcpp::export]] arma::vec Mahalanobis(arma::mat x, arma::rowvec center, arma::mat cov){ int n = x.n_rows; arma::mat x_cen; x_cen.copy_size(x); for (int i=0; i < n; ++i) { x_cen.row(i) = x.row(i) - center; } return sum((x_cen * cov.i())%x_cen, 1); } // [[Rcpp::export]] arma::vec dmvnorm_C (arma::mat x,arma::rowvec mean, arma::mat sigma, bool log){ arma::vec distval = Mahalanobis(x, mean, sigma); double logdet = sum(arma::log(arma::eig_sym(sigma))); double log2pi = 1.8378770664093454835606594728112352797227949472755668; arma::vec logretval = -( (x.n_cols * log2pi + logdet + distval)/2 ) ; if(log){ return logretval; } else { return exp(logretval);} } // [[Rcpp::export]] NumericVector stl_sort(NumericVector x) {//function to sort a Numeric vector NumericVector y = clone(x); std::sort(y.begin(), y.end()); return y; } // [[Rcpp::export]] List bounds_fun_C(NumericVector piks, List Cks, arma::mat Gamma){//intermediate function IntegerVector is = (seq_along(piks)-1); IntegerVector::iterator ncomp_it = is.end(); int ncomp = Cks.size(); NumericVector dets(ncomp); NumericVector norms_Cinv(ncomp); NumericVector traces(ncomp); NumericVector maxeigen(ncomp); NumericVector norms_GiCinv(ncomp); arma::mat Gi = arma::inv(Gamma); for(IntegerVector::iterator i=is.begin(); i!=ncomp_it;++i){ arma::mat Ck = Cks[*i]; arma::mat Cki = arma::inv(Ck); dets[*i] = arma::det(2*M_PI*Ck); norms_Cinv[*i] = arma::norm(Cki,2); maxeigen[*i] = arma::norm(Ck,2); traces[*i] = trace_C(Cki); norms_GiCinv[*i] = arma::norm(Gi*Cki,2); } double delta_min = -sum(piks * pow(dets,-0.5) * traces); double delta_max = 2*exp(-1)*sum(piks * pow(norms_Cinv,2) * pow(dets,-0.5) * maxeigen); double alpha_bar = exp(-1)*sum(piks * pow(norms_GiCinv,2) * maxeigen/dets); return List::create(Named("delta_min") = delta_min, Named("delta_max") = delta_max, Named("alpha_bar") = alpha_bar); } // [[Rcpp::export]] double phi_C(arma::vec X, NumericVector piks,arma::mat muks, List Cks, arma::mat Gamma){//intermediate function int ncomp = piks.size(); List tmp=bounds_fun_C(piks,Cks,Gamma); double delta_min = as(tmp["delta_min"]); arma::vec GX = Gamma*X; arma::mat Xtmp(1,2);//to go in dmvnorm function Xtmp(0,0) = GX[0]; Xtmp(0,1) = GX[1]; arma::vec pi_gaus_dens(ncomp); arma::vec traces(ncomp); arma::vec norms_C_Ix(ncomp); arma::mat Gi = arma::inv(Gamma); arma::vec alpha(2); alpha.fill(0); double lapl_H = 0.0; for(int i = 0; i < ncomp;++i){ arma::rowvec mu = muks.row(i); arma::mat Ck = Cks[i]; arma::mat Cki = arma::inv(Ck); pi_gaus_dens[i] = piks[i]*dmvnorm_C(Xtmp,mu,Ck,false)[0]; traces[i] = trace_C(Cki); norms_C_Ix[i] = pow(arma::norm(Cki*(GX-arma::trans(mu)),2),2); lapl_H += pi_gaus_dens[i]*(norms_C_Ix[i]-traces[i]); alpha += pi_gaus_dens[i]*Gi*Cki*(GX-arma::trans(mu)); } double norm_alpha = pow(arma::norm(alpha,2),2); double res = 0.5*(norm_alpha+lapl_H-delta_min); return res; } arma::mat rubb_it_C(arma::vec X0,arma::vec XF,//Simulating a brownian bridge double t0, double tF,NumericVector times) { double XF1 = XF[0]; double XF2 = XF[1]; int n = times.size(); arma::vec X1(n+2); arma::vec X2(n+2); NumericVector ts(n+1);//times series for the loop ts[0] = t0; X1[0] = X0[0]; X2[0] = X0[1]; X1[n+1] = XF1; X2[n+1] = XF2; for(int i=1; i < (n+1); ++i){ ts[i] = times[i-1]; double tar = tF-ts[i];//time before the arrival double tdeb = ts[i]-ts[i-1];//time since the departure double ttot = tF-ts[i-1];//overall time X1[i] = (tar*X1[i-1]+tdeb*XF1)/ttot + rnorm(1,0,pow((tar*tdeb)/ttot,0.5))[0]; X2[i] = (tar*X2[i-1]+tdeb*XF2)/ttot + rnorm(1,0,pow((tar*tdeb)/ttot,0.5))[0]; } arma::mat res(n+2,2); res.col(0) = X1; res.col(1) = X2; return res; } // [[Rcpp::export]] List main_function_C(arma::vec X0,arma::vec XF,double t0, double tF, arma::mat Gamma, NumericVector piks,arma::mat muks, List Cks, int max_iter = 500){ List bounds = bounds_fun_C(piks,Cks,Gamma); double sup_bound = 0.5 *(as(bounds["alpha_bar"]) + as(bounds["delta_max"]) - as(bounds["delta_min"])); bool accept = false; int kappa = 0; arma::mat omegas(2,2);//arbitrary size, will change in loop NumericVector Psi(5);//arbitrary size, will change in loop for(int i = 0; i < max_iter; ++i){ kappa = rpois(1,(tF-t0)*sup_bound)[0]; if(kappa > 0){ Psi = stl_sort(runif(kappa,t0,tF)); NumericVector Upsilon = runif(kappa, 0, sup_bound); omegas = rubb_it_C(X0, XF, t0, tF, Psi); NumericVector phi_omega(kappa); for(int i = 1; i < kappa+2; i++){ phi_omega[i-1] = phi_C(arma::trans(omegas.row(i)), piks,muks,Cks,Gamma); } accept = all_C((phi_omega < Upsilon)); } else{ accept = true; } if(accept){ break; } } arma::mat res(kappa+2,3);//result matrix, if(kappa > 0){ res.submat(0,0,kappa+1,1) = omegas; res(0,2) = t0; for(int i =1; i < kappa+1;++i){ res(i,2) = Psi[i-1]; //Psi is of size kappa the index then goes till kappa-1 } res(kappa+1,2) = tF; } else{ res(0,arma::span(0,1)) = trans(X0); res(1,arma::span(0,1)) = trans(XF); res(0,2) = t0; res(kappa+1,2) = tF; } return List::create(Named("skel") = res, Named("accepted") = accept); } // [[Rcpp::export]] List simu_cond_ea_C(arma::vec X0,arma::vec XF, double t0, double tF, NumericVector times, arma::mat Gamma, NumericVector piks, arma::mat muks,List Cks, int max_iter = 500, bool do_Lamp=true){ arma::vec X0_tmp = X0; arma::vec XF_tmp = XF; if(do_Lamp){ arma::mat Gi = arma::inv(Gamma); X0_tmp = Gi*X0_tmp; XF_tmp = Gi*XF_tmp; } List tmp = main_function_C(X0,XF,t0,tF,Gamma,piks,muks,Cks,max_iter); arma::mat skeleton = tmp["skel"]; bool accept = as(tmp["accepted"]); arma::vec tmp_vec = skeleton.col(2); NumericVector skel_times(tmp_vec.begin(),tmp_vec.end()); IntegerVector segmentation = findInterval_C(times,skel_times); arma::mat res(skeleton); IntegerVector idx_seg= unique(segmentation); IntegerVector::iterator end_loop = idx_seg.end(); for(IntegerVector::iterator it=idx_seg.begin();it!=end_loop;++it){ NumericVector times_tmp = times[segmentation==*it]; arma::mat tmp_bb = rubb_it_C(arma::trans(skeleton(*it-1,arma::span(0,1))), arma::trans(skeleton(*it,arma::span(0,1))), skel_times[*it-1], skel_times[*it], times_tmp); int n_tmp = times_tmp.size(); arma::mat tmp_res(n_tmp,3); tmp_res.col(2) = as(times_tmp); tmp_res.submat(0,0,n_tmp-1,1) = tmp_bb.submat(1,0,n_tmp,1); res = rbind_C(res,tmp_res); } arma::mat out(res); arma::uvec indx_time = sort_index(res.col(2)); int nobs = res.n_rows; for(int i=0;i < nobs;++i){ out.row(i) = res.row(indx_time[i]); } return List::create(Named("skel") = out, Named("accepted") = accept); } //// [[Rcpp::export]] //arma::mat simu_mc_xusC(arma::mat X, List theta0,arma::mat Gamma, // int Nsamp, bool do_Lamp=false){ // int nobs = X.n_rows; // double t0_glob = X(0,2); // double tF_glob = X(nobs-1,2); // NumericVector piks = theta0["piks"]; // arma::mat muks = theta0["muks"]; // List Cks = theta0["Cks"]; // NumericVector us = stl_sort(runif(Nsamp,t0_glob,tF_glob)); // arma::vec tmp = X.col(2); // NumericVector times_obs(tmp.begin(),tmp.end()); // IntegerVector which_seg = findInterval_C(us,times_obs); // arma::mat res(Nsamp,3); // arma::mat Xtrans = arma::trans(X); // for(int i = 0; i < Nsamp; ++i){ // arma::vec X0 = Xtrans(arma::span(0,1),which_seg[i]-1).col(0); // arma::vec XF = Xtrans(arma::span(0,1),which_seg[i]).col(0); // double t0 = X(which_seg[i]-1,2); // double tF = X(which_seg[i],2); // NumericVector times_tp(1); // times_tp.fill(us[i]); // List simu = main_function_C(X0,XF,t0,tF, times_tp, // Gamma, piks, muks, Cks, // 500, do_Lamp); // bool accept = simu["accepted"]; // arma::mat res_tmp = simu["skel"]; // if(!accept){ // std::cout << "Conditionnal simu failed for point" < nrow, noprob x <- matrix(sample(20),nrow=5,ncol=4) test <- traceC(x) #Normal error message, so that would no be this #SEEMS OK # test stl_sort ------------------------------------------------------------ #adding stl_sort sourceCpp("cpp_funcs.cpp") for(i in 1:1000){ x <- runif(1000) test <- stl_sort(x) } #seems OK # test Mahalanobis ------------------------------------------------------------ #adding Mahalanobis sourceCpp("cpp_funcs.cpp") for(i in 1:1000){ x <- matrix(rnorm(100),ncol=2,nrow=50) y <- rnorm(2) cov <- rWishart(1,2,diag(1,2))[,,1] test <- Mahalanobis(x,y,cov) } #SEEMS OK # test dmvnorm_C ------------------------------------------------------------ #This function depends on Mahalanobis #adding dmvnorm_C sourceCpp("cpp_funcs.cpp") for(i in 1:1000){ x <- matrix(rnorm(100),ncol=2,nrow=50) y <- rnorm(2) cov <- rWishart(1,2,diag(1,2))[,,1] test <- dmvnorm_C(x,y,cov,log=FALSE) } #SEEMS OK # test bounds_fun_C ------------------------------------------------------------ #This function depends on trace_C #adding bounds_fun_C sourceCpp("cpp_funcs.cpp") for(i in 1:10000){ ncomp<- sample(1:5,size=1) pis <- rdirichlet(1,rep(1,ncomp))[1,] tmp <- rWishart(ncomp,2,diag(1,2)) cov <- lapply(1:ncomp,function(i) tmp[,,i]) Gam <- rWishart(ncomp,2,diag(1,2))[,,1] test <- bounds_fun_C(pis,cov,Gam) } #SEEMS OK # test phi_C ------------------------------------------------------------ #This function depends on trace_C, dmvnorm_C and bounds_fun_C #adding bounds_fun_C sourceCpp("cpp_funcs.cpp") for(i in 1:1000){ ncomp<- sample(1:5,size=1) x <- rnorm(2) pis <- rdirichlet(1,rep(1,ncomp))[1,] tmp <- rWishart(ncomp,2,diag(1,2)) mu <- matrix(rnorm(2*ncomp),ncol=2,nrow=ncomp) cov <- lapply(1:ncomp,function(i) tmp[,,i]) Gam <- rWishart(ncomp,2,diag(1,2))[,,1] test <- phi_C(x,pis,mu,cov,Gam) } #SEEMS OK BUT there was an unexplained abort at some point # test rubb_it_C ------------------------------------------------------------ #uses bounds_fun_C, stl_sort,phi_C,all_C #adding rubb_it_C sourceCpp("cpp_funcs.cpp") for(i in 1:10000){ ntime <- sample(1000,size=1) t0= 0 tF = 1 tmp_times <- sort(runif(ntime,t0,tF)) X0 <- rnorm(2) XF <- rnorm(2) test <- rubb_it_C(X0,XF,t0,tF,tmp_times) } #SEEMS OK # test simu_ea_seg_C ------------------------------------------------------------ #uses bounds_fun_C, stl_sort,phi_C,all_C,rubb_it_C #adding simu_ea_segC sourceCpp("cpp_funcs.cpp") X0 <- c(0.5,0.5) XF <- c(1,1) t0 <- 0 tF <- 1 Gam <- diag(0.1,2) ncomp=2 pis <- c(0.5,0.5) mu <- matrix(c(-1,1, 1,1),ncol=2,nrow=ncomp) cov <- list(diag(0.5,2),diag(1,2)) for(i in 1:1000){ set.seed(123) test <- main_function_C(X0,XF,t0,tF,Gam,pis,mu,cov) gc() } # test simu_cond_ea ------------------------------------------------------------ #uses bounds_fun_C, stl_sort,phi_C,all_C,rubb_it_C #adding simu_cond_ea sourceCpp("cpp_funcs.cpp") X0 <- c(0.5,0.5) XF <- c(1,1) t0 <- 0 tF <- 1 tim <- seq(t0+0.1,tF-0.1,0.1) Gam <- diag(0.1,2) ncomp=2 pis <- c(0.5,0.5) mu <- matrix(c(-1,1, 1,1),ncol=2,nrow=ncomp) cov <- list(diag(0.5,2),diag(1,2)) for(i in 1:10000){ test <- simu_cond_ea_C(X0,XF,t0,tF,tim,Gam,pis,mu,cov) gc() print(i) } # test simu_mc_xus.R ------------------------------------------------------ sourceCpp("cpp_funcs.cpp") source("R_function_embedding_rcpp.R") ncomp=2 X <- cbind(rnorm(10),rnorm(10),seq(0,1,length.out=10)) pis <- c(0.5,0.5) mu <- matrix(c(-1,1, 1,1),ncol=2,nrow=ncomp) cov <- list(diag(0.5,2),diag(1,2)) theta0 <- list(piks=pis,muks=mu,Cks=cov) Gam <- diag(0.1,2) N <- 10000 test <- simu_mc_xus_R(X,theta0,Gam,N,FALSE) shine(test) -------------- next part -------------- simu_mc_xus_R <- function(X,theta0,Gamma,N,do_Lamp=F){ t0.glob <- X[1,3] tF.glob <- X[nrow(X),3] us <- stl_sort(runif(N,t0.glob,tF.glob)) which.seg <- findInterval_C(us,X[,3]) xus_tmp <- matrix(nrow=N,ncol=3) xus_tmp[,3] <- us for(i in 1:N){ X0 <- X[which.seg[i],1:2] XF <- X[which.seg[i]+1,1:2] t0 <- X[which.seg[i],3] tF <- X[which.seg[i]+1,3] tmp <- simu_cond_ea_C(X0,XF,t0=t0,tF=tF,times=us[i], Gamma=Gamma, Cks=theta0$Cks, muks=theta0$muks, piks=theta0$piks,do_Lamp=do_Lamp)$skel xus_tmp[i,1:2] <- tmp[tmp[,3]==us[i],1:2] gc() } xus_tmp } From edd at debian.org Wed Oct 8 01:46:10 2014 From: edd at debian.org (Dirk Eddelbuettel) Date: Tue, 7 Oct 2014 18:46:10 -0500 Subject: [Rcpp-devel] R session crashes when largely using a Rcpp sourced function In-Reply-To: <20141008012001.17881f6rhr4xh1y9@vdmz1mail.ifremer.fr> References: <20141004015701.1317100ree0hhbyl@vdmz1mail.ifremer.fr> <20141006233638.344549nfud9jit7q@vdmz1mail.ifremer.fr> <21555.4942.183138.546361@max.nulle.part> <20141007003106.12955bk55jorvodm@vdmz1mail.ifremer.fr> <20141008012001.17881f6rhr4xh1y9@vdmz1mail.ifremer.fr> Message-ID: <21556.31554.202302.21490@max.nulle.part> On 8 October 2014 at 01:20, Pierre.Gloaguen at ifremer.fr wrote: | Hello Dirk, and everyone, | | I sadly was too optimistic thinking that a gc() would solve the problem. | The main_function_C I wrote was putted in a more general function | named simu_cond_ea_C [...] | Any clue about the origin of this problem would be welcomed! Try to reduce the example from ~ 2 screens full of code to just one screen full -- and preferably just a handful of lines, and ideally self-contained, which still exhibit the issue. You cannot really expect us to be an on-call debug service for you. Sorry, Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org From Pierre.Gloaguen at ifremer.fr Wed Oct 8 01:59:40 2014 From: Pierre.Gloaguen at ifremer.fr (Pierre.Gloaguen at ifremer.fr) Date: Wed, 08 Oct 2014 01:59:40 +0200 Subject: [Rcpp-devel] R session crashes when largely using a Rcpp sourced function In-Reply-To: <21556.31554.202302.21490@max.nulle.part> References: <20141004015701.1317100ree0hhbyl@vdmz1mail.ifremer.fr> <20141006233638.344549nfud9jit7q@vdmz1mail.ifremer.fr> <21555.4942.183138.546361@max.nulle.part> <20141007003106.12955bk55jorvodm@vdmz1mail.ifremer.fr> <20141008012001.17881f6rhr4xh1y9@vdmz1mail.ifremer.fr> <21556.31554.202302.21490@max.nulle.part> Message-ID: <20141008015940.149442hq00h8pzzg@vdmz1mail.ifremer.fr> Hello Dirk, I will do what I can to reduce the code and have to same error occuring. Of course i don't expect you to read all of it :) I was just wondering if that kind of memory problem occured before, and if has some "typical/generic" solutions. I will try to have a shortest code to exhibit. Thank you, Pierre Dirk Eddelbuettel a ?crit?: > > On 8 October 2014 at 01:20, Pierre.Gloaguen at ifremer.fr wrote: > | Hello Dirk, and everyone, > | > | I sadly was too optimistic thinking that a gc() would solve the problem. > | The main_function_C I wrote was putted in a more general function > | named simu_cond_ea_C > [...] > | Any clue about the origin of this problem would be welcomed! > > Try to reduce the example from ~ 2 screens full of code to just one screen > full -- and preferably just a handful of lines, and ideally self-contained, > which still exhibit the issue. > > You cannot really expect us to be an on-call debug service for you. > > Sorry, Dirk > > -- > http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org > From edd at debian.org Wed Oct 8 02:17:10 2014 From: edd at debian.org (Dirk Eddelbuettel) Date: Tue, 7 Oct 2014 19:17:10 -0500 Subject: [Rcpp-devel] R session crashes when largely using a Rcpp sourced function In-Reply-To: <20141008015940.149442hq00h8pzzg@vdmz1mail.ifremer.fr> References: <20141004015701.1317100ree0hhbyl@vdmz1mail.ifremer.fr> <20141006233638.344549nfud9jit7q@vdmz1mail.ifremer.fr> <21555.4942.183138.546361@max.nulle.part> <20141007003106.12955bk55jorvodm@vdmz1mail.ifremer.fr> <20141008012001.17881f6rhr4xh1y9@vdmz1mail.ifremer.fr> <21556.31554.202302.21490@max.nulle.part> <20141008015940.149442hq00h8pzzg@vdmz1mail.ifremer.fr> Message-ID: <21556.33414.102223.631405@max.nulle.part> Hi Pierre, On 8 October 2014 at 01:59, Pierre.Gloaguen at ifremer.fr wrote: | I will do what I can to reduce the code and have to same error occuring. | Of course i don't expect you to read all of it :) I was just wondering | if that kind of memory problem occured before, and if has some | "typical/generic" solutions. | I will try to have a shortest code to exhibit. Really appreciate it. Many of us found over the years that just by "creating a better example" to often drill down close enough to the problem core. And the easier you make it for folks to help you, the likier it is that some kind soul from around here can give you a hand. Just lowering the barriers, be it cognitive or just plain effort ... Best, Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org From jpolmsted at gmail.com Wed Oct 8 06:07:09 2014 From: jpolmsted at gmail.com (Jonathan Olmsted) Date: Wed, 8 Oct 2014 00:07:09 -0400 Subject: [Rcpp-devel] R session crashes when largely using a Rcpp sourced function In-Reply-To: <21556.33414.102223.631405@max.nulle.part> References: <20141004015701.1317100ree0hhbyl@vdmz1mail.ifremer.fr> <20141006233638.344549nfud9jit7q@vdmz1mail.ifremer.fr> <21555.4942.183138.546361@max.nulle.part> <20141007003106.12955bk55jorvodm@vdmz1mail.ifremer.fr> <20141008012001.17881f6rhr4xh1y9@vdmz1mail.ifremer.fr> <21556.31554.202302.21490@max.nulle.part> <20141008015940.149442hq00h8pzzg@vdmz1mail.ifremer.fr> <21556.33414.102223.631405@max.nulle.part> Message-ID: Pierre, Have you used a tool like Valgrind? There is a bit of a learning curve, but it is exceedingly useful. A few comments: 1) For cases likes this gctortute(TRUE) in your R script helps those ?for enough iterations in a loop?? bugs to present quickly. With gctorture(TRUE) I?m producing the crash with fewer than 50 iters. ?2) What you are implementing has everything to do with RNGs, so setting the seed is useful for reproducibility? ?.? 2) I got useful messages from Valgrind after changing your prefix increments to postfix increments, but I didn?t before making that switch ? (if I remember correctly)? . 3) These msgs points me to these lines for(int i = 1; i < kappa+2; i++){ phi_omega[i-1] = phi_C(arma::trans(omegas.row(i)), piks,muks,Cks,Gamma); } accept = all_C((phi_omega < Upsilon)); in main_function_C(). Pretty sure you have an ?off by 1? error here. kappa is an int, phi_omega has kappa elements (in elements 0 through kappa -1), but you refer to elements 1-1=0 through kappa+1-1=kappa which is the position of the kappa+1st elem. I switched your loop to for(int i = 1; i < kappa+1; i++) and it is running under Valgrind now (i.e. slowly) and it?s gotten farther than any other run thus far. ? Without having a conceptual understanding of what you are trying to do, I have no idea if this is the right fix for you (and I may be mistaken altogether of course...). HTH, Jonathan? ? On Tue, Oct 7, 2014 at 8:17 PM, Dirk Eddelbuettel wrote: > > Hi Pierre, > > On 8 October 2014 at 01:59, Pierre.Gloaguen at ifremer.fr wrote: > | I will do what I can to reduce the code and have to same error occuring. > | Of course i don't expect you to read all of it :) I was just wondering > | if that kind of memory problem occured before, and if has some > | "typical/generic" solutions. > | I will try to have a shortest code to exhibit. > > Really appreciate it. > > Many of us found over the years that just by "creating a better example" to > often drill down close enough to the problem core. > > And the easier you make it for folks to help you, the likier it is that > some > kind soul from around here can give you a hand. > > Just lowering the barriers, be it cognitive or just plain effort ... > > Best, Dirk > > -- > http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org > _______________________________________________ > Rcpp-devel mailing list > Rcpp-devel at lists.r-forge.r-project.org > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel > -- J.P. Olmsted j.p.olmsted at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Pierre.Gloaguen at ifremer.fr Wed Oct 8 08:18:31 2014 From: Pierre.Gloaguen at ifremer.fr (Pierre.Gloaguen at ifremer.fr) Date: Wed, 08 Oct 2014 08:18:31 +0200 Subject: [Rcpp-devel] R session crashes when largely using a Rcpp sourced function In-Reply-To: References: <20141004015701.1317100ree0hhbyl@vdmz1mail.ifremer.fr> <20141006233638.344549nfud9jit7q@vdmz1mail.ifremer.fr> <21555.4942.183138.546361@max.nulle.part> <20141007003106.12955bk55jorvodm@vdmz1mail.ifremer.fr> <20141008012001.17881f6rhr4xh1y9@vdmz1mail.ifremer.fr> <21556.31554.202302.21490@max.nulle.part> <20141008015940.149442hq00h8pzzg@vdmz1mail.ifremer.fr> <21556.33414.102223.631405@max.nulle.part> Message-ID: <20141008081831.18731oth3smel92v@vdmz1mail.ifremer.fr> Hello Jonathan, Thanks a lot for your help. I didn't know valgrind, but i'll definitely go into it. Thanks very much for your help. So, you think I should go to postfix increments instead of prefix? I'm a beginner in C++, so I'm not comfortable on which of them to chose. You seem to be right on my mistake on the loop, I'll check it more carefuly tomorow. If it still don't work after these fixings, I'll try to have a shorter version as Dirk suggested, so it will be easier to point out mistakes from this whole code. Again, thank you for your help, and if you're interested I could describe you in details the goals of this code (i guess it's not the purpose of tis list) I'll let you know! Pierre Jonathan Olmsted a ?crit?: > Pierre, > > Have you used a tool like Valgrind? There is a bit of a learning curve, but > it is exceedingly useful. > > A few comments: > > 1) For cases likes this gctortute(TRUE) in your R script helps those ?for > enough iterations in a loop?? bugs to present quickly. With gctorture(TRUE) > I?m producing the crash with fewer than 50 iters. > > ?2) What you are implementing has everything to do with RNGs, so setting > the seed is useful for reproducibility? > ?.? > > 2) I got useful messages from Valgrind after changing your prefix > increments to postfix increments, but I didn?t before making that switch > ? (if I remember correctly)? > . > > 3) These msgs points me to these lines > > for(int i = 1; i < kappa+2; i++){ > phi_omega[i-1] = phi_C(arma::trans(omegas.row(i)), > piks,muks,Cks,Gamma); > } > accept = all_C((phi_omega < Upsilon)); > > in main_function_C(). Pretty sure you have an ?off by 1? error here. kappa > is an int, phi_omega has kappa elements (in elements 0 through kappa -1), > but you refer to elements 1-1=0 through kappa+1-1=kappa which is the > position of the kappa+1st elem. > > I switched your loop to for(int i = 1; i < kappa+1; i++) and it is running > under Valgrind now (i.e. slowly) and it?s gotten farther than any other run > thus far. > ? Without having a conceptual understanding of what you are trying to do, I > have no idea if this is the right fix for you (and I may be mistaken > altogether of course...). > > HTH, > Jonathan? > > ? > > On Tue, Oct 7, 2014 at 8:17 PM, Dirk Eddelbuettel wrote: > >> >> Hi Pierre, >> >> On 8 October 2014 at 01:59, Pierre.Gloaguen at ifremer.fr wrote: >> | I will do what I can to reduce the code and have to same error occuring. >> | Of course i don't expect you to read all of it :) I was just wondering >> | if that kind of memory problem occured before, and if has some >> | "typical/generic" solutions. >> | I will try to have a shortest code to exhibit. >> >> Really appreciate it. >> >> Many of us found over the years that just by "creating a better example" to >> often drill down close enough to the problem core. >> >> And the easier you make it for folks to help you, the likier it is that >> some >> kind soul from around here can give you a hand. >> >> Just lowering the barriers, be it cognitive or just plain effort ... >> >> Best, Dirk >> >> -- >> http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org >> _______________________________________________ >> Rcpp-devel mailing list >> Rcpp-devel at lists.r-forge.r-project.org >> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel >> > > > > -- > > J.P. Olmsted > j.p.olmsted at gmail.com > From jpolmsted at gmail.com Wed Oct 8 15:53:44 2014 From: jpolmsted at gmail.com (Jonathan Olmsted) Date: Wed, 8 Oct 2014 09:53:44 -0400 Subject: [Rcpp-devel] R session crashes when largely using a Rcpp sourced function In-Reply-To: <20141008081831.18731oth3smel92v@vdmz1mail.ifremer.fr> References: <20141004015701.1317100ree0hhbyl@vdmz1mail.ifremer.fr> <20141006233638.344549nfud9jit7q@vdmz1mail.ifremer.fr> <21555.4942.183138.546361@max.nulle.part> <20141007003106.12955bk55jorvodm@vdmz1mail.ifremer.fr> <20141008012001.17881f6rhr4xh1y9@vdmz1mail.ifremer.fr> <21556.31554.202302.21490@max.nulle.part> <20141008015940.149442hq00h8pzzg@vdmz1mail.ifremer.fr> <21556.33414.102223.631405@max.nulle.part> <20141008081831.18731oth3smel92v@vdmz1mail.ifremer.fr> Message-ID: > > So, you think I should go to postfix increments instead of prefix? > I'm a beginner in C++, so I'm not comfortable on which of them to chose. > ?I was just giving some tips in case you needed to look at the output from Valgrind. When using the prefix, Valgrinds messages didn't lead me right to the problem. When using postfix, they did. A more seasoned user may have been able to identify the problem using prefix, but I did not.? > If it still don't work after these fixings, > ?... fingers crossed. -Jonathan? > Again, thank you for your help, and if you're interested I could describe > you in details the goals of this code (i guess it's not the purpose of tis > list) > I'll let you know! > > Pierre > > > Jonathan Olmsted a ?crit : > > > Pierre, >> >> Have you used a tool like Valgrind? There is a bit of a learning curve, >> but >> it is exceedingly useful. >> >> A few comments: >> >> 1) For cases likes this gctortute(TRUE) in your R script helps those ?for >> enough iterations in a loop?? bugs to present quickly. With >> gctorture(TRUE) >> I?m producing the crash with fewer than 50 iters. >> >> ?2) What you are implementing has everything to do with RNGs, so setting >> the seed is useful for reproducibility? >> ?.? >> >> 2) I got useful messages from Valgrind after changing your prefix >> increments to postfix increments, but I didn?t before making that switch >> ? (if I remember correctly)? >> . >> >> 3) These msgs points me to these lines >> >> for(int i = 1; i < kappa+2; i++){ >> phi_omega[i-1] = phi_C(arma::trans(omegas.row(i)), >> piks,muks,Cks,Gamma); >> } >> accept = all_C((phi_omega < Upsilon)); >> >> in main_function_C(). Pretty sure you have an ?off by 1? error here. kappa >> is an int, phi_omega has kappa elements (in elements 0 through kappa -1), >> but you refer to elements 1-1=0 through kappa+1-1=kappa which is the >> position of the kappa+1st elem. >> >> I switched your loop to for(int i = 1; i < kappa+1; i++) and it is running >> under Valgrind now (i.e. slowly) and it?s gotten farther than any other >> run >> thus far. >> ? Without having a conceptual understanding of what you are trying to do, >> I >> have no idea if this is the right fix for you (and I may be mistaken >> altogether of course...). >> >> HTH, >> Jonathan? >> >> ? >> >> On Tue, Oct 7, 2014 at 8:17 PM, Dirk Eddelbuettel wrote: >> >> >>> Hi Pierre, >>> >>> On 8 October 2014 at 01:59, Pierre.Gloaguen at ifremer.fr wrote: >>> | I will do what I can to reduce the code and have to same error >>> occuring. >>> | Of course i don't expect you to read all of it :) I was just wondering >>> | if that kind of memory problem occured before, and if has some >>> | "typical/generic" solutions. >>> | I will try to have a shortest code to exhibit. >>> >>> Really appreciate it. >>> >>> Many of us found over the years that just by "creating a better example" >>> to >>> often drill down close enough to the problem core. >>> >>> And the easier you make it for folks to help you, the likier it is that >>> some >>> kind soul from around here can give you a hand. >>> >>> Just lowering the barriers, be it cognitive or just plain effort ... >>> >>> Best, Dirk >>> >>> -- >>> http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org >>> _______________________________________________ >>> Rcpp-devel mailing list >>> Rcpp-devel at lists.r-forge.r-project.org >>> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel >>> >>> >> >> >> -- >> >> J.P. Olmsted >> j.p.olmsted at gmail.com >> >> > > > -- J.P. Olmsted j.p.olmsted at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From edd at debian.org Wed Oct 8 16:10:26 2014 From: edd at debian.org (Dirk Eddelbuettel) Date: Wed, 8 Oct 2014 09:10:26 -0500 Subject: [Rcpp-devel] R session crashes when largely using a Rcpp sourced function In-Reply-To: References: <20141004015701.1317100ree0hhbyl@vdmz1mail.ifremer.fr> <20141006233638.344549nfud9jit7q@vdmz1mail.ifremer.fr> <21555.4942.183138.546361@max.nulle.part> <20141007003106.12955bk55jorvodm@vdmz1mail.ifremer.fr> <20141008012001.17881f6rhr4xh1y9@vdmz1mail.ifremer.fr> <21556.31554.202302.21490@max.nulle.part> <20141008015940.149442hq00h8pzzg@vdmz1mail.ifremer.fr> <21556.33414.102223.631405@max.nulle.part> Message-ID: <21557.17874.5938.58807@max.nulle.part> On 8 October 2014 at 00:07, Jonathan Olmsted wrote: | Have you used a tool like Valgrind? There is a bit of a learning curve, but it | is exceedingly useful. Excellent point. And the "Writing R Extensions" manual has a few tips. Reading the output of valgrind takes a little getting used to though. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org From Pierre.Gloaguen at ifremer.fr Wed Oct 8 20:29:41 2014 From: Pierre.Gloaguen at ifremer.fr (Pierre.Gloaguen at ifremer.fr) Date: Wed, 08 Oct 2014 20:29:41 +0200 Subject: [Rcpp-devel] R session crashes when largely using a Rcpp sourced function In-Reply-To: References: <20141004015701.1317100ree0hhbyl@vdmz1mail.ifremer.fr> <20141006233638.344549nfud9jit7q@vdmz1mail.ifremer.fr> <21555.4942.183138.546361@max.nulle.part> <20141007003106.12955bk55jorvodm@vdmz1mail.ifremer.fr> <20141008012001.17881f6rhr4xh1y9@vdmz1mail.ifremer.fr> <21556.31554.202302.21490@max.nulle.part> <20141008015940.149442hq00h8pzzg@vdmz1mail.ifremer.fr> <21556.33414.102223.631405@max.nulle.part> <20141008081831.18731oth3smel92v@vdmz1mail.ifremer.fr> Message-ID: <20141008202941.10166ljqio4q6mqd@vdmz1mail.ifremer.fr> Hello Jonhatan and Dirk, It seems that the whole issue that I encountered was contained in this "off by 1" in the loop. I feel a bit stupid for that :). I can now compute the operation 10^8 times (embedded in another function) without any problem so far, and without using R function gc(). Just one last question though. In that case, no compiling error like "subscript out of bounds" is returned at the compilation (which would have avoided this problem)? Anyway, thanks a lot for the help, and I'll keep in mind to use Valgrind (or Dr Memory, for windows), even if, so far, I'm learning how to use it. Just one last thing, congratulations for your package, the improvement in computation time is amazing (not far than 1000 times faster in my case)! Thanks again, Pierre Gloaguen Jonathan Olmsted a ?crit?: >> >> So, you think I should go to postfix increments instead of prefix? >> I'm a beginner in C++, so I'm not comfortable on which of them to chose. >> > > ?I was just giving some tips in case you needed to look at the output from > Valgrind. When using the prefix, Valgrinds messages didn't lead me right to > the problem. When using postfix, they did. A more seasoned user may have > been able to identify the problem using prefix, but I did not.? > > > >> If it still don't work after these fixings, >> > > ?... fingers crossed. > > -Jonathan? > > > > >> Again, thank you for your help, and if you're interested I could describe >> you in details the goals of this code (i guess it's not the purpose of tis >> list) >> I'll let you know! >> >> Pierre >> >> >> Jonathan Olmsted a ?crit : >> >> >> Pierre, >>> >>> Have you used a tool like Valgrind? There is a bit of a learning curve, >>> but >>> it is exceedingly useful. >>> >>> A few comments: >>> >>> 1) For cases likes this gctortute(TRUE) in your R script helps those ?for >>> enough iterations in a loop?? bugs to present quickly. With >>> gctorture(TRUE) >>> I?m producing the crash with fewer than 50 iters. >>> >>> ?2) What you are implementing has everything to do with RNGs, so setting >>> the seed is useful for reproducibility? >>> ?.? >>> >>> 2) I got useful messages from Valgrind after changing your prefix >>> increments to postfix increments, but I didn?t before making that switch >>> ? (if I remember correctly)? >>> . >>> >>> 3) These msgs points me to these lines >>> >>> for(int i = 1; i < kappa+2; i++){ >>> phi_omega[i-1] = phi_C(arma::trans(omegas.row(i)), >>> piks,muks,Cks,Gamma); >>> } >>> accept = all_C((phi_omega < Upsilon)); >>> >>> in main_function_C(). Pretty sure you have an ?off by 1? error here. kappa >>> is an int, phi_omega has kappa elements (in elements 0 through kappa -1), >>> but you refer to elements 1-1=0 through kappa+1-1=kappa which is the >>> position of the kappa+1st elem. >>> >>> I switched your loop to for(int i = 1; i < kappa+1; i++) and it is running >>> under Valgrind now (i.e. slowly) and it?s gotten farther than any other >>> run >>> thus far. >>> ? Without having a conceptual understanding of what you are trying to do, >>> I >>> have no idea if this is the right fix for you (and I may be mistaken >>> altogether of course...). >>> >>> HTH, >>> Jonathan? >>> >>> ? >>> >>> On Tue, Oct 7, 2014 at 8:17 PM, Dirk Eddelbuettel wrote: >>> >>> >>>> Hi Pierre, >>>> >>>> On 8 October 2014 at 01:59, Pierre.Gloaguen at ifremer.fr wrote: >>>> | I will do what I can to reduce the code and have to same error >>>> occuring. >>>> | Of course i don't expect you to read all of it :) I was just wondering >>>> | if that kind of memory problem occured before, and if has some >>>> | "typical/generic" solutions. >>>> | I will try to have a shortest code to exhibit. >>>> >>>> Really appreciate it. >>>> >>>> Many of us found over the years that just by "creating a better example" >>>> to >>>> often drill down close enough to the problem core. >>>> >>>> And the easier you make it for folks to help you, the likier it is that >>>> some >>>> kind soul from around here can give you a hand. >>>> >>>> Just lowering the barriers, be it cognitive or just plain effort ... >>>> >>>> Best, Dirk >>>> >>>> -- >>>> http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org >>>> _______________________________________________ >>>> Rcpp-devel mailing list >>>> Rcpp-devel at lists.r-forge.r-project.org >>>> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel >>>> >>>> >>> >>> >>> -- >>> >>> J.P. Olmsted >>> j.p.olmsted at gmail.com >>> >>> >> >> >> > > > -- > > J.P. Olmsted > j.p.olmsted at gmail.com > From authmanc at Mathematik.Uni-Marburg.de Thu Oct 9 14:07:11 2014 From: authmanc at Mathematik.Uni-Marburg.de (Christian Authmann) Date: Thu, 09 Oct 2014 14:07:11 +0200 Subject: [Rcpp-devel] Iterating an Rcpp::DataFrame Message-ID: <54367A6F.4090307@mathematik.uni-marburg.de> Hello, this sounds like a newbie question, but I haven't been able to find a good answer in Rcpp's documentation, source or testcases.. Say I have an internal data type which I want to wrap/unwrap as a DataFrame. template<> SEXP wrap(const Foo &foo) { Rcpp::DataFrame dataframe; for (auto key : foo.keys()) { if (key.is_numeric()) { Rcpp::NumericVector vec; // Fill vector with numbers dataframe[ key ] = vec; } else if (key.is_string()) { Rcpp::StringVector vec; // Fill vector with strings dataframe[ key ] = vec; } // etc } } template<> Foo as(SEXP sexp) { Rcpp::DataFrame dataframe(sexp); // now what? } First, I need to iterate over all vectors in the dataframe. I could access a vector using dataframe["my_key"] but that would require me to have a list of all the keys/column names first. R has a colnames() function, but getting that into an Rcpp::Function and calling it seems overly complicated.. I couldn't find anything in Rcpp's source or testcases.. but maybe there's a simpler way? Problem number two, how do I type the vector once I have it? The dataframe can contain NumericVector or StringVector (or possibly something different). Should I just construct each type, try/catch the exceptions and see what fits, or is there a better way to determine the type of a SEXP? Thanks! Christian -- Christian Authmann Philipps-Universit?t Marburg Fachbereich Mathematik und Informatik AG Datenbanksysteme Hans-Meerwein-Stra?e D-35032 Marburg From edd at debian.org Thu Oct 9 14:33:24 2014 From: edd at debian.org (Dirk Eddelbuettel) Date: Thu, 9 Oct 2014 07:33:24 -0500 Subject: [Rcpp-devel] Iterating an Rcpp::DataFrame In-Reply-To: <54367A6F.4090307@mathematik.uni-marburg.de> References: <54367A6F.4090307@mathematik.uni-marburg.de> Message-ID: <21558.32916.47027.115814@max.nulle.part> On 9 October 2014 at 14:07, Christian Authmann wrote: | Hello, | | this sounds like a newbie question, but I haven't been able to find a | good answer in Rcpp's documentation, source or testcases.. | | Say I have an internal data type which I want to wrap/unwrap as a DataFrame. | | template<> SEXP wrap(const Foo &foo) { | Rcpp::DataFrame dataframe; | for (auto key : foo.keys()) { | if (key.is_numeric()) { | Rcpp::NumericVector vec; | // Fill vector with numbers | dataframe[ key ] = vec; | } | else if (key.is_string()) { | Rcpp::StringVector vec; | // Fill vector with strings | dataframe[ key ] = vec; | } | // etc | } | } | | template<> Foo as(SEXP sexp) { | Rcpp::DataFrame dataframe(sexp); | // now what? | } | | | First, I need to iterate over all vectors in the dataframe. I could | access a vector using | dataframe["my_key"] | but that would require me to have a list of all the keys/column names | first. R has a colnames() function, but getting that into an | Rcpp::Function and calling it seems overly complicated.. | I couldn't find anything in Rcpp's source or testcases.. but maybe | there's a simpler way? DataFrame objects are clunky, that's just the way it is. It is a glorified list of vectors, possibly of different types, with the added constraint of equal length. Not much more really. | Problem number two, how do I type the vector once I have it? The | dataframe can contain NumericVector or StringVector (or possibly | something different). Should I just construct each type, try/catch the | exceptions and see what fits, or is there a better way to determine the | type of a SEXP? In my usage I typically assume that I know the layout. So if the third column is, say, a vector of strings I would assign it to that. For free-form incoming data that is a little harder but I believe we have several 'dispatching based on types' examples floating around here, on the Rcpp Gallery and/or other places. The joys of interfacing a dynamically-typed language with a statically-typed one :) Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org From xian at unm.edu Tue Oct 14 09:29:29 2014 From: xian at unm.edu (Christian Gunning) Date: Tue, 14 Oct 2014 01:29:29 -0600 Subject: [Rcpp-devel] Using an Rcpp module package in an R Reference Class Message-ID: Dear all, I have a working package that uses the Rcpp module mechanism (my RaggedArray project, as per previous discussion), and a working pure-R reference class (RefClass) that does computation on a list-based ragged array. I'm unsure on how to integrate the RaggedArray module into the RefClass. I have a simple example working, but I'm getting inscrutable "expecting an external pointer" errors every time I try something non-trivial. Is there a canonical way to do this, or a good example floating about? I've looked both at direct inheritance: ## but how to initialize the base class? wormSim <- setRefClass("wormSim", contains='RaggedArray', ## parent class fields=c( CF="numeric") ) and at adding a field: ## wormSim <- setRefClass("wormSim", fields=c( CF="numeric", LL = "RaggedArray") ) On a seemingly related note, I'm having trouble figuring out the details of exporting / exposing an Rcpp module to R via standard tools. I've found the following related items, but I'm still confused about how they're related. Are any of these S4-related rather than RefClass related? Any pointers/docs/examples would be appreciated. * Rcpp: RCPP_EXPOSED_CLASS_NODECL(RaggedArray) * Rcpp: setRcppClass("RaggedArray") * roxygen2/NAMESPACE: @exportClass RaggedArray Thanks, Christian From dibarra at aqualogy.net Tue Oct 14 13:29:25 2014 From: dibarra at aqualogy.net (=?iso-8859-1?Q?David_Ibarra_G=F3mez?=) Date: Tue, 14 Oct 2014 13:29:25 +0200 Subject: [Rcpp-devel] Updating R and RInside Message-ID: <73BF4AC06CB74F44BB2575D55439522009742FB663@SRVEXMBV01.ga.local> Hello, I usually build C++ executables on debian 7 (x64) that calls R using RInside. It just so happens that everything it's working with R 2.15 and RInside 0.29. But I wanted some new features of some packages, but It's seem mandatory to upgrade R > 3.0. Originally I installed R (2.15) and RInside from sources with some special configuration options (i.e. ./configure --with-x=no LIBnn=lib --enable-R-shlib). The question is: To upgrade R and R Inside should I follow the analogous way (install from source with special options)... or it's possible and recommendable to use apt-get with some "dev" flag. Regards [cid:image001.jpg at 01CFE7B2.4F4AF0A0] David Ibarra G?mez Jefe de Proyectos Direcci?n de Ingenier?a de Sistemas Aqualogy Aqua Ambiente dibarra at aquology.net ________________________________ Disclaimer: http://disclaimer.aqualogy.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 2816 bytes Desc: image001.jpg URL: From dibarra at aqualogy.net Tue Oct 14 13:34:29 2014 From: dibarra at aqualogy.net (=?iso-8859-1?Q?David_Ibarra_G=F3mez?=) Date: Tue, 14 Oct 2014 13:34:29 +0200 Subject: [Rcpp-devel] Updating R and RInside In-Reply-To: <73BF4AC06CB74F44BB2575D55439522009742FB663@SRVEXMBV01.ga.local> References: <73BF4AC06CB74F44BB2575D55439522009742FB663@SRVEXMBV01.ga.local> Message-ID: <73BF4AC06CB74F44BB2575D55439522009742FB677@SRVEXMBV01.ga.local> Sorry I meant R 2.15.2 and RInside 0.2.9. [cid:image001.jpg at 01CFE7B3.94AF4370] David Ibarra G?mez Jefe de Proyectos Direcci?n de Ingenier?a de Sistemas Aqualogy Aqua Ambiente dibarra at aquology.net Barcelona - Torre Agbar Av Diagonal 211, Pl.2 08018 Barcelona Tel. 933422521/638202619 www.aquambiente.es De: rcpp-devel-bounces at lists.r-forge.r-project.org [mailto:rcpp-devel-bounces at lists.r-forge.r-project.org] En nombre de David Ibarra G?mez Enviado el: martes, 14 de octubre de 2014 13:29 Para: rcpp-devel at lists.r-forge.r-project.org Asunto: [Rcpp-devel] Updating R and RInside Hello, I usually build C++ executables on debian 7 (x64) that calls R using RInside. It just so happens that everything it's working with R 2.15 and RInside 0.29. But I wanted some new features of some packages, but It's seem mandatory to upgrade R > 3.0. Originally I installed R (2.15) and RInside from sources with some special configuration options (i.e. ./configure --with-x=no LIBnn=lib --enable-R-shlib). The question is: To upgrade R and R Inside should I follow the analogous way (install from source with special options)... or it's possible and recommendable to use apt-get with some "dev" flag. Regards [cid:image001.jpg at 01CFE7B3.94AF4370] David Ibarra G?mez Jefe de Proyectos Direcci?n de Ingenier?a de Sistemas Aqualogy Aqua Ambiente dibarra at aquology.net ________________________________ Disclaimer: http://disclaimer.aqualogy.net/ ________________________________ Disclaimer: http://disclaimer.aqualogy.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 2816 bytes Desc: image001.jpg URL: From edd at debian.org Tue Oct 14 14:13:35 2014 From: edd at debian.org (Dirk Eddelbuettel) Date: Tue, 14 Oct 2014 07:13:35 -0500 Subject: [Rcpp-devel] Updating R and RInside In-Reply-To: <73BF4AC06CB74F44BB2575D55439522009742FB663@SRVEXMBV01.ga.local> References: <73BF4AC06CB74F44BB2575D55439522009742FB663@SRVEXMBV01.ga.local> Message-ID: <21565.4975.182028.192781@max.nulle.part> On 14 October 2014 at 13:29, David Ibarra G?mez wrote: | I usually build C++ executables on debian 7 (x64) that calls R | using RInside. It just so happens that everything it?s working with R 2.15 and | RInside 0.29. But I wanted some new features of some packages, but It?s seem | mandatory to upgrade R > 3.0. The way the R ecosystem works is that CRAN sometimes suggests we make changes in packages, which then in turn depend on something in the R 'system'. The clearest recent example was a move of the vignettes/ directory, which in turn with changes in R, lead many packages have a Depends: R (>= 3.0.0) If you know what you are doing, none of this is binding to you. The __only__ interface Rcpp touches from R is SEXP .Call(SEXP a, SEXP b, ...) and as this is plain C nothing has changed [1]. So there should be no changes on your side you could not accomodate with, if need be, some editing of the DESCRIPTION files. In a nutshell: there is no issue here you can't address, but as you have not asked a concrete (reproducible) question I can't give a more concrete answer. | Originally I installed R (2.15) and RInside from sources with some special | configuration options (i.e. ./configure --with-x=no LIBnn=lib | --enable-R-shlib). R configuration has little to do with on R package builds. | The question is: To upgrade R and R Inside should I follow the analogous way | (install from source with special options)? or it?s possible and recommendable | to use apt-get with some ?dev? flag. Whether you use apt-get for prebuild binary, or work from source has not so much to do with Rcpp and more with how you run your system -- maybe a question for r-sig-debian? For what it is worth, on all my .deb systems at home and work, I install Rcpp and friends from source. Hope this helps, Dirk [1] As an aside, and despite what some may claim, this also means that it does not matter which C++ dialect or flavour you use -- they all communicate with R via the same plain C interface -- and favouring one to the exclusion of the others is at the end of the day just a constraint on what you can, or cannot, use. I rather avoid such constraints, but it is fine that people have choices. | | | | Regards | | | | | | | | | | | | cid:image004.jpg at 01CCF71E.03D7B6D0 | | David Ibarra G?mez | | Jefe de Proyectos | | Direcci?n de Ingenier?a de | Sistemas | | Aqualogy Aqua Ambiente | | dibarra at aquology.net | | | | | | | | | | | | | | ------------------------------------------------------------------------------- | Disclaimer: http://disclaimer.aqualogy.net/ | _______________________________________________ | Rcpp-devel mailing list | Rcpp-devel at lists.r-forge.r-project.org | https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel -- http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org From xian at unm.edu Tue Oct 14 22:42:00 2014 From: xian at unm.edu (Christian Gunning) Date: Tue, 14 Oct 2014 14:42:00 -0600 Subject: [Rcpp-devel] Using an Rcpp module package in an R Reference Class Message-ID: On Tue, Oct 14, 2014 at 9:19 AM, Dr Gregory Jefferis wrote: > >> * Rcpp: RCPP_EXPOSED_CLASS_NODECL(RaggedArray) >> * Rcpp: setRcppClass("RaggedArray") >> * roxygen2/NAMESPACE: @exportClass RaggedArray > > I'm not sure if the exact issue here, but you could look at this package > that I wrote: > > https://github.com/jefferis/nabor > > and in particular > > https://github.com/jefferis/nabor/blob/master/R/WKNNClasses.R > https://github.com/jefferis/nabor/blob/master/src/WKNN.cpp > Yeah, I found your package and used it as a prototype to fix a few things, but I'm honestly still short on understanding. Here's my reading of the above 3 *s: * I've read ?setRcppClass, and looked at the definition (e.g. Rcpp::setRcppClass) and I'm not clear on when this is required, and whether its RefClass or S4. * The best explanation of the RCPP_EXPOSED_CLASS macro I found was here: http://romainfrancois.blog.free.fr/index.php?post/2012/10/25/Rcpp-modules-more-flexible. My understanding is that this only involves the C++ side, and is totally unrelated to a pure-R reference class using an Rcpp module object and its methods. * The @exportClassses directive creates an exportClasses entry in NAMESPACE. Looking at "Writing R extensions", it looks like this is particular to S4 classses. In fact, I can't find mention of reference classes in "Writing R extensions". So, I'm murky on what calling exportClasses(myRcppModule) actually does, or how it works. Did I miss anything here? Thanks! Christian -- A man, a plan, a cat, a ham, a yak, a yam, a hat, a canal ? Panama! From dibarra at aqualogy.net Tue Oct 14 23:39:49 2014 From: dibarra at aqualogy.net (=?iso-8859-1?Q?David_Ibarra_G=F3mez?=) Date: Tue, 14 Oct 2014 23:39:49 +0200 Subject: [Rcpp-devel] Updating R and RInside Message-ID: <2sy5yoxpxg7llmbeedafbj21.1413322785118@email.android.com> Well, at least I know where to address more questions, thank you. I'll maybe submit a question to the debian list you mention. I posted here by the rinside installation. I was just looking for the fastest way (the old conf its on several "production" machines), to upgrade R and RInside. Because the last time was neither fast or easy... I'll keep on trying... David Ibarra Gomez Jefe de Proyectos Direcci?n de Ingenier?a de Sistemas Aqualogy Aqua Ambiente dibarra at aqualogy.net Barcelona - Torre Agbar 08018 Barcelona Tel. 933422521 / 638202619 -------- Mensaje original -------- De: Dirk Eddelbuettel Fecha: 14/10/2014 14:13 (GMT+01:00) Para: David Ibarra G?mez Cc: rcpp-devel at lists.r-forge.r-project.org Asunto: Re: [Rcpp-devel] Updating R and RInside On 14 October 2014 at 13:29, David Ibarra G?mez wrote: | I usually build C++ executables on debian 7 (x64) that calls R | using RInside. It just so happens that everything it?s working with R 2.15 and | RInside 0.29. But I wanted some new features of some packages, but It?s seem | mandatory to upgrade R > 3.0. The way the R ecosystem works is that CRAN sometimes suggests we make changes in packages, which then in turn depend on something in the R 'system'. The clearest recent example was a move of the vignettes/ directory, which in turn with changes in R, lead many packages have a Depends: R (>= 3.0.0) If you know what you are doing, none of this is binding to you. The __only__ interface Rcpp touches from R is SEXP .Call(SEXP a, SEXP b, ...) and as this is plain C nothing has changed [1]. So there should be no changes on your side you could not accomodate with, if need be, some editing of the DESCRIPTION files. In a nutshell: there is no issue here you can't address, but as you have not asked a concrete (reproducible) question I can't give a more concrete answer. | Originally I installed R (2.15) and RInside from sources with some special | configuration options (i.e. ./configure --with-x=no LIBnn=lib | --enable-R-shlib). R configuration has little to do with on R package builds. | The question is: To upgrade R and R Inside should I follow the analogous way | (install from source with special options)? or it?s possible and recommendable | to use apt-get with some ?dev? flag. Whether you use apt-get for prebuild binary, or work from source has not so much to do with Rcpp and more with how you run your system -- maybe a question for r-sig-debian? For what it is worth, on all my .deb systems at home and work, I install Rcpp and friends from source. Hope this helps, Dirk [1] As an aside, and despite what some may claim, this also means that it does not matter which C++ dialect or flavour you use -- they all communicate with R via the same plain C interface -- and favouring one to the exclusion of the others is at the end of the day just a constraint on what you can, or cannot, use. I rather avoid such constraints, but it is fine that people have choices. | | | | Regards | | | | | | | | | | | | cid:image004.jpg at 01CCF71E.03D7B6D0 | | David Ibarra G?mez | | Jefe de Proyectos | | Direcci?n de Ingenier?a de | Sistemas | | Aqualogy Aqua Ambiente | | dibarra at aquology.net | | | | | | | | | | | | | | ------------------------------------------------------------------------------- | Disclaimer: http://disclaimer.aqualogy.net/ | _______________________________________________ | Rcpp-devel mailing list | Rcpp-devel at lists.r-forge.r-project.org | https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel -- http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org ________________________________ Disclaimer: http://disclaimer.aqualogy.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From edd at debian.org Tue Oct 14 23:53:38 2014 From: edd at debian.org (Dirk Eddelbuettel) Date: Tue, 14 Oct 2014 16:53:38 -0500 Subject: [Rcpp-devel] Updating R and RInside In-Reply-To: <2sy5yoxpxg7llmbeedafbj21.1413322785118@email.android.com> References: <2sy5yoxpxg7llmbeedafbj21.1413322785118@email.android.com> Message-ID: <21565.39778.582981.789718@max.nulle.part> On 14 October 2014 at 23:39, David Ibarra G?mez wrote: | Well, at least I know where to address more questions, thank you. | | I'll maybe submit a question to the debian list you mention. I posted here by | the rinside installation. I was just looking for the fastest way (the old conf | its on several "production" machines), to upgrade R and RInside. Because the | last time was neither fast or easy... I'll keep on trying... It all depends on what you are comfortable with. If you all you want is to install pre-built r-cran-rcpp and r-cran-rinside, then I (with my Debian maintainer hat on) surely provide those for you. If you don't change them, they should work just fine. On "my" production systems, I do however build Rcpp* et al from source. The whole "should I install CRAN packages as r-cran-* binaries, or from source" nexus is somewhat complicated, but is the wrong question for this list. [ And in case you are wondering, I tend to install mostly from source into /usr/local/lib/R/site-library/ --- but different strokes for different folks. ] Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org From luckyrand at gmail.com Wed Oct 15 04:19:40 2014 From: luckyrand at gmail.com (Chenliang Xu) Date: Tue, 14 Oct 2014 21:19:40 -0500 Subject: [Rcpp-devel] compileAttributes does not scan header files Message-ID: Hello, compileAttributes currently only scan .cpp and .c files, and ignore header files (.h, .hpp). When a function is used in two or more cpp files, the default parameter of function should be provided in function declaration, which is usually included in a header file, so it seems to be nature to scan attributes in header files. Do I miss any reason that prohibit scanning header files? It seems to be straightforward to add support for header files, but I'm not quite sure what is the right behavior. Thanks a lot! -------------- next part -------------- An HTML attachment was scrubbed... URL: From krthornt at uci.edu Wed Oct 15 19:24:36 2014 From: krthornt at uci.edu (Kevin Thornton) Date: Wed, 15 Oct 2014 10:24:36 -0700 Subject: [Rcpp-devel] Template instantiation of commonly-used types Message-ID: <88A1C642-CC00-4BAE-83AF-AF893C653E32@uci.edu> In looking through the Rcpp/0.11.3 code, I came across this file: inst/include/Rcpp/vector/instantiation.h The file contains the declarations for IntegerVector, NumericVector, etc. It seems reasonable to assume that these types will be used in basically any code using Rcpp. The declarations are aliases to templates. For example: typedef Vector NumericVector ; The effect of this is that every .cpp file declaring a NumericVector must recompile the template, because these declarations rely on implicit instantiation. However, from the perspective of an Rcpp user, these types are actually not templates. In other words, there is no NumericVector template providing compile-time polymorphism, and NumericVector is a fully-specified type. The implicit instantiation increases both compile time and object file size ("code bloat") for packages using Rcpp. As such, I'd suggest that these types should be provided pre-compiled in the Rcpp dynamic object, which can be done via explicit template instantiation (http://en.cppreference.com/w/cpp/language/class_template). I've put a modified instantation.h at https://gist.github.com/5180d60689fa8d6cb353.git and the corresponding (and incomplete) .cpp file at https://gist.github.com/c13135659e0b27421a3a.git. This implementation should result in a situation where the object code for these types is present only once on a user's system, rather than being replicated once per package that is using Rcpp. While I appreciate that Rcpp is "header-only", I think that the current declaration of these types is better-served with compiled code, for the reasons mentioned above. However, I may be missing something--perhaps there is something about the way dynamic objects in R do things that means this approach would not work? ___________________________ Kevin Thornton Associate Professor Ecology and Evolutionary Biology University of California, Irvine http://www.molpopgen.org From krthornt at uci.edu Wed Oct 15 19:28:54 2014 From: krthornt at uci.edu (Kevin Thornton) Date: Wed, 15 Oct 2014 10:28:54 -0700 Subject: [Rcpp-devel] Template instantiation of commonly-used types In-Reply-To: <88A1C642-CC00-4BAE-83AF-AF893C653E32@uci.edu> References: <88A1C642-CC00-4BAE-83AF-AF893C653E32@uci.edu> Message-ID: I should clarify: those git gist are the "git clone" links. Here are the direct links for viewing: The .h: https://gist.github.com/molpopgen/5180d60689fa8d6cb353 The .cpp: https://gist.github.com/molpopgen/c13135659e0b27421a3a ___________________________ Kevin Thornton Associate Professor Ecology and Evolutionary Biology University of California, Irvine http://www.molpopgen.org From edd at debian.org Wed Oct 15 20:01:59 2014 From: edd at debian.org (Dirk Eddelbuettel) Date: Wed, 15 Oct 2014 13:01:59 -0500 Subject: [Rcpp-devel] Template instantiation of commonly-used types In-Reply-To: References: <88A1C642-CC00-4BAE-83AF-AF893C653E32@uci.edu> Message-ID: <21566.46743.468161.686580@max.nulle.part> On 15 October 2014 at 10:28, Kevin Thornton wrote: | I should clarify: those git gist are the "git clone" links. Here are the direct links for viewing: | | The .h: https://gist.github.com/molpopgen/5180d60689fa8d6cb353 | | The .cpp: https://gist.github.com/molpopgen/c13135659e0b27421a3a Could you give it a spin and actually try how R CMD check behaves if you do that? And/or check how any of the Rcpp dependents behaves? Maybe give numbers for the gain in compilation you try to achieve? If it does work we can surely condition via configure on the appropriate compiler and version. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org From kevinushey at gmail.com Wed Oct 15 20:14:58 2014 From: kevinushey at gmail.com (Kevin Ushey) Date: Wed, 15 Oct 2014 11:14:58 -0700 Subject: [Rcpp-devel] Template instantiation of commonly-used types In-Reply-To: <21566.46743.468161.686580@max.nulle.part> References: <88A1C642-CC00-4BAE-83AF-AF893C653E32@uci.edu> <21566.46743.468161.686580@max.nulle.part> Message-ID: If we were to have these vectors as part of the shared object rather than header-only, wouldn't this imply breakage for existing packages if newer versions of Rcpp changed the Vector template class implementation (perhaps it inherits new policies, or gains new methods, or methods change, or becomes templated in a different way)? This is unlikely but it could happen down the line. Also, doesn't it imply fewer opportunities for the compiler to inline code when possible? Part of the reason Rcpp is header only is that it gives the compiler opportunities to inline all parts when sensible; by having the Vector class external the compiler can lose the ability to inline these calls. Overall I feel fairly uncomfortable moving away from header-only-ness in Rcpp (although we could be persuaded otherwise) -- reducing compile time / binary size doesn't seem a convincing enough reason to steer away from being header only as possible. On Wed, Oct 15, 2014 at 11:01 AM, Dirk Eddelbuettel wrote: > > On 15 October 2014 at 10:28, Kevin Thornton wrote: > | I should clarify: those git gist are the "git clone" links. Here are the direct links for viewing: > | > | The .h: https://gist.github.com/molpopgen/5180d60689fa8d6cb353 > | > | The .cpp: https://gist.github.com/molpopgen/c13135659e0b27421a3a > > Could you give it a spin and actually try how R CMD check behaves if you do > that? And/or check how any of the Rcpp dependents behaves? Maybe give > numbers for the gain in compilation you try to achieve? > > If it does work we can surely condition via configure on the appropriate > compiler and version. > > Dirk > > -- > http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org > _______________________________________________ > Rcpp-devel mailing list > Rcpp-devel at lists.r-forge.r-project.org > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel From jj.allaire at gmail.com Wed Oct 15 20:16:24 2014 From: jj.allaire at gmail.com (JJ Allaire) Date: Wed, 15 Oct 2014 14:16:24 -0400 Subject: [Rcpp-devel] Template instantiation of commonly-used types In-Reply-To: References: <88A1C642-CC00-4BAE-83AF-AF893C653E32@uci.edu> <21566.46743.468161.686580@max.nulle.part> Message-ID: Yeah, we definitely want to keep things header-only for ABI stability. This is pretty non-negotiable IMHO. On Wed, Oct 15, 2014 at 2:14 PM, Kevin Ushey wrote: > If we were to have these vectors as part of the shared object rather > than header-only, wouldn't this imply breakage for existing packages > if newer versions of Rcpp changed the Vector template class > implementation (perhaps it inherits new policies, or gains new > methods, or methods change, or becomes templated in a different way)? > This is unlikely but it could happen down the line. > > Also, doesn't it imply fewer opportunities for the compiler to inline > code when possible? Part of the reason Rcpp is header only is that it > gives the compiler opportunities to inline all parts when sensible; by > having the Vector class external the compiler can lose the ability to > inline these calls. > > Overall I feel fairly uncomfortable moving away from header-only-ness > in Rcpp (although we could be persuaded otherwise) -- reducing compile > time / binary size doesn't seem a convincing enough reason to steer > away from being header only as possible. > > On Wed, Oct 15, 2014 at 11:01 AM, Dirk Eddelbuettel wrote: >> >> On 15 October 2014 at 10:28, Kevin Thornton wrote: >> | I should clarify: those git gist are the "git clone" links. Here are the direct links for viewing: >> | >> | The .h: https://gist.github.com/molpopgen/5180d60689fa8d6cb353 >> | >> | The .cpp: https://gist.github.com/molpopgen/c13135659e0b27421a3a >> >> Could you give it a spin and actually try how R CMD check behaves if you do >> that? And/or check how any of the Rcpp dependents behaves? Maybe give >> numbers for the gain in compilation you try to achieve? >> >> If it does work we can surely condition via configure on the appropriate >> compiler and version. >> >> Dirk >> >> -- >> http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org >> _______________________________________________ >> Rcpp-devel mailing list >> Rcpp-devel at lists.r-forge.r-project.org >> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel > _______________________________________________ > Rcpp-devel mailing list > Rcpp-devel at lists.r-forge.r-project.org > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel From krthornt at uci.edu Wed Oct 15 20:17:32 2014 From: krthornt at uci.edu (Kevin Thornton) Date: Wed, 15 Oct 2014 11:17:32 -0700 Subject: [Rcpp-devel] Template instantiation of commonly-used types In-Reply-To: <21566.46743.468161.686580@max.nulle.part> References: <88A1C642-CC00-4BAE-83AF-AF893C653E32@uci.edu> <21566.46743.468161.686580@max.nulle.part> Message-ID: On Oct 15, 2014, at 11:01 AM, Dirk Eddelbuettel wrote: > > On 15 October 2014 at 10:28, Kevin Thornton wrote: > | I should clarify: those git gist are the "git clone" links. Here are the direct links for viewing: > | > | The .h: https://gist.github.com/molpopgen/5180d60689fa8d6cb353 > | > | The .cpp: https://gist.github.com/molpopgen/c13135659e0b27421a3a > > Could you give it a spin and actually try how R CMD check behaves if you do > that? And/or check how any of the Rcpp dependents behaves? Maybe give > numbers for the gain in compilation you try to achieve? > > If it does work we can surely condition via configure on the appropriate > compiler and version. > I can try, but getting the .cpp to compile is a chore (for me). I'm having to work out the code structure of the entire package. > Dirk > > -- > http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org ___________________________ Kevin Thornton Associate Professor Ecology and Evolutionary Biology University of California, Irvine http://www.molpopgen.org From krthornt at uci.edu Wed Oct 15 20:19:21 2014 From: krthornt at uci.edu (Kevin Thornton) Date: Wed, 15 Oct 2014 11:19:21 -0700 Subject: [Rcpp-devel] Template instantiation of commonly-used types In-Reply-To: References: <88A1C642-CC00-4BAE-83AF-AF893C653E32@uci.edu> <21566.46743.468161.686580@max.nulle.part> Message-ID: On Oct 15, 2014, at 11:14 AM, Kevin Ushey wrote: > If we were to have these vectors as part of the shared object rather > than header-only, wouldn't this imply breakage for existing packages > if newer versions of Rcpp changed the Vector template class > implementation (perhaps it inherits new policies, or gains new > methods, or methods change, or becomes templated in a different way)? > This is unlikely but it could happen down the line. > Yes, this is a potential cost. > Also, doesn't it imply fewer opportunities for the compiler to inline > code when possible? Part of the reason Rcpp is header only is that it > gives the compiler opportunities to inline all parts when sensible; by > having the Vector class external the compiler can lose the ability to > inline these calls. Not necessarily. > > Overall I feel fairly uncomfortable moving away from header-only-ness > in Rcpp (although we could be persuaded otherwise) -- reducing compile > time / binary size doesn't seem a convincing enough reason to steer > away from being header only as possible. > > On Wed, Oct 15, 2014 at 11:01 AM, Dirk Eddelbuettel wrote: >> >> On 15 October 2014 at 10:28, Kevin Thornton wrote: >> | I should clarify: those git gist are the "git clone" links. Here are the direct links for viewing: >> | >> | The .h: https://gist.github.com/molpopgen/5180d60689fa8d6cb353 >> | >> | The .cpp: https://gist.github.com/molpopgen/c13135659e0b27421a3a >> >> Could you give it a spin and actually try how R CMD check behaves if you do >> that? And/or check how any of the Rcpp dependents behaves? Maybe give >> numbers for the gain in compilation you try to achieve? >> >> If it does work we can surely condition via configure on the appropriate >> compiler and version. >> >> Dirk >> >> -- >> http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org >> _______________________________________________ >> Rcpp-devel mailing list >> Rcpp-devel at lists.r-forge.r-project.org >> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel ___________________________ Kevin Thornton Associate Professor Ecology and Evolutionary Biology University of California, Irvine http://www.molpopgen.org From krthornt at uci.edu Wed Oct 15 20:31:56 2014 From: krthornt at uci.edu (Kevin Thornton) Date: Wed, 15 Oct 2014 11:31:56 -0700 Subject: [Rcpp-devel] Template instantiation of commonly-used types In-Reply-To: <21566.46743.468161.686580@max.nulle.part> References: <88A1C642-CC00-4BAE-83AF-AF893C653E32@uci.edu> <21566.46743.468161.686580@max.nulle.part> Message-ID: <06D3E371-C58B-43E9-876A-FF319D841147@uci.edu> It looks like this is beyond me at the moment, and would require the attention of someone who knows the code base. Even including Rcpp.h in the .cpp file returns errors, which I find rather puzzling. On Oct 15, 2014, at 11:01 AM, Dirk Eddelbuettel wrote: > > On 15 October 2014 at 10:28, Kevin Thornton wrote: > | I should clarify: those git gist are the "git clone" links. Here are the direct links for viewing: > | > | The .h: https://gist.github.com/molpopgen/5180d60689fa8d6cb353 > | > | The .cpp: https://gist.github.com/molpopgen/c13135659e0b27421a3a > > Could you give it a spin and actually try how R CMD check behaves if you do > that? And/or check how any of the Rcpp dependents behaves? Maybe give > numbers for the gain in compilation you try to achieve? > > If it does work we can surely condition via configure on the appropriate > compiler and version. > > Dirk > > -- > http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org ___________________________ Kevin Thornton Associate Professor Ecology and Evolutionary Biology University of California, Irvine http://www.molpopgen.org From edd at debian.org Wed Oct 15 20:52:04 2014 From: edd at debian.org (Dirk Eddelbuettel) Date: Wed, 15 Oct 2014 13:52:04 -0500 Subject: [Rcpp-devel] Template instantiation of commonly-used types In-Reply-To: References: <88A1C642-CC00-4BAE-83AF-AF893C653E32@uci.edu> <21566.46743.468161.686580@max.nulle.part> Message-ID: <21566.49748.190231.870166@max.nulle.part> On 15 October 2014 at 11:17, Kevin Thornton wrote: | | On Oct 15, 2014, at 11:01 AM, Dirk Eddelbuettel wrote: | | > | > On 15 October 2014 at 10:28, Kevin Thornton wrote: | > | I should clarify: those git gist are the "git clone" links. Here are the direct links for viewing: | > | | > | The .h: https://gist.github.com/molpopgen/5180d60689fa8d6cb353 | > | | > | The .cpp: https://gist.github.com/molpopgen/c13135659e0b27421a3a | > | > Could you give it a spin and actually try how R CMD check behaves if you do | > that? And/or check how any of the Rcpp dependents behaves? Maybe give | > numbers for the gain in compilation you try to achieve? | > | > If it does work we can surely condition via configure on the appropriate | > compiler and version. | > | | I can try, but getting the .cpp to compile is a chore (for me). I'm having to work out the code structure of the entire package. I am not sure how familiar you are with R, and R packages but most of us generally do cd .. # out of the repo directory containing DESCRIPTION, src, ... R CMD build rcpp # assuming your repo directory is called rcpp/ R CMD check Rcpp_0.11.3.4.tar.gz # or whatever versioning comes from DESCRIPTION which isn't all that terribly involved. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org From henrik.singmann at psychologie.uni-freiburg.de Wed Oct 15 20:59:59 2014 From: henrik.singmann at psychologie.uni-freiburg.de (Henrik Singmann) Date: Wed, 15 Oct 2014 20:59:59 +0200 Subject: [Rcpp-devel] RcppEigen: Windows binary from CRAN crashes R, but not when installing from source. Message-ID: <543EC42F.1000001@psychologie.uni-freiburg.de> Dear list, I have the following weird problem and would be really glad for any input: The windows binary from CRAN for my package MPTinR, which uses RcppEigen, leads to an "Assertion failed" error which crashes R with a simple example given below (which unfortunately is not part of the examples and henceforth not tested by CRAN). Interestingly enough, the problem disappears when installing the package on Windows from source or when using Linux (Ubuntu). But it also appears when using a binary version of MPTinR from winbuilder (temporarily available here: http://win-builder.r-project.org/h18PJ7B55VAq), R-devel and corresponding binary from CRAN, and I could replicate the error on a range of different Windows machines. The error also always disappears when installing from source. I am also extremely confident that this problem didn't exist in the past, I and others have used this functionality regularly with the CRAN windows binary. ###### code starts ####### require(MPTinR) data(d.broeder) m.2htm <- system.file("extdata", "5points.2htm.model", package = "MPTinR") get.mpt.fia(d.broeder, m.2htm) ###### code ends ####### The complete error message is: ###### error message starts ####### Assertion failed! Program: C:\Program Files\RStudio\bin\x64\rsession.exe File: d:/RCompile/CRANpkg/lib/3.1/RcppEigen/include/Eigen/src/Core/ProductBase.h, Line 95 Expression: a_lhs.cols() == a_rhs.rows() && "invalid matrix product" && "if you wanted a coeff-wise or a dot product use the respective explicit functions" This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. ###### error message ends ####### When adding such an example to the code and resubmitting it to winbuilder it now also crashes, see http://win-builder.r-project.org/0ei38q0t48h2/00check.log But again, when installing the same package on my machine from source it works. Best, Henrik PS: A session info (without attaching MPTinR) is given below: R version 3.1.1 (2014-07-10) Platform: x86_64-w64-mingw32/x64 (64-bit) locale: [1] LC_COLLATE=German_Switzerland.1252 LC_CTYPE=German_Switzerland.1252 LC_MONETARY=German_Switzerland.1252 [4] LC_NUMERIC=C LC_TIME=German_Switzerland.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base other attached packages: [1] devtools_1.6 loaded via a namespace (and not attached): [1] fortunes_1.5-2 tools_3.1.1 -- Dr. Henrik Singmann Universit?t Z?rich, Schweiz http://singmann.org From edd at debian.org Wed Oct 15 21:13:50 2014 From: edd at debian.org (Dirk Eddelbuettel) Date: Wed, 15 Oct 2014 14:13:50 -0500 Subject: [Rcpp-devel] RcppEigen: Windows binary from CRAN crashes R, but not when installing from source. In-Reply-To: <543EC42F.1000001@psychologie.uni-freiburg.de> References: <543EC42F.1000001@psychologie.uni-freiburg.de> Message-ID: <21566.51054.502184.443950@max.nulle.part> Hi Henrik, On 15 October 2014 at 20:59, Henrik Singmann wrote: | Dear list, | | I have the following weird problem and would be really glad for any input: | | The windows binary from CRAN for my package MPTinR, which uses RcppEigen, leads to an "Assertion failed" error which crashes R with a simple example given below (which unfortunately is not part of the examples and henceforth not tested by CRAN). | | Interestingly enough, the problem disappears when installing the package on Windows from source or when using Linux (Ubuntu). But it also appears when using a binary version of MPTinR from winbuilder (temporarily available here: http://win-builder.r-project.org/h18PJ7B55VAq), R-devel and corresponding binary from CRAN, and I could replicate the error on a range of different Windows machines. The error also always disappears when installing from source. I am also extremely confident that this problem didn't exist in the past, I and others have used this functionality regularly with the CRAN windows binary. | | ###### code starts ####### | require(MPTinR) | data(d.broeder) | m.2htm <- system.file("extdata", "5points.2htm.model", package = "MPTinR") | get.mpt.fia(d.broeder, m.2htm) | ###### code ends ####### | | The complete error message is: | | ###### error message starts ####### | Assertion failed! | | Program: C:\Program Files\RStudio\bin\x64\rsession.exe | File: d:/RCompile/CRANpkg/lib/3.1/RcppEigen/include/Eigen/src/Core/ProductBase.h, Line 95 | | Expression: a_lhs.cols() == a_rhs.rows() && "invalid matrix product" && "if you wanted a coeff-wise or a dot product use the respective explicit functions" | | This application has requested the Runtime to terminate it in an unusual way. | Please contact the application's support team for more information. | ###### error message ends ####### | | When adding such an example to the code and resubmitting it to winbuilder it now also crashes, see http://win-builder.r-project.org/0ei38q0t48h2/00check.log | But again, when installing the same package on my machine from source it works. It would help us if you could create a minimally reproducible example exhibit this behaviour. About 24 CRAN packages use RcppEigen. The error could be yours, or ours. But given the information provided so far it is hard to say more. You could also try R along with valgrind on Linux to see if that tickles it. Dirk | Best, | Henrik | | PS: A session info (without attaching MPTinR) is given below: | | R version 3.1.1 (2014-07-10) | Platform: x86_64-w64-mingw32/x64 (64-bit) | | locale: | [1] LC_COLLATE=German_Switzerland.1252 LC_CTYPE=German_Switzerland.1252 LC_MONETARY=German_Switzerland.1252 | [4] LC_NUMERIC=C LC_TIME=German_Switzerland.1252 | | attached base packages: | [1] stats graphics grDevices utils datasets methods base | | other attached packages: | [1] devtools_1.6 | | loaded via a namespace (and not attached): | [1] fortunes_1.5-2 tools_3.1.1 | | | | -- | Dr. Henrik Singmann | Universit?t Z?rich, Schweiz | http://singmann.org | _______________________________________________ | Rcpp-devel mailing list | Rcpp-devel at lists.r-forge.r-project.org | https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel -- http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org From yixuan.qiu at cos.name Wed Oct 15 21:13:58 2014 From: yixuan.qiu at cos.name (Yixuan Qiu) Date: Wed, 15 Oct 2014 15:13:58 -0400 Subject: [Rcpp-devel] RcppEigen: Windows binary from CRAN crashes R, but not when installing from source. In-Reply-To: <543EC42F.1000001@psychologie.uni-freiburg.de> References: <543EC42F.1000001@psychologie.uni-freiburg.de> Message-ID: Hi Henrik, There seems to be a similar problem here in my package, reported by https://github.com/yixuan/rARPACK/issues/4. The reporter said that the runtime error occured when using RStudio, but disappeared in RGui. Is this the same situation as yours? Best, Yixuan 2014-10-15 14:59 GMT-04:00 Henrik Singmann < henrik.singmann at psychologie.uni-freiburg.de>: > Dear list, > > I have the following weird problem and would be really glad for any input: > > The windows binary from CRAN for my package MPTinR, which uses RcppEigen, > leads to an "Assertion failed" error which crashes R with a simple example > given below (which unfortunately is not part of the examples and henceforth > not tested by CRAN). > > Interestingly enough, the problem disappears when installing the package > on Windows from source or when using Linux (Ubuntu). But it also appears > when using a binary version of MPTinR from winbuilder (temporarily > available here: http://win-builder.r-project.org/h18PJ7B55VAq), R-devel > and corresponding binary from CRAN, and I could replicate the error on a > range of different Windows machines. The error also always disappears when > installing from source. I am also extremely confident that this problem > didn't exist in the past, I and others have used this functionality > regularly with the CRAN windows binary. > > ###### code starts ####### > require(MPTinR) > data(d.broeder) > m.2htm <- system.file("extdata", "5points.2htm.model", package = "MPTinR") > get.mpt.fia(d.broeder, m.2htm) > ###### code ends ####### > > The complete error message is: > > ###### error message starts ####### > Assertion failed! > > Program: C:\Program Files\RStudio\bin\x64\rsession.exe > File: d:/RCompile/CRANpkg/lib/3.1/RcppEigen/include/Eigen/src/Core/ProductBase.h, > Line 95 > > Expression: a_lhs.cols() == a_rhs.rows() && "invalid matrix product" && > "if you wanted a coeff-wise or a dot product use the respective explicit > functions" > > This application has requested the Runtime to terminate it in an unusual > way. > Please contact the application's support team for more information. > ###### error message ends ####### > > When adding such an example to the code and resubmitting it to winbuilder > it now also crashes, see http://win-builder.r-project. > org/0ei38q0t48h2/00check.log > But again, when installing the same package on my machine from source it > works. > > Best, > Henrik > > PS: A session info (without attaching MPTinR) is given below: > > R version 3.1.1 (2014-07-10) > Platform: x86_64-w64-mingw32/x64 (64-bit) > > locale: > [1] LC_COLLATE=German_Switzerland.1252 LC_CTYPE=German_Switzerland.1252 > LC_MONETARY=German_Switzerland.1252 > [4] LC_NUMERIC=C LC_TIME=German_Switzerland.1252 > > attached base packages: > [1] stats graphics grDevices utils datasets methods base > > other attached packages: > [1] devtools_1.6 > > loaded via a namespace (and not attached): > [1] fortunes_1.5-2 tools_3.1.1 > > > > -- > Dr. Henrik Singmann > Universit?t Z?rich, Schweiz > http://singmann.org > _______________________________________________ > Rcpp-devel mailing list > Rcpp-devel at lists.r-forge.r-project.org > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel -- Yixuan Qiu Department of Statistics, Purdue University -------------- next part -------------- An HTML attachment was scrubbed... URL: From henrik.singmann at psychologie.uni-freiburg.de Wed Oct 15 21:19:48 2014 From: henrik.singmann at psychologie.uni-freiburg.de (Henrik Singmann) Date: Wed, 15 Oct 2014 21:19:48 +0200 Subject: [Rcpp-devel] RcppEigen: Windows binary from CRAN crashes R, but not when installing from source. In-Reply-To: References: <543EC42F.1000001@psychologie.uni-freiburg.de> Message-ID: <543EC8D4.705@psychologie.uni-freiburg.de> Hi Yixuan, Unfortunately the problem seems to not be related to RStudio. It also appears in RGui. The error message is also different. Cheers, Henrik Am 15.10.2014 um 21:13 schrieb Yixuan Qiu: > Hi Henrik, > There seems to be a similar problem here in my package, reported by https://github.com/yixuan/rARPACK/issues/4. > The reporter said that the runtime error occured when using RStudio, but disappeared in RGui. Is this the same situation as yours? > > > Best, > Yixuan > > 2014-10-15 14:59 GMT-04:00 Henrik Singmann >: > > Dear list, > > I have the following weird problem and would be really glad for any input: > > The windows binary from CRAN for my package MPTinR, which uses RcppEigen, leads to an "Assertion failed" error which crashes R with a simple example given below (which unfortunately is not part of the examples and henceforth not tested by CRAN). > > Interestingly enough, the problem disappears when installing the package on Windows from source or when using Linux (Ubuntu). But it also appears when using a binary version of MPTinR from winbuilder (temporarily available here: http://win-builder.r-project.__org/h18PJ7B55VAq ), R-devel and corresponding binary from CRAN, and I could replicate the error on a range of different Windows machines. The error also always disappears when installing from source. I am also extremely confident that this problem didn't exist in the past, I and others have used this functionality regularly with the CRAN windows binary. > > ###### code starts ####### > require(MPTinR) > data(d.broeder) > m.2htm <- system.file("extdata", "5points.2htm.model", package = "MPTinR") > get.mpt.fia(d.broeder, m.2htm) > ###### code ends ####### > > The complete error message is: > > ###### error message starts ####### > Assertion failed! > > Program: C:\Program Files\RStudio\bin\x64\__rsession.exe > File: d:/RCompile/CRANpkg/lib/3.1/__RcppEigen/include/Eigen/src/__Core/ProductBase.h, Line 95 > > Expression: a_lhs.cols() == a_rhs.rows() && "invalid matrix product" && "if you wanted a coeff-wise or a dot product use the respective explicit functions" > > This application has requested the Runtime to terminate it in an unusual way. > Please contact the application's support team for more information. > ###### error message ends ####### > > When adding such an example to the code and resubmitting it to winbuilder it now also crashes, see http://win-builder.r-project.__org/0ei38q0t48h2/00check.log > But again, when installing the same package on my machine from source it works. > > Best, > Henrik > > PS: A session info (without attaching MPTinR) is given below: > > R version 3.1.1 (2014-07-10) > Platform: x86_64-w64-mingw32/x64 (64-bit) > > locale: > [1] LC_COLLATE=German_Switzerland.__1252 LC_CTYPE=German_Switzerland.__1252 LC_MONETARY=German___Switzerland.1252 > [4] LC_NUMERIC=C LC_TIME=German_Switzerland.__1252 > > attached base packages: > [1] stats graphics grDevices utils datasets methods base > > other attached packages: > [1] devtools_1.6 > > loaded via a namespace (and not attached): > [1] fortunes_1.5-2 tools_3.1.1 > > > > -- > Dr. Henrik Singmann > Universit?t Z?rich, Schweiz > http://singmann.org > _________________________________________________ > Rcpp-devel mailing list > Rcpp-devel-Z+qqJ2/841dDXCDGMXqaGg at public.gmane.org__project.org > https://lists.r-forge.r-__project.org/cgi-bin/mailman/__listinfo/rcpp-devel > > > > > -- > Yixuan Qiu > > Department of Statistics, > Purdue University > > > _______________________________________________ > Rcpp-devel mailing list > Rcpp-devel-Z+qqJ2/841dDXCDGMXqaGq2UG9VpUWMKQH7oEaQurus at public.gmane.org > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel > -- Dr. Henrik Singmann Universit?t Z?rich, Schweiz http://singmann.org From henrik.singmann at psychologie.uni-freiburg.de Wed Oct 15 21:30:26 2014 From: henrik.singmann at psychologie.uni-freiburg.de (Henrik Singmann) Date: Wed, 15 Oct 2014 21:30:26 +0200 Subject: [Rcpp-devel] RcppEigen: Windows binary from CRAN crashes R, but not when installing from source. In-Reply-To: <21566.51054.502184.443950@max.nulle.part> References: <543EC42F.1000001@psychologie.uni-freiburg.de> <21566.51054.502184.443950@max.nulle.part> Message-ID: <543ECB52.6010308@psychologie.uni-freiburg.de> Hi Dirk, I will try to produce a minimal reproducible example, but as I need to resort on winbuilder to crash it, this could take some time. Furthermore, not all inputs crash R, as shown in the example in the end. However, I am not sure how I contributed to the error since the C++ part of the package did run without problems for quite a while, the error only occurs with the binary from CRAN, and not all inputs show the error. Also, the code below did run with previous versions completely, but now the last part again crashes it on windows. An interesting additional observation could be that right now, compiling the package on windows using devtools::load_all() also produces the same error while installing the tar.gz of the same code from source does not trigger the error. Installing using devtools on windows also was never a problem for me. Very mysterious. Cheers, Henrik ### new example code ### require(MPTinR) data(d.broeder) m.2htm <- system.file("extdata", "5points.2htm.model", package = "MPTinR") i.2htm <- system.file("extdata", "broeder.2htm.ineq", package = "MPTinR") get.mpt.fia(d.broeder, m.2htm, i.2htm, Sample = 100) # works get.mpt.fia(d.broeder, m.2htm, Sample = 100) # crashes ### new example ends ### Am 15.10.2014 um 21:13 schrieb Dirk Eddelbuettel: > > Hi Henrik, > > On 15 October 2014 at 20:59, Henrik Singmann wrote: > | Dear list, > | > | I have the following weird problem and would be really glad for any input: > | > | The windows binary from CRAN for my package MPTinR, which uses RcppEigen, leads to an "Assertion failed" error which crashes R with a simple example given below (which unfortunately is not part of the examples and henceforth not tested by CRAN). > | > | Interestingly enough, the problem disappears when installing the package on Windows from source or when using Linux (Ubuntu). But it also appears when using a binary version of MPTinR from winbuilder (temporarily available here: http://win-builder.r-project.org/h18PJ7B55VAq), R-devel and corresponding binary from CRAN, and I could replicate the error on a range of different Windows machines. The error also always disappears when installing from source. I am also extremely confident that this problem didn't exist in the past, I and others have used this functionality regularly with the CRAN windows binary. > | > | ###### code starts ####### > | require(MPTinR) > | data(d.broeder) > | m.2htm <- system.file("extdata", "5points.2htm.model", package = "MPTinR") > | get.mpt.fia(d.broeder, m.2htm) > | ###### code ends ####### > | > | The complete error message is: > | > | ###### error message starts ####### > | Assertion failed! > | > | Program: C:\Program Files\RStudio\bin\x64\rsession.exe > | File: d:/RCompile/CRANpkg/lib/3.1/RcppEigen/include/Eigen/src/Core/ProductBase.h, Line 95 > | > | Expression: a_lhs.cols() == a_rhs.rows() && "invalid matrix product" && "if you wanted a coeff-wise or a dot product use the respective explicit functions" > | > | This application has requested the Runtime to terminate it in an unusual way. > | Please contact the application's support team for more information. > | ###### error message ends ####### > | > | When adding such an example to the code and resubmitting it to winbuilder it now also crashes, see http://win-builder.r-project.org/0ei38q0t48h2/00check.log > | But again, when installing the same package on my machine from source it works. > > It would help us if you could create a minimally reproducible example exhibit > this behaviour. > > About 24 CRAN packages use RcppEigen. The error could be yours, or ours. But > given the information provided so far it is hard to say more. > > You could also try R along with valgrind on Linux to see if that tickles it. > > Dirk > > > | Best, > | Henrik > | > | PS: A session info (without attaching MPTinR) is given below: > | > | R version 3.1.1 (2014-07-10) > | Platform: x86_64-w64-mingw32/x64 (64-bit) > | > | locale: > | [1] LC_COLLATE=German_Switzerland.1252 LC_CTYPE=German_Switzerland.1252 LC_MONETARY=German_Switzerland.1252 > | [4] LC_NUMERIC=C LC_TIME=German_Switzerland.1252 > | > | attached base packages: > | [1] stats graphics grDevices utils datasets methods base > | > | other attached packages: > | [1] devtools_1.6 > | > | loaded via a namespace (and not attached): > | [1] fortunes_1.5-2 tools_3.1.1 > | > | > | > | -- > | Dr. Henrik Singmann > | Universit?t Z?rich, Schweiz > | http://singmann.org > | _______________________________________________ > | Rcpp-devel mailing list > | Rcpp-devel-Z+qqJ2/841dDXCDGMXqaGq2UG9VpUWMKQH7oEaQurus at public.gmane.org > | https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel > -- Dr. Henrik Singmann Universit?t Z?rich, Schweiz http://singmann.org From henrik.singmann at psychologie.uni-freiburg.de Wed Oct 15 23:15:34 2014 From: henrik.singmann at psychologie.uni-freiburg.de (Henrik Singmann) Date: Wed, 15 Oct 2014 23:15:34 +0200 Subject: [Rcpp-devel] RcppEigen: Windows binary from CRAN crashes R, but not when installing from source. In-Reply-To: <21566.51054.502184.443950@max.nulle.part> References: <543EC42F.1000001@psychologie.uni-freiburg.de> <21566.51054.502184.443950@max.nulle.part> Message-ID: <543EE3F6.20907@psychologie.uni-freiburg.de> Hi Dirk and list, I have now managed to isolate the problem. The cpp file posted below can on both Windows and Linux crash R if (a) compiled by winbuilder (windows only) or if build via devtools::load_all() or from within Rstudio ("Build & Reload") and (b) when using the appropriate input. The following input crashes R: S <- 3 Ineq <- structure(0, .Dim = c(1L, 1L)) But this input is okay: S <- 3 Ineq <- structure(c(-1, 1, 0), .Dim = c(1L, 3L)) The c++ function producing the problem is (where SS = S and ineq = Ineq): #### code follows ###### SEXP determinant2( SEXP SS, SEXP ineq){ BEGIN_RCPP using namespace Rcpp; using Eigen::Map; using Eigen::VectorXd; using Eigen::RowVectorXd; using Eigen::MatrixXd; const int S = Rcpp::as(SS); const Map Ineq(as >(ineq)); RNGScope scope; VectorXd thetaTMP; RowVectorXd theta; VectorXd IneqT; thetaTMP = Rcpp::as(rbeta(S, 0.5, 0.5)); theta = thetaTMP.transpose(); IneqT = (theta*Ineq.transpose()); return wrap(0); END_RCPP } #### code ends ###### I have build a package which contains nothing but this code and two functions trigger() and no_trigger() the former of which crashes R and the latter does not crash R. The package can be found here: http://singmann.org/download/teaching/r/MPTbug_1.0.0.tar.gz But as I said, when installing from source, the two functions work. Only when using the binary from winbuilder or building via devtools or RStudio does trigger() crash R. The winbuilder version can be found here (temporarily): http://win-builder.r-project.org/M4yLs8R7tFR1/ The problem obviously seems to be (theta*Ineq.transpose()) if Ineq is a scalar 0. But why it works given one compilation and not the other is outside of my knowledge space. Any help would obviously be really appreciated. Cheers, Henrik Am 15.10.2014 um 21:13 schrieb Dirk Eddelbuettel: > > Hi Henrik, > > On 15 October 2014 at 20:59, Henrik Singmann wrote: > | Dear list, > | > | I have the following weird problem and would be really glad for any input: > | > | The windows binary from CRAN for my package MPTinR, which uses RcppEigen, leads to an "Assertion failed" error which crashes R with a simple example given below (which unfortunately is not part of the examples and henceforth not tested by CRAN). > | > | Interestingly enough, the problem disappears when installing the package on Windows from source or when using Linux (Ubuntu). But it also appears when using a binary version of MPTinR from winbuilder (temporarily available here: http://win-builder.r-project.org/h18PJ7B55VAq), R-devel and corresponding binary from CRAN, and I could replicate the error on a range of different Windows machines. The error also always disappears when installing from source. I am also extremely confident that this problem didn't exist in the past, I and others have used this functionality regularly with the CRAN windows binary. > | > | ###### code starts ####### > | require(MPTinR) > | data(d.broeder) > | m.2htm <- system.file("extdata", "5points.2htm.model", package = "MPTinR") > | get.mpt.fia(d.broeder, m.2htm) > | ###### code ends ####### > | > | The complete error message is: > | > | ###### error message starts ####### > | Assertion failed! > | > | Program: C:\Program Files\RStudio\bin\x64\rsession.exe > | File: d:/RCompile/CRANpkg/lib/3.1/RcppEigen/include/Eigen/src/Core/ProductBase.h, Line 95 > | > | Expression: a_lhs.cols() == a_rhs.rows() && "invalid matrix product" && "if you wanted a coeff-wise or a dot product use the respective explicit functions" > | > | This application has requested the Runtime to terminate it in an unusual way. > | Please contact the application's support team for more information. > | ###### error message ends ####### > | > | When adding such an example to the code and resubmitting it to winbuilder it now also crashes, see http://win-builder.r-project.org/0ei38q0t48h2/00check.log > | But again, when installing the same package on my machine from source it works. > > It would help us if you could create a minimally reproducible example exhibit > this behaviour. > > About 24 CRAN packages use RcppEigen. The error could be yours, or ours. But > given the information provided so far it is hard to say more. > > You could also try R along with valgrind on Linux to see if that tickles it. > > Dirk > > > | Best, > | Henrik > | > | PS: A session info (without attaching MPTinR) is given below: > | > | R version 3.1.1 (2014-07-10) > | Platform: x86_64-w64-mingw32/x64 (64-bit) > | > | locale: > | [1] LC_COLLATE=German_Switzerland.1252 LC_CTYPE=German_Switzerland.1252 LC_MONETARY=German_Switzerland.1252 > | [4] LC_NUMERIC=C LC_TIME=German_Switzerland.1252 > | > | attached base packages: > | [1] stats graphics grDevices utils datasets methods base > | > | other attached packages: > | [1] devtools_1.6 > | > | loaded via a namespace (and not attached): > | [1] fortunes_1.5-2 tools_3.1.1 > | > | > | > | -- > | Dr. Henrik Singmann > | Universit?t Z?rich, Schweiz > | http://singmann.org > | _______________________________________________ > | Rcpp-devel mailing list > | Rcpp-devel-Z+qqJ2/841dDXCDGMXqaGq2UG9VpUWMKQH7oEaQurus at public.gmane.org > | https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel > -- Dr. Henrik Singmann Universit?t Z?rich, Schweiz http://singmann.org From edd at debian.org Wed Oct 15 23:56:48 2014 From: edd at debian.org (Dirk Eddelbuettel) Date: Wed, 15 Oct 2014 16:56:48 -0500 Subject: [Rcpp-devel] RcppEigen: Windows binary from CRAN crashes R, but not when installing from source. In-Reply-To: <543EE3F6.20907@psychologie.uni-freiburg.de> References: <543EC42F.1000001@psychologie.uni-freiburg.de> <21566.51054.502184.443950@max.nulle.part> <543EE3F6.20907@psychologie.uni-freiburg.de> Message-ID: <21566.60832.364379.708073@max.nulle.part> (Resending, corrected headers) Henrik, The list address is rcpp-devel at r-forge.wu-wien.ac.at Would you mind using that? The gmane redirector messes up automated filtering. Thank you! Moreover, it also seems to have swallowed my reply. Please do not create extra work for us. Thanks. On 15 October 2014 at 23:15, Henrik Singmann wrote: |=20 |=20 | Hi Dirk and list, |=20 | I have now managed to isolate the problem. The cpp file posted below = can on both Windows and Linux crash R if (a) compiled by winbuilder (wi= ndows only) or if build via devtools::load_all() or from within Rstudio= ("Build & Reload") and (b) when using the appropriate input. |=20 | The following input crashes R: | S <- 3 | Ineq <- structure(0, .Dim =3D c(1L, 1L)) | =20 | But this input is okay: | S <- 3 | Ineq <- structure(c(-1, 1, 0), .Dim =3D c(1L, 3L)) |=20 | =20 | The c++ function producing the problem is (where SS =3D S and ineq =3D= Ineq): |=20 | #### code follows ###### |=20 | SEXP determinant2( SEXP SS, SEXP ineq){ | BEGIN_RCPP I *strongly* recommend you look into the Rcpp Attributes vignette, and the hundreds of examples in the list archive and on, say, the Rcpp Gallery, and use an an interface such as // [[Rcpp::export]] Rcpp::NumericMatrix foo(Rcpp::NumericMatrix a, Rcpp::NumericMatrix n) { ... (and I used base Rcpp for simplicity, RcppEigen works the same way). We had several cases where manual use of RNGScope gets in the way. That may not be the use, but it makes it easier for everybody to play along --- if you use the same format we all use. Otherwise -- thanks, and I'll try to take a look later. Dirk PS Your example is not self-contained. What arguments do you supply to determinant2 ? -- http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org From henrik.singmann at psychologie.uni-freiburg.de Thu Oct 16 00:13:06 2014 From: henrik.singmann at psychologie.uni-freiburg.de (Henrik Singmann) Date: Thu, 16 Oct 2014 00:13:06 +0200 Subject: [Rcpp-devel] RcppEigen: Windows binary from CRAN crashes R, but not when installing from source. In-Reply-To: References: <543EC42F.1000001@psychologie.uni-freiburg.de> <21566.51054.502184.443950@max.nulle.part> <543EE3F6.20907@psychologie.uni-freiburg.de> Message-ID: <543EF172.7080108@psychologie.uni-freiburg.de> Hi Kevin, The easiest way for me to reproduce the issue on Linux was to upload the zip file containing the R package folder plus the .Rproj file onto my Rstudio Server. This zip file can be found here: http://singmann.org/download/teaching/r/mptmin.zip There I opened a new R script, and entered the following lines to crash R: require(devtools) load_all(recompile = TRUE) no_trigger() trigger() I just retried it and reliably crashed my RStudio Server. Thanks a lot, Henrik Am 15.10.2014 um 23:53 schrieb Kevin Ushey: > Hi Henrik, > > Thanks for putting this together. FWIW, I cannot reproduce this error > (either with `trigger()` or `no_trigger()`) on OS X, nor when building > from source on a Windows VM (while inside RStudio). > > I also tried running the address and undefined behavior sanitizers > when executing the code and nothing was picked up. > > Can you post the compiler output you get when using > `devtools::load_all()` vs. a regular `R CMD INSTALL` ? I wonder if the > compile flags are somehow different and if that could lead to a > problem. > > Can you also elaborate on how you can reproduce this on Linux? This is > the environment we're most familiar with and so if we can reproduce > there then we can most easily discover a solution. I wonder if using > `gctorture(TRUE)` before running `trigger()` would make the assertion > failure more likely. > > Thanks, > Kevin > > > > On Wed, Oct 15, 2014 at 2:15 PM, Henrik Singmann > wrote: >> >> Hi Dirk and list, >> >> I have now managed to isolate the problem. The cpp file posted below can on >> both Windows and Linux crash R if (a) compiled by winbuilder (windows only) >> or if build via devtools::load_all() or from within Rstudio ("Build & >> Reload") and (b) when using the appropriate input. >> >> The following input crashes R: >> S <- 3 >> Ineq <- structure(0, .Dim = c(1L, 1L)) >> But this input is okay: >> S <- 3 >> Ineq <- structure(c(-1, 1, 0), .Dim = c(1L, 3L)) >> >> The c++ function producing the problem is (where SS = S and ineq = Ineq): >> >> #### code follows ###### >> >> SEXP determinant2( SEXP SS, SEXP ineq){ >> BEGIN_RCPP >> >> using namespace Rcpp; >> using Eigen::Map; >> using Eigen::VectorXd; >> using Eigen::RowVectorXd; >> using Eigen::MatrixXd; >> const int S = Rcpp::as(SS); >> const Map Ineq(as >(ineq)); >> >> RNGScope scope; >> >> VectorXd thetaTMP; >> RowVectorXd theta; >> VectorXd IneqT; >> >> thetaTMP = Rcpp::as(rbeta(S, 0.5, 0.5)); >> theta = thetaTMP.transpose(); >> >> IneqT = (theta*Ineq.transpose()); >> return wrap(0); >> >> END_RCPP >> } >> >> #### code ends ###### >> >> I have build a package which contains nothing but this code and two >> functions trigger() and no_trigger() the former of which crashes R and the >> latter does not crash R. The package can be found here: >> http://singmann.org/download/teaching/r/MPTbug_1.0.0.tar.gz >> But as I said, when installing from source, the two functions work. Only >> when using the binary from winbuilder or building via devtools or RStudio >> does trigger() crash R. The winbuilder version can be found here >> (temporarily): http://win-builder.r-project.org/M4yLs8R7tFR1/ >> >> The problem obviously seems to be (theta*Ineq.transpose()) if Ineq is a >> scalar 0. But why it works given one compilation and not the other is >> outside of my knowledge space. Any help would obviously be really >> appreciated. >> >> Cheers, >> Henrik >> >> Am 15.10.2014 um 21:13 schrieb Dirk Eddelbuettel: >>> >>> Hi Henrik, >>> >>> On 15 October 2014 at 20:59, Henrik Singmann wrote: >>> | Dear list, >>> | >>> | I have the following weird problem and would be really glad for any >>> input: >>> | >>> | The windows binary from CRAN for my package MPTinR, which uses >>> RcppEigen, leads to an "Assertion failed" error which crashes R with a >>> simple example given below (which unfortunately is not part of the examples >>> and henceforth not tested by CRAN). >>> | >>> | Interestingly enough, the problem disappears when installing the package >>> on Windows from source or when using Linux (Ubuntu). But it also appears >>> when using a binary version of MPTinR from winbuilder (temporarily available >>> here: http://win-builder.r-project.org/h18PJ7B55VAq), R-devel and >>> corresponding binary from CRAN, and I could replicate the error on a range >>> of different Windows machines. The error also always disappears when >>> installing from source. I am also extremely confident that this problem >>> didn't exist in the past, I and others have used this functionality >>> regularly with the CRAN windows binary. >>> | >>> | ###### code starts ####### >>> | require(MPTinR) >>> | data(d.broeder) >>> | m.2htm <- system.file("extdata", "5points.2htm.model", package = >>> "MPTinR") >>> | get.mpt.fia(d.broeder, m.2htm) >>> | ###### code ends ####### >>> | >>> | The complete error message is: >>> | >>> | ###### error message starts ####### >>> | Assertion failed! >>> | >>> | Program: C:\Program Files\RStudio\bin\x64\rsession.exe >>> | File: >>> d:/RCompile/CRANpkg/lib/3.1/RcppEigen/include/Eigen/src/Core/ProductBase.h, >>> Line 95 >>> | >>> | Expression: a_lhs.cols() == a_rhs.rows() && "invalid matrix product" && >>> "if you wanted a coeff-wise or a dot product use the respective explicit >>> functions" >>> | >>> | This application has requested the Runtime to terminate it in an unusual >>> way. >>> | Please contact the application's support team for more information. >>> | ###### error message ends ####### >>> | >>> | When adding such an example to the code and resubmitting it to >>> winbuilder it now also crashes, see >>> http://win-builder.r-project.org/0ei38q0t48h2/00check.log >>> | But again, when installing the same package on my machine from source it >>> works. >>> >>> It would help us if you could create a minimally reproducible example >>> exhibit >>> this behaviour. >>> >>> About 24 CRAN packages use RcppEigen. The error could be yours, or ours. >>> But >>> given the information provided so far it is hard to say more. >>> >>> You could also try R along with valgrind on Linux to see if that tickles >>> it. >>> >>> Dirk >>> >>> >>> | Best, >>> | Henrik >>> | >>> | PS: A session info (without attaching MPTinR) is given below: >>> | >>> | R version 3.1.1 (2014-07-10) >>> | Platform: x86_64-w64-mingw32/x64 (64-bit) >>> | >>> | locale: >>> | [1] LC_COLLATE=German_Switzerland.1252 LC_CTYPE=German_Switzerland.1252 >>> LC_MONETARY=German_Switzerland.1252 >>> | [4] LC_NUMERIC=C LC_TIME=German_Switzerland.1252 >>> | >>> | attached base packages: >>> | [1] stats graphics grDevices utils datasets methods base >>> | >>> | other attached packages: >>> | [1] devtools_1.6 >>> | >>> | loaded via a namespace (and not attached): >>> | [1] fortunes_1.5-2 tools_3.1.1 >>> | >>> | >>> | >>> | -- >>> | Dr. Henrik Singmann >>> | Universit?t Z?rich, Schweiz >>> | http://singmann.org >>> | _______________________________________________ >>> | Rcpp-devel mailing list >>> | Rcpp-devel-Z+qqJ2/841dDXCDGMXqaGq2UG9VpUWMKQH7oEaQurus at public.gmane.org >>> | https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel >>> >> -- >> Dr. Henrik Singmann >> Universit?t Z?rich, Schweiz >> http://singmann.org >> >> _______________________________________________ >> Rcpp-devel mailing list >> Rcpp-devel at lists.r-forge.r-project.org >> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel -- Dr. Henrik Singmann PostDoc Universit?t Z?rich, Schweiz http://singmann.org From henrik.singmann at psychologie.uni-freiburg.de Thu Oct 16 00:16:33 2014 From: henrik.singmann at psychologie.uni-freiburg.de (Henrik Singmann) Date: Thu, 16 Oct 2014 00:16:33 +0200 Subject: [Rcpp-devel] RcppEigen: Windows binary from CRAN crashes R, but not when installing from source. In-Reply-To: <21566.60832.364379.708073@max.nulle.part> References: <543EC42F.1000001@psychologie.uni-freiburg.de> <21566.51054.502184.443950@max.nulle.part> <543EE3F6.20907@psychologie.uni-freiburg.de> <21566.60832.364379.708073@max.nulle.part> Message-ID: <543EF241.8070807@psychologie.uni-freiburg.de> Hi Dirk, I am sorry for using the wrong address, it will not happen again. Furthermore, I think that back in the day when I programmed my code the interface I used was the recommended one (at least this is what I thought it was). It was right around the time when the paper in JStatSoft from Doug Bates and you came out and I tried to strongly follow the recommendations and used the RcppEigen package skeleton. If the interface has changed meanwhile, I will do my very best to update it and will look into the vignettes. Thanks for the pointer, Henrik Am 15.10.2014 um 23:56 schrieb Dirk Eddelbuettel: > (Resending, corrected headers) > > Henrik, > > The list address is rcpp-devel at r-forge.wu-wien.ac.at Would you mind > using that? The gmane redirector messes up automated filtering. Thank you! > > Moreover, it also seems to have swallowed my reply. Please do not create > extra work for us. Thanks. > > On 15 October 2014 at 23:15, Henrik Singmann wrote: > |=20 > |=20 > | Hi Dirk and list, > |=20 > | I have now managed to isolate the problem. The cpp file posted below = > can on both Windows and Linux crash R if (a) compiled by winbuilder (wi= > ndows only) or if build via devtools::load_all() or from within Rstudio= > ("Build & Reload") and (b) when using the appropriate input. > |=20 > | The following input crashes R: > | S <- 3 > | Ineq <- structure(0, .Dim =3D c(1L, 1L)) > | =20 > | But this input is okay: > | S <- 3 > | Ineq <- structure(c(-1, 1, 0), .Dim =3D c(1L, 3L)) > |=20 > | =20 > | The c++ function producing the problem is (where SS =3D S and ineq =3D= > Ineq): > |=20 > | #### code follows ###### > |=20 > | SEXP determinant2( SEXP SS, SEXP ineq){ > | BEGIN_RCPP > > I *strongly* recommend you look into the Rcpp Attributes vignette, and > the hundreds of examples in the list archive and on, say, the Rcpp Gallery, > and use an an interface such as > > // [[Rcpp::export]] > Rcpp::NumericMatrix foo(Rcpp::NumericMatrix a, Rcpp::NumericMatrix n) { ... > > (and I used base Rcpp for simplicity, RcppEigen works the same way). > > We had several cases where manual use of RNGScope gets in the way. That may > not be the use, but it makes it easier for everybody to play along --- if you > use the same format we all use. > > Otherwise -- thanks, and I'll try to take a look later. > > Dirk > > PS Your example is not self-contained. What arguments do you supply to > determinant2 ? > > -- Dr. Henrik Singmann PostDoc Universit?t Z?rich, Schweiz http://singmann.org From jbuonagurio at exponent.com Thu Oct 16 00:43:07 2014 From: jbuonagurio at exponent.com (John Buonagurio) Date: Wed, 15 Oct 2014 22:43:07 +0000 Subject: [Rcpp-devel] RcppEigen: Windows binary from CRAN crashes R, but not when installing from source. In-Reply-To: <543EF172.7080108@psychologie.uni-freiburg.de> References: <543EC42F.1000001@psychologie.uni-freiburg.de> <21566.51054.502184.443950@max.nulle.part> <543EE3F6.20907@psychologie.uni-freiburg.de> <543EF172.7080108@psychologie.uni-freiburg.de> Message-ID: <00F9E64B563E7C45818C85C1B7FCC726A777CDAE@SFMB02.exponent.com> Hi Henrik, R CMD INSTALL defines the NDEBUG macro (as Writing R Extensions sec. 1.7 recommends), which disables eigen_assert. Otherwise your error is triggered here: eigen_assert(a_lhs.cols() == a_rhs.rows() && "invalid matrix product" && "if you wanted a coeff-wise or a dot product use the respective explicit functions"); Looks like it's complaining that you're trying to transpose a scalar. win-builder doesn't add -DNDEBUG. You can just #undef NDEBUG and it will build, but I'd leave asserts on during development to avoid any unexpected behavior. Trimmed the rest of this message as I'm having problems with a new mail filter at work... John > -----Original Message----- > From: rcpp-devel-bounces at lists.r-forge.r-project.org [mailto:rcpp-devel- > bounces at lists.r-forge.r-project.org] On Behalf Of Henrik Singmann > Sent: Wednesday, October 15, 2014 6:13 PM > To: Kevin Ushey > Cc: rcpp-devel at r-forge.wu-wien.ac.at > Subject: Re: [Rcpp-devel] RcppEigen: Windows binary from CRAN crashes R, but > not when installing from source. From edd at debian.org Thu Oct 16 00:19:47 2014 From: edd at debian.org (Dirk Eddelbuettel) Date: Wed, 15 Oct 2014 17:19:47 -0500 Subject: [Rcpp-devel] RcppEigen: Windows binary from CRAN crashes R, but not when installing from source. In-Reply-To: References: <543EC42F.1000001@psychologie.uni-freiburg.de> <21566.51054.502184.443950@max.nulle.part> <543EE3F6.20907@psychologie.uni-freiburg.de> Message-ID: <21566.62211.262507.47211@max.nulle.part> (Headers once more corrected) On 15 October 2014 at 14:53, Kevin Ushey wrote: | | | | Hi Henrik, | | Thanks for putting this together. FWIW, I cannot reproduce this error | (either with `trigger()` or `no_trigger()`) on OS X, nor when building | from source on a Windows VM (while inside RStudio). | | I also tried running the address and undefined behavior sanitizers | when executing the code and nothing was picked up. | | Can you post the compiler output you get when using | `devtools::load_all()` vs. a regular `R CMD INSTALL` ? I wonder if the | compile flags are somehow different and if that could lead to a | problem. | | Can you also elaborate on how you can reproduce this on Linux? This is | the environment we're most familiar with and so if we can reproduce | there then we can most easily discover a solution. I wonder if using | `gctorture(TRUE)` before running `trigger()` would make the assertion | failure more likely. I second Kevin's comments. I have an outstanding request with Dortmund for something regarding another package where I also suspect a configuration issue; this may be as trivial as the Windows binary there being out of sync. Your code seems fine. Below is how I would write it, in a self-contained short snippet you can just 'sourceCpp()' and which will even executed the short R portion making it truly reproducible and self-contained. It shows no issue. This may be a one-off related to win-builder. Thanks, Dirk #include using namespace Rcpp; using Eigen::Map; using Eigen::VectorXd; using Eigen::RowVectorXd; using Eigen::MatrixXd; // [[Rcpp::depends(RcppEigen)]] // [[Rcpp::export]] int determinant2(int S, Map Ineq) { VectorXd thetaTMP = Rcpp::as(rbeta(S, 0.5, 0.5)); RowVectorXd theta = thetaTMP.transpose(); VectorXd IneqT = (theta*Ineq.transpose()); return 0; } /*** R determinant2(2, matrix(1.0*(1:4),2,2)) */ -- http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org From henrik.singmann at psychologie.uni-freiburg.de Thu Oct 16 15:07:24 2014 From: henrik.singmann at psychologie.uni-freiburg.de (Henrik Singmann) Date: Thu, 16 Oct 2014 15:07:24 +0200 Subject: [Rcpp-devel] RcppEigen: Windows binary from CRAN crashes R, but not when installing from source. In-Reply-To: <21566.62211.262507.47211@max.nulle.part> References: <543EC42F.1000001@psychologie.uni-freiburg.de> <21566.51054.502184.443950@max.nulle.part> <543EE3F6.20907@psychologie.uni-freiburg.de> <21566.62211.262507.47211@max.nulle.part> Message-ID: <543FC30C.6090306@psychologie.uni-freiburg.de> Hi Dirk and Kevin, I have now rebuild the package using the code Dirk send me (i.e., using attributes) and the code still reliably crashes my R on Linux when using devtools (independent of RStudio), but not when installing via install.packages. When just using the code Dirk had send directly (i.e., outside a package) this does not happen. Note that I had to minimally change the code Dirk had sent as I couldn't manage to use "using Eigen::" so had to preface every call to Eigen functions or structures with "Eigen::". Following are the exact steps needed to crash R from a Linux console: Thanks a lot, Henrik ####################### # get the package: wget http://singmann.org/download/teaching/r/MPTbug_1.0.0.tar.gz tar -zxvf MPTbug_1.0.0.tar.gz # I first use devtools to build and then crash R: cd MPTbug R require(devtools) load_all(recompile = TRUE) trigger() #this crashes R, error message is given below, but the same as before. ### Compiling messages: Loading MPTbug Re-compiling MPTbug '/usr/lib64/R/bin/R' --vanilla CMD INSTALL '/home/singmann/MPTbug' \ --library='/tmp/Rtmp3vi8kf' --no-R --no-data --no-help --no-demo --no-inst \ --no-docs --no-exec --no-multiarch --no-test-load --preclean * installing *source* package ?MPTbug? ... ** libs g++ -m64 -I/usr/include/R -DNDEBUG -I. -I../inst/include -I/usr/local/include -I"/home/singmann/R/x86_64-redhat-linux-gnu-library/3.1/Rcpp/include" -I"/home/singmann/R/x86_64-redhat-linux-gnu-library/3.1/RcppEigen/include" -UNDEBUG -Wall -pedantic -g -O0 -fpic -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -flto -c RcppExports.cpp -o RcppExports.o In file included from /home/singmann/R/x86_64-redhat-linux-gnu-library/3.1/RcppEigen/include/Eigen/Cholesky:24:0, from /home/singmann/R/x86_64-redhat-linux-gnu-library/3.1/RcppEigen/include/Eigen/Dense:3, from /home/singmann/R/x86_64-redhat-linux-gnu-library/3.1/RcppEigen/include/RcppEigenForward.h:30, from /home/singmann/R/x86_64-redhat-linux-gnu-library/3.1/RcppEigen/include/RcppEigen.h:25, from RcppExports.cpp:4: /home/singmann/R/x86_64-redhat-linux-gnu-library/3.1/RcppEigen/include/Eigen/src/Cholesky/LDLT.h: In member function ?void Eigen::internal::solve_retval, Rhs>::evalTo(Dest&) const?: /home/singmann/R/x86_64-redhat-linux-gnu-library/3.1/RcppEigen/include/Eigen/src/Cholesky/LDLT.h:505:39: warning: typedef ?Scalar? locally defined but not used [-Wunused-local-typedefs] typedef typename LDLTType::Scalar Scalar; ^ g++ -m64 -I/usr/include/R -DNDEBUG -I. -I../inst/include -I/usr/local/include -I"/home/singmann/R/x86_64-redhat-linux-gnu-library/3.1/Rcpp/include" -I"/home/singmann/R/x86_64-redhat-linux-gnu-library/3.1/RcppEigen/include" -UNDEBUG -Wall -pedantic -g -O0 -fpic -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -flto -c determinant2.cpp -o determinant2.o In file included from /home/singmann/R/x86_64-redhat-linux-gnu-library/3.1/RcppEigen/include/Eigen/Cholesky:24:0, from /home/singmann/R/x86_64-redhat-linux-gnu-library/3.1/RcppEigen/include/Eigen/Dense:3, from /home/singmann/R/x86_64-redhat-linux-gnu-library/3.1/RcppEigen/include/RcppEigenForward.h:30, from /home/singmann/R/x86_64-redhat-linux-gnu-library/3.1/RcppEigen/include/RcppEigen.h:25, from determinant2.cpp:1: /home/singmann/R/x86_64-redhat-linux-gnu-library/3.1/RcppEigen/include/Eigen/src/Cholesky/LDLT.h: In member function ?void Eigen::internal::solve_retval, Rhs>::evalTo(Dest&) const?: /home/singmann/R/x86_64-redhat-linux-gnu-library/3.1/RcppEigen/include/Eigen/src/Cholesky/LDLT.h:505:39: warning: typedef ?Scalar? locally defined but not used [-Wunused-local-typedefs] typedef typename LDLTType::Scalar Scalar; ^ g++ -m64 -shared -Wl,-z,relro -o MPTbug.so RcppExports.o determinant2.o -L/usr/lib64/R/lib -lR installing to /tmp/Rtmp3vi8kf/MPTbug/libs * DONE (MPTbug) ### Error message (which is the same as from winbuilder/CRAN binary): > trigger() R: /home/singmann/R/x86_64-redhat-linux-gnu-library/3.1/RcppEigen/include/Eigen/src/Core/ProductBase.h:95: Eigen::ProductBase::ProductBase(const Lhs&, const Rhs&) [with Derived = Eigen::GeneralProduct, Eigen::Transpose > >, 4>; Lhs = Eigen::Matrix; Rhs = Eigen::Transpose > >]: Assertion `a_lhs.cols() == a_rhs.rows() && "invalid matrix product" && "if you wanted a coeff-wise or a dot product use the respective explicit functions"' failed. Aborted (core dumped) #### However, when installing from the source package, everything works. See following code and compiler messages. cd .. R install.packages("MPTbug_1.0.0.tar.gz", repos = NULL) require(MPTbug) trigger() #### compiler: > install.packages("MPTbug_1.0.0.tar.gz", repos = NULL) Installing package into ?/home/singmann/R/x86_64-redhat-linux-gnu-library/3.1? (as ?lib? is unspecified) * installing *source* package ?MPTbug? ... ** libs g++ -m64 -I/usr/include/R -DNDEBUG -I. -I../inst/include -I/usr/local/include -I"/home/singmann/R/x86_64-redhat-linux-gnu-library/3.1/Rcpp/include" -I"/home/singmann/R/x86_64-redhat-linux-gnu-library/3.1/RcppEigen/include" -fpic -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -flto -c RcppExports.cpp -o RcppExports.o In file included from /home/singmann/R/x86_64-redhat-linux-gnu-library/3.1/RcppEigen/include/Eigen/Cholesky:24:0, from /home/singmann/R/x86_64-redhat-linux-gnu-library/3.1/RcppEigen/include/Eigen/Dense:3, from /home/singmann/R/x86_64-redhat-linux-gnu-library/3.1/RcppEigen/include/RcppEigenForward.h:30, from /home/singmann/R/x86_64-redhat-linux-gnu-library/3.1/RcppEigen/include/RcppEigen.h:25, from RcppExports.cpp:4: /home/singmann/R/x86_64-redhat-linux-gnu-library/3.1/RcppEigen/include/Eigen/src/Cholesky/LDLT.h: In member function ?void Eigen::internal::solve_retval, Rhs>::evalTo(Dest&) const?: /home/singmann/R/x86_64-redhat-linux-gnu-library/3.1/RcppEigen/include/Eigen/src/Cholesky/LDLT.h:505:39: warning: typedef ?Scalar? locally defined but not used [-Wunused-local-typedefs] typedef typename LDLTType::Scalar Scalar; ^ g++ -m64 -I/usr/include/R -DNDEBUG -I. -I../inst/include -I/usr/local/include -I"/home/singmann/R/x86_64-redhat-linux-gnu-library/3.1/Rcpp/include" -I"/home/singmann/R/x86_64-redhat-linux-gnu-library/3.1/RcppEigen/include" -fpic -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -flto -c determinant2.cpp -o determinant2.o In file included from /home/singmann/R/x86_64-redhat-linux-gnu-library/3.1/RcppEigen/include/Eigen/Cholesky:24:0, from /home/singmann/R/x86_64-redhat-linux-gnu-library/3.1/RcppEigen/include/Eigen/Dense:3, from /home/singmann/R/x86_64-redhat-linux-gnu-library/3.1/RcppEigen/include/RcppEigenForward.h:30, from /home/singmann/R/x86_64-redhat-linux-gnu-library/3.1/RcppEigen/include/RcppEigen.h:25, from determinant2.cpp:1: /home/singmann/R/x86_64-redhat-linux-gnu-library/3.1/RcppEigen/include/Eigen/src/Cholesky/LDLT.h: In member function ?void Eigen::internal::solve_retval, Rhs>::evalTo(Dest&) const?: /home/singmann/R/x86_64-redhat-linux-gnu-library/3.1/RcppEigen/include/Eigen/src/Cholesky/LDLT.h:505:39: warning: typedef ?Scalar? locally defined but not used [-Wunused-local-typedefs] typedef typename LDLTType::Scalar Scalar; ^ g++ -m64 -shared -Wl,-z,relro -o MPTbug.so RcppExports.o determinant2.o -L/usr/lib64/R/lib -lR installing to /home/singmann/R/x86_64-redhat-linux-gnu-library/3.1/MPTbug/libs ** R ** byte-compile and prepare package for lazy loading ** help *** installing help indices converting help for package ?MPTbug? finding HTML links ... done trigger html ** building package indices ** testing if installed package can be loaded * DONE (MPTbug) Am 16.10.2014 um 00:19 schrieb Dirk Eddelbuettel: > (Headers once more corrected) > > On 15 October 2014 at 14:53, Kevin Ushey wrote: > | > | > | > | Hi Henrik, > | > | Thanks for putting this together. FWIW, I cannot reproduce this error > | (either with `trigger()` or `no_trigger()`) on OS X, nor when building > | from source on a Windows VM (while inside RStudio). > | > | I also tried running the address and undefined behavior sanitizers > | when executing the code and nothing was picked up. > | > | Can you post the compiler output you get when using > | `devtools::load_all()` vs. a regular `R CMD INSTALL` ? I wonder if the > | compile flags are somehow different and if that could lead to a > | problem. > | > | Can you also elaborate on how you can reproduce this on Linux? This is > | the environment we're most familiar with and so if we can reproduce > | there then we can most easily discover a solution. I wonder if using > | `gctorture(TRUE)` before running `trigger()` would make the assertion > | failure more likely. > > I second Kevin's comments. I have an outstanding request with Dortmund for > something regarding another package where I also suspect a configuration > issue; this may be as trivial as the Windows binary there being out of sync. > > Your code seems fine. Below is how I would write it, in a self-contained > short snippet you can just 'sourceCpp()' and which will even executed the > short R portion making it truly reproducible and self-contained. > > It shows no issue. This may be a one-off related to win-builder. > > Thanks, Dirk > > > > #include > > using namespace Rcpp; > > using Eigen::Map; > using Eigen::VectorXd; > using Eigen::RowVectorXd; > using Eigen::MatrixXd; > > // [[Rcpp::depends(RcppEigen)]] > > // [[Rcpp::export]] > int determinant2(int S, Map Ineq) { > > VectorXd thetaTMP = Rcpp::as(rbeta(S, 0.5, 0.5)); > RowVectorXd theta = thetaTMP.transpose(); > > VectorXd IneqT = (theta*Ineq.transpose()); > > return 0; > } > > /*** R > determinant2(2, matrix(1.0*(1:4),2,2)) > */ > > -- Dr. Henrik Singmann PostDoc Universit?t Z?rich, Schweiz http://singmann.org From edd at debian.org Thu Oct 16 15:35:18 2014 From: edd at debian.org (Dirk Eddelbuettel) Date: Thu, 16 Oct 2014 08:35:18 -0500 Subject: [Rcpp-devel] RcppEigen: Windows binary from CRAN crashes R, but not when installing from source. In-Reply-To: <543FC30C.6090306@psychologie.uni-freiburg.de> References: <543EC42F.1000001@psychologie.uni-freiburg.de> <21566.51054.502184.443950@max.nulle.part> <543EE3F6.20907@psychologie.uni-freiburg.de> <21566.62211.262507.47211@max.nulle.part> <543FC30C.6090306@psychologie.uni-freiburg.de> Message-ID: <21567.51606.784535.536005@max.nulle.part> On 16 October 2014 at 15:07, Henrik Singmann wrote: | Hi Dirk and Kevin, | | I have now rebuild the package using the code Dirk send me (i.e., using attributes) and the code still reliably crashes my R on Linux when using devtools (independent of RStudio), but not when installing via install.packages. When just using the code Dirk had send directly (i.e., outside a package) this does not happen. Please take that up with the devtools maintainer. I do not use devtools. It is not part of what we asked for: __a minimally reproducible example__ | Note that I had to minimally change the code Dirk had sent as I couldn't manage to use "using Eigen::" so had to preface every call to Eigen functions or structures with "Eigen::". Here is my counter example. Ubuntu 14.04. Everything current. Save the following a file "henrik.cpp" ----------------------------------------------------------------------------- #include using namespace Rcpp; using Eigen::Map; using Eigen::VectorXd; using Eigen::RowVectorXd; using Eigen::MatrixXd; // [[Rcpp::depends(RcppEigen)]] // The following is __identical__ to mptmin::src/determinant.cpp // but at the same time much, much shorter and more readable // // The following 'tag' ensure determinant2() is accessible from R // // [[Rcpp::export]] int determinant2(int S, Map Ineq) { VectorXd thetaTMP = Rcpp::as(rbeta(S, 0.5, 0.5)); RowVectorXd theta = thetaTMP.transpose(); VectorXd IneqT = (theta*Ineq.transpose()); return 0; } /*** R # the following is equivalent to mptmin::R/minimal.cpp # but shorter and easier; also removed the leading dot oneSample2 <- function(Sx, Ineq) { #.Call("determinant2", Sx, Ineq, PACKAGE = "MPTbug") determinant2(Sx, Ineq) } # the dimensions are of course incompatible so this is user error trigger <- function() { S <- 3 # why would you create a matrix via structure() ? Ineq <- structure(0, .Dim = c(1L, 1L)) #error oneSample2(Sx = S, Ineq = Ineq) } no_trigger <- function() { S <- 3 Ineq <- structure(c(-1, 1, 0), .Dim = c(1L, 3L)) # no error oneSample2(Sx = S, Ineq = Ineq) } no_trigger() # no issue trigger() # no issue either */ ----------------------------------------------------------------------------- In an R session, issue the following command sourceCpp("filename.cpp") with the name (plus optional path) to the file above. Here is what I get in a fresh session: ----------------------------------------------------------------------------- R> Rcpp::sourceCpp("~/Dropbox/tmp/henrik.cpp") R> # the following is equivalent to mptmin::R/minimal.cpp R> # but shorter and easier; also removed the leading dot R> oneSample2 <- function(Sx, In .... [TRUNCATED] R> # the dimensions are of course incompatible so this is user error R> trigger <- function() { + S <- 3 + # why would you create a matrix via str .... [TRUNCATED] R> no_trigger <- function() { + S <- 3 + Ineq <- structure(c(-1, 1, 0), .Dim = c(1L, 3L)) # no error + oneSample2(Sx = S, Ineq = Ineq) + } R> no_trigger() # no issue [1] 0 R> trigger() # no issue either [1] 0 R> ----------------------------------------------------------------------------- I consider this issue closed because __there is still no minimal reproducible bug__. There is what we could call a user error. Or if you wish a design error. You simply cannot multiply non-conformant vectors. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org From edd at debian.org Thu Oct 16 16:04:08 2014 From: edd at debian.org (Dirk Eddelbuettel) Date: Thu, 16 Oct 2014 09:04:08 -0500 Subject: [Rcpp-devel] RcppEigen: Windows binary from CRAN crashes R, but not when installing from source. In-Reply-To: <21567.51606.784535.536005@max.nulle.part> References: <543EC42F.1000001@psychologie.uni-freiburg.de> <21566.51054.502184.443950@max.nulle.part> <543EE3F6.20907@psychologie.uni-freiburg.de> <21566.62211.262507.47211@max.nulle.part> <543FC30C.6090306@psychologie.uni-freiburg.de> <21567.51606.784535.536005@max.nulle.part> Message-ID: <21567.53336.38384.338507@max.nulle.part> On 16 October 2014 at 08:35, Dirk Eddelbuettel wrote: | | | On 16 October 2014 at 15:07, Henrik Singmann wrote: | | Hi Dirk and Kevin, | | | | I have now rebuild the package using the code Dirk send me (i.e., using attributes) and the code still reliably crashes my R on Linux when using devtools (independent of RStudio), but not when installing via install.packages. When just using the code Dirk had send directly (i.e., outside a package) this does not happen. | | Please take that up with the devtools maintainer. I do not use devtools. And FWIW he used confirmed over IM that devtools sets NDEBUG. So there -- devtools issues, not an Rcpp or RcppEigen issue. Dirk | It is not part of what we asked for: __a minimally reproducible example__ | | | Note that I had to minimally change the code Dirk had sent as I couldn't manage to use "using Eigen::" so had to preface every call to Eigen functions or structures with "Eigen::". | | Here is my counter example. Ubuntu 14.04. Everything current. | | Save the following a file "henrik.cpp" | | ----------------------------------------------------------------------------- | | #include | | using namespace Rcpp; | | using Eigen::Map; | using Eigen::VectorXd; | using Eigen::RowVectorXd; | using Eigen::MatrixXd; | | // [[Rcpp::depends(RcppEigen)]] | | // The following is __identical__ to mptmin::src/determinant.cpp | // but at the same time much, much shorter and more readable | // | // The following 'tag' ensure determinant2() is accessible from R | // | // [[Rcpp::export]] | int determinant2(int S, Map Ineq) { | | VectorXd thetaTMP = Rcpp::as(rbeta(S, 0.5, 0.5)); | RowVectorXd theta = thetaTMP.transpose(); | | VectorXd IneqT = (theta*Ineq.transpose()); | | return 0; | } | | /*** R | | # the following is equivalent to mptmin::R/minimal.cpp | # but shorter and easier; also removed the leading dot | oneSample2 <- function(Sx, Ineq) { | #.Call("determinant2", Sx, Ineq, PACKAGE = "MPTbug") | determinant2(Sx, Ineq) | } | | # the dimensions are of course incompatible so this is user error | trigger <- function() { | S <- 3 | # why would you create a matrix via structure() ? | Ineq <- structure(0, .Dim = c(1L, 1L)) #error | oneSample2(Sx = S, Ineq = Ineq) | } | | no_trigger <- function() { | S <- 3 | Ineq <- structure(c(-1, 1, 0), .Dim = c(1L, 3L)) # no error | oneSample2(Sx = S, Ineq = Ineq) | } | | no_trigger() # no issue | trigger() # no issue either | */ | | ----------------------------------------------------------------------------- | | | In an R session, issue the following command sourceCpp("filename.cpp") with | the name (plus optional path) to the file above. Here is what I get in a | fresh session: | | ----------------------------------------------------------------------------- | R> Rcpp::sourceCpp("~/Dropbox/tmp/henrik.cpp") | | R> # the following is equivalent to mptmin::R/minimal.cpp | R> # but shorter and easier; also removed the leading dot | R> oneSample2 <- function(Sx, In .... [TRUNCATED] | | R> # the dimensions are of course incompatible so this is user error | R> trigger <- function() { | + S <- 3 | + # why would you create a matrix via str .... [TRUNCATED] | | R> no_trigger <- function() { | + S <- 3 | + Ineq <- structure(c(-1, 1, 0), .Dim = c(1L, 3L)) # no error | + oneSample2(Sx = S, Ineq = Ineq) | + } | | R> no_trigger() # no issue | [1] 0 | | R> trigger() # no issue either | [1] 0 | R> | ----------------------------------------------------------------------------- | | I consider this issue closed because __there is still no minimal reproducible | bug__. | | There is what we could call a user error. Or if you wish a design error. You | simply cannot multiply non-conformant vectors. | | Dirk | | | | | | | | -- | http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org -- http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org From henrik.singmann at psychologie.uni-freiburg.de Thu Oct 16 16:39:14 2014 From: henrik.singmann at psychologie.uni-freiburg.de (Henrik Singmann) Date: Thu, 16 Oct 2014 16:39:14 +0200 Subject: [Rcpp-devel] RcppEigen: Windows binary from CRAN crashes R, but not when installing from source. In-Reply-To: <21567.53336.38384.338507@max.nulle.part> References: <543EC42F.1000001@psychologie.uni-freiburg.de> <21566.51054.502184.443950@max.nulle.part> <543EE3F6.20907@psychologie.uni-freiburg.de> <21566.62211.262507.47211@max.nulle.part> <543FC30C.6090306@psychologie.uni-freiburg.de> <21567.51606.784535.536005@max.nulle.part> <21567.53336.38384.338507@max.nulle.part> Message-ID: <543FD892.70803@psychologie.uni-freiburg.de> Hi Dirk, I am sorry to address this again, as I am in no position to argue, but the problem is still the following: The code runs perfectly as your example showed but will fail when using either devtools or winbuilder or CRAN when *inside a package*. The problem of producing a minimally reproducible example of your liking is that either of those conditions cannot be met: I need the package to reproduce it. I also agree that it is an issue of multiplying non-conformable vectors. But as can be easily shown using the code you had sent, when compiling it on owns own (i.e., not using the conditions reproducing the crash described above) this only leads to a result of 0. However, when using the binary from either of the above it crashes R with an assertion error. It is also important to note that this did not happen in the past. So I probably just need to set the correct compiler flags or disable DNDEBUG or such a thing, but I did not manage to do this in such a way to prohibit the crash under the above described circumstances. I would really like to receive any advice on how to avoid this crash (assertion error) when using the binary compiled on CRAN, this is in the end the critical issue. *How can I disable the assertion error compiling in my code?* Just adding "#undef NDEBUG" at the beginning didn't work. On an unrelated note, the issue of within package or outside of a package also concerns the question of "using Eigen::..." versus prefacing all calls to Eigen parts with Eigen:: directly. While the code you had sent works great when using sourceCpp(), I didn't manage to get it to work in a package (even after wildly using compileAttributes). I had to replace all calls of e.g., VectorXd with Eigen::VectorXd. Is there a trick of how to do this inside a package? Btw, I agree that using the RcppAttributes is great. I hadn't used it, because, you know, "never touch a running system." But as it failed now, it is perhaps time for a change. Thanks again, Henrik Am 16.10.2014 um 16:04 schrieb Dirk Eddelbuettel: > On 16 October 2014 at 08:35, Dirk Eddelbuettel wrote: > | > | > | On 16 October 2014 at 15:07, Henrik Singmann wrote: > | | Hi Dirk and Kevin, > | | > | | I have now rebuild the package using the code Dirk send me (i.e., using attributes) and the code still reliably crashes my R on Linux when using devtools (independent of RStudio), but not when installing via install.packages. When just using the code Dirk had send directly (i.e., outside a package) this does not happen. > | > | Please take that up with the devtools maintainer. I do not use devtools. > > And FWIW he used confirmed over IM that devtools sets NDEBUG. So there -- > devtools issues, not an Rcpp or RcppEigen issue. > > Dirk > > | It is not part of what we asked for: __a minimally reproducible example__ > | > | | Note that I had to minimally change the code Dirk had sent as I couldn't manage to use "using Eigen::" so had to preface every call to Eigen functions or structures with "Eigen::". > | > | Here is my counter example. Ubuntu 14.04. Everything current. > | > | Save the following a file "henrik.cpp" > | > | ----------------------------------------------------------------------------- > | > | #include > | > | using namespace Rcpp; > | > | using Eigen::Map; > | using Eigen::VectorXd; > | using Eigen::RowVectorXd; > | using Eigen::MatrixXd; > | > | // [[Rcpp::depends(RcppEigen)]] > | > | // The following is __identical__ to mptmin::src/determinant.cpp > | // but at the same time much, much shorter and more readable > | // > | // The following 'tag' ensure determinant2() is accessible from R > | // > | // [[Rcpp::export]] > | int determinant2(int S, Map Ineq) { > | > | VectorXd thetaTMP = Rcpp::as(rbeta(S, 0.5, 0.5)); > | RowVectorXd theta = thetaTMP.transpose(); > | > | VectorXd IneqT = (theta*Ineq.transpose()); > | > | return 0; > | } > | > | /*** R > | > | # the following is equivalent to mptmin::R/minimal.cpp > | # but shorter and easier; also removed the leading dot > | oneSample2 <- function(Sx, Ineq) { > | #.Call("determinant2", Sx, Ineq, PACKAGE = "MPTbug") > | determinant2(Sx, Ineq) > | } > | > | # the dimensions are of course incompatible so this is user error > | trigger <- function() { > | S <- 3 > | # why would you create a matrix via structure() ? > | Ineq <- structure(0, .Dim = c(1L, 1L)) #error > | oneSample2(Sx = S, Ineq = Ineq) > | } > | > | no_trigger <- function() { > | S <- 3 > | Ineq <- structure(c(-1, 1, 0), .Dim = c(1L, 3L)) # no error > | oneSample2(Sx = S, Ineq = Ineq) > | } > | > | no_trigger() # no issue > | trigger() # no issue either > | */ > | > | ----------------------------------------------------------------------------- > | > | > | In an R session, issue the following command sourceCpp("filename.cpp") with > | the name (plus optional path) to the file above. Here is what I get in a > | fresh session: > | > | ----------------------------------------------------------------------------- > | R> Rcpp::sourceCpp("~/Dropbox/tmp/henrik.cpp") > | > | R> # the following is equivalent to mptmin::R/minimal.cpp > | R> # but shorter and easier; also removed the leading dot > | R> oneSample2 <- function(Sx, In .... [TRUNCATED] > | > | R> # the dimensions are of course incompatible so this is user error > | R> trigger <- function() { > | + S <- 3 > | + # why would you create a matrix via str .... [TRUNCATED] > | > | R> no_trigger <- function() { > | + S <- 3 > | + Ineq <- structure(c(-1, 1, 0), .Dim = c(1L, 3L)) # no error > | + oneSample2(Sx = S, Ineq = Ineq) > | + } > | > | R> no_trigger() # no issue > | [1] 0 > | > | R> trigger() # no issue either > | [1] 0 > | R> > | ----------------------------------------------------------------------------- > | > | I consider this issue closed because __there is still no minimal reproducible > | bug__. > | > | There is what we could call a user error. Or if you wish a design error. You > | simply cannot multiply non-conformant vectors. > | > | Dirk > | > | > | > | > | > | > | > | -- > | http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org > -- Dr. Henrik Singmann PostDoc Universit?t Z?rich, Schweiz http://singmann.org From edd at debian.org Thu Oct 16 17:02:47 2014 From: edd at debian.org (Dirk Eddelbuettel) Date: Thu, 16 Oct 2014 10:02:47 -0500 Subject: [Rcpp-devel] RcppEigen: Windows binary from CRAN crashes R, but not when installing from source. In-Reply-To: <543FD892.70803@psychologie.uni-freiburg.de> References: <543EC42F.1000001@psychologie.uni-freiburg.de> <21566.51054.502184.443950@max.nulle.part> <543EE3F6.20907@psychologie.uni-freiburg.de> <21566.62211.262507.47211@max.nulle.part> <543FC30C.6090306@psychologie.uni-freiburg.de> <21567.51606.784535.536005@max.nulle.part> <21567.53336.38384.338507@max.nulle.part> <543FD892.70803@psychologie.uni-freiburg.de> Message-ID: <21567.56855.326699.85943@max.nulle.part> Hi Henrik, On 16 October 2014 at 16:39, Henrik Singmann wrote: | Hi Dirk, | | I am sorry to address this again, as I am in no position to argue, but the problem is still the following: I understand your frustration, but please consider: | The code runs perfectly as your example showed but will fail when using | either devtools or winbuilder or CRAN when *inside a package*. 1) I don't stand behind devtools or winbuilder 2) A package "is still just code" compiled a certain way. You should try to distill where there difference between what works and what wasn't. At the bottom of these things, there must be a difference. | The problem of producing a minimally reproducible example of your liking is that either of those conditions cannot be met: I need the package to reproduce it. Try comparing __all compiler flags and settings__ between the way you build. | I also agree that it is an issue of multiplying non-conformable vectors. But as can be easily shown using the code you had sent, when compiling it on owns own (i.e., not using the conditions reproducing the crash described above) this only leads to a result of 0. However, when using the binary from either of the above it crashes R with an assertion error. | It is also important to note that this did not happen in the past. | | So I probably just need to set the correct compiler flags or disable DNDEBUG or such a thing, but I did not manage to do this in such a way to prohibit the crash under the above described circumstances. | I would really like to receive any advice on how to avoid this crash (assertion error) when using the binary compiled on CRAN, this is in the end the critical issue. *How can I disable the assertion error compiling in my code?* Just adding "#undef NDEBUG" at the beginning didn't work. | | | On an unrelated note, the issue of within package or outside of a package also concerns the question of "using Eigen::..." versus prefacing all calls to Eigen parts with Eigen:: directly. | While the code you had sent works great when using sourceCpp(), I didn't manage to get it to work in a package (even after wildly using compileAttributes). I had to replace all calls of e.g., VectorXd with Eigen::VectorXd. Is there a trick of how to do this inside a package? Try looking at the two dozen CRAN packages using RcppEigen. I am more of an RcppArmadillo user myself. | Btw, I agree that using the RcppAttributes is great. I hadn't used it, because, you know, "never touch a running system." But as it failed now, it is perhaps time for a change. :) Change is sometimes hard, and often takes some effort. But at times it is worth it too. Dirk | Thanks again, | Henrik | | | Am 16.10.2014 um 16:04 schrieb Dirk Eddelbuettel: | > On 16 October 2014 at 08:35, Dirk Eddelbuettel wrote: | > | | > | | > | On 16 October 2014 at 15:07, Henrik Singmann wrote: | > | | Hi Dirk and Kevin, | > | | | > | | I have now rebuild the package using the code Dirk send me (i.e., using attributes) and the code still reliably crashes my R on Linux when using devtools (independent of RStudio), but not when installing via install.packages. When just using the code Dirk had send directly (i.e., outside a package) this does not happen. | > | | > | Please take that up with the devtools maintainer. I do not use devtools. | > | > And FWIW he used confirmed over IM that devtools sets NDEBUG. So there -- | > devtools issues, not an Rcpp or RcppEigen issue. | > | > Dirk | > | > | It is not part of what we asked for: __a minimally reproducible example__ | > | | > | | Note that I had to minimally change the code Dirk had sent as I couldn't manage to use "using Eigen::" so had to preface every call to Eigen functions or structures with "Eigen::". | > | | > | Here is my counter example. Ubuntu 14.04. Everything current. | > | | > | Save the following a file "henrik.cpp" | > | | > | ----------------------------------------------------------------------------- | > | | > | #include | > | | > | using namespace Rcpp; | > | | > | using Eigen::Map; | > | using Eigen::VectorXd; | > | using Eigen::RowVectorXd; | > | using Eigen::MatrixXd; | > | | > | // [[Rcpp::depends(RcppEigen)]] | > | | > | // The following is __identical__ to mptmin::src/determinant.cpp | > | // but at the same time much, much shorter and more readable | > | // | > | // The following 'tag' ensure determinant2() is accessible from R | > | // | > | // [[Rcpp::export]] | > | int determinant2(int S, Map Ineq) { | > | | > | VectorXd thetaTMP = Rcpp::as(rbeta(S, 0.5, 0.5)); | > | RowVectorXd theta = thetaTMP.transpose(); | > | | > | VectorXd IneqT = (theta*Ineq.transpose()); | > | | > | return 0; | > | } | > | | > | /*** R | > | | > | # the following is equivalent to mptmin::R/minimal.cpp | > | # but shorter and easier; also removed the leading dot | > | oneSample2 <- function(Sx, Ineq) { | > | #.Call("determinant2", Sx, Ineq, PACKAGE = "MPTbug") | > | determinant2(Sx, Ineq) | > | } | > | | > | # the dimensions are of course incompatible so this is user error | > | trigger <- function() { | > | S <- 3 | > | # why would you create a matrix via structure() ? | > | Ineq <- structure(0, .Dim = c(1L, 1L)) #error | > | oneSample2(Sx = S, Ineq = Ineq) | > | } | > | | > | no_trigger <- function() { | > | S <- 3 | > | Ineq <- structure(c(-1, 1, 0), .Dim = c(1L, 3L)) # no error | > | oneSample2(Sx = S, Ineq = Ineq) | > | } | > | | > | no_trigger() # no issue | > | trigger() # no issue either | > | */ | > | | > | ----------------------------------------------------------------------------- | > | | > | | > | In an R session, issue the following command sourceCpp("filename.cpp") with | > | the name (plus optional path) to the file above. Here is what I get in a | > | fresh session: | > | | > | ----------------------------------------------------------------------------- | > | R> Rcpp::sourceCpp("~/Dropbox/tmp/henrik.cpp") | > | | > | R> # the following is equivalent to mptmin::R/minimal.cpp | > | R> # but shorter and easier; also removed the leading dot | > | R> oneSample2 <- function(Sx, In .... [TRUNCATED] | > | | > | R> # the dimensions are of course incompatible so this is user error | > | R> trigger <- function() { | > | + S <- 3 | > | + # why would you create a matrix via str .... [TRUNCATED] | > | | > | R> no_trigger <- function() { | > | + S <- 3 | > | + Ineq <- structure(c(-1, 1, 0), .Dim = c(1L, 3L)) # no error | > | + oneSample2(Sx = S, Ineq = Ineq) | > | + } | > | | > | R> no_trigger() # no issue | > | [1] 0 | > | | > | R> trigger() # no issue either | > | [1] 0 | > | R> | > | ----------------------------------------------------------------------------- | > | | > | I consider this issue closed because __there is still no minimal reproducible | > | bug__. | > | | > | There is what we could call a user error. Or if you wish a design error. You | > | simply cannot multiply non-conformant vectors. | > | | > | Dirk | > | | > | | > | | > | | > | | > | | > | | > | -- | > | http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org | > | | -- | Dr. Henrik Singmann | PostDoc | Universit?t Z?rich, Schweiz | http://singmann.org -- http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org From jbuonagurio at exponent.com Thu Oct 16 17:58:08 2014 From: jbuonagurio at exponent.com (John Buonagurio) Date: Thu, 16 Oct 2014 15:58:08 +0000 Subject: [Rcpp-devel] RcppEigen: Windows binary from CRAN crashes R, but not when installing from source. In-Reply-To: <543FD892.70803@psychologie.uni-freiburg.de> References: <543EC42F.1000001@psychologie.uni-freiburg.de> <21566.51054.502184.443950@max.nulle.part> <543EE3F6.20907@psychologie.uni-freiburg.de> <21566.62211.262507.47211@max.nulle.part> <543FC30C.6090306@psychologie.uni-freiburg.de> <21567.51606.784535.536005@max.nulle.part> <21567.53336.38384.338507@max.nulle.part> <543FD892.70803@psychologie.uni-freiburg.de> Message-ID: <00F9E64B563E7C45818C85C1B7FCC726A777D2A8@SFMB02.exponent.com> Hi Henrik, You can just add #define EIGEN_NO_DEBUG to make it clear that you want to specifically disable Eigen assertions, without relying on what sets or does not set the DNDEBUG flag. It's in the Eigen documentation: http://eigen.tuxfamily.org/dox/TopicPreprocessorDirectives.html John > -----Original Message----- > From: rcpp-devel-bounces at lists.r-forge.r-project.org [mailto:rcpp-devel- > bounces at lists.r-forge.r-project.org] On Behalf Of Henrik Singmann > Sent: Thursday, October 16, 2014 10:39 AM > To: Dirk Eddelbuettel > Cc: rcpp-devel at r-forge.wu-wien.ac.at > Subject: Re: [Rcpp-devel] RcppEigen: Windows binary from CRAN crashes R, but > not when installing from source. > > > Hi Dirk, > > I am sorry to address this again, as I am in no position to argue, but the problem > is still the following: > The code runs perfectly as your example showed but will fail when using either > devtools or winbuilder or CRAN when *inside a package*. The problem of > producing a minimally reproducible example of your liking is that either of those > conditions cannot be met: I need the package to reproduce it. > > I also agree that it is an issue of multiplying non-conformable vectors. But as can > be easily shown using the code you had sent, when compiling it on owns own > (i.e., not using the conditions reproducing the crash described above) this only > leads to a result of 0. However, when using the binary from either of the above > it crashes R with an assertion error. > It is also important to note that this did not happen in the past. > > So I probably just need to set the correct compiler flags or disable DNDEBUG or > such a thing, but I did not manage to do this in such a way to prohibit the crash > under the above described circumstances. > I would really like to receive any advice on how to avoid this crash (assertion > error) when using the binary compiled on CRAN, this is in the end the critical > issue. *How can I disable the assertion error compiling in my code?* Just adding > "#undef NDEBUG" at the beginning didn't work. > > > On an unrelated note, the issue of within package or outside of a package also > concerns the question of "using Eigen::..." versus prefacing all calls to Eigen > parts with Eigen:: directly. > While the code you had sent works great when using sourceCpp(), I didn't > manage to get it to work in a package (even after wildly using > compileAttributes). I had to replace all calls of e.g., VectorXd with > Eigen::VectorXd. Is there a trick of how to do this inside a package? > > Btw, I agree that using the RcppAttributes is great. I hadn't used it, because, you > know, "never touch a running system." But as it failed now, it is perhaps time for > a change. > > Thanks again, > Henrik > > > Am 16.10.2014 um 16:04 schrieb Dirk Eddelbuettel: > > On 16 October 2014 at 08:35, Dirk Eddelbuettel wrote: > > | > > | > > | On 16 October 2014 at 15:07, Henrik Singmann wrote: > > | | Hi Dirk and Kevin, > > | | > > | | I have now rebuild the package using the code Dirk send me (i.e., using > attributes) and the code still reliably crashes my R on Linux when using devtools > (independent of RStudio), but not when installing via install.packages. When just > using the code Dirk had send directly (i.e., outside a package) this does not > happen. > > | > > | Please take that up with the devtools maintainer. I do not use devtools. > > > > And FWIW he used confirmed over IM that devtools sets NDEBUG. So > > there -- devtools issues, not an Rcpp or RcppEigen issue. > > > > Dirk > > > > | It is not part of what we asked for: __a minimally reproducible > > | example__ > > | > > | | Note that I had to minimally change the code Dirk had sent as I couldn't > manage to use "using Eigen::" so had to preface every call to Eigen functions or > structures with "Eigen::". > > | > > | Here is my counter example. Ubuntu 14.04. Everything current. > > | > > | Save the following a file "henrik.cpp" > > | > > | -------------------------------------------------------------------- > > | --------- > > | > > | #include > > | > > | using namespace Rcpp; > > | > > | using Eigen::Map; > > | using Eigen::VectorXd; > > | using Eigen::RowVectorXd; > > | using Eigen::MatrixXd; > > | > > | // [[Rcpp::depends(RcppEigen)]] > > | > > | // The following is __identical__ to mptmin::src/determinant.cpp // > > | but at the same time much, much shorter and more readable // // The > > | following 'tag' ensure determinant2() is accessible from R // // > > | [[Rcpp::export]] int determinant2(int S, Map Ineq) { > > | > > | VectorXd thetaTMP = Rcpp::as(rbeta(S, 0.5, 0.5)); > > | RowVectorXd theta = thetaTMP.transpose(); > > | > > | VectorXd IneqT = (theta*Ineq.transpose()); > > | > > | return 0; > > | } > > | > > | /*** R > > | > > | # the following is equivalent to mptmin::R/minimal.cpp # but shorter > > | and easier; also removed the leading dot > > | oneSample2 <- function(Sx, Ineq) { > > | #.Call("determinant2", Sx, Ineq, PACKAGE = "MPTbug") > > | determinant2(Sx, Ineq) > > | } > > | > > | # the dimensions are of course incompatible so this is user error > > | trigger <- function() { > > | S <- 3 > > | # why would you create a matrix via structure() ? > > | Ineq <- structure(0, .Dim = c(1L, 1L)) #error > > | oneSample2(Sx = S, Ineq = Ineq) > > | } > > | > > | no_trigger <- function() { > > | S <- 3 > > | Ineq <- structure(c(-1, 1, 0), .Dim = c(1L, 3L)) # no error > > | oneSample2(Sx = S, Ineq = Ineq) > > | } > > | > > | no_trigger() # no issue > > | trigger() # no issue either > > | */ > > | > > | -------------------------------------------------------------------- > > | --------- > > | > > | > > | In an R session, issue the following command > > | sourceCpp("filename.cpp") with the name (plus optional path) to the > > | file above. Here is what I get in a fresh session: > > | > > | -------------------------------------------------------------------- > > | --------- > > | R> Rcpp::sourceCpp("~/Dropbox/tmp/henrik.cpp") > > | > > | R> # the following is equivalent to mptmin::R/minimal.cpp # but > > | R> shorter and easier; also removed the leading dot > > | R> oneSample2 <- function(Sx, In .... [TRUNCATED] > > | > > | R> # the dimensions are of course incompatible so this is user error > > | R> trigger <- function() { > > | + S <- 3 > > | + # why would you create a matrix via str .... [TRUNCATED] > > | > > | R> no_trigger <- function() { > > | + S <- 3 > > | + Ineq <- structure(c(-1, 1, 0), .Dim = c(1L, 3L)) # no error > > | + oneSample2(Sx = S, Ineq = Ineq) > > | + } > > | > > | R> no_trigger() # no issue > > | [1] 0 > > | > > | R> trigger() # no issue either > > | [1] 0 > > | R> > > | -------------------------------------------------------------------- > > | --------- > > | > > | I consider this issue closed because __there is still no minimal > > | reproducible bug__. > > | > > | There is what we could call a user error. Or if you wish a design > > | error. You simply cannot multiply non-conformant vectors. > > | > > | Dirk From kevinushey at gmail.com Thu Oct 16 18:35:07 2014 From: kevinushey at gmail.com (Kevin Ushey) Date: Thu, 16 Oct 2014 09:35:07 -0700 Subject: [Rcpp-devel] RcppEigen: Windows binary from CRAN crashes R, but not when installing from source. In-Reply-To: <00F9E64B563E7C45818C85C1B7FCC726A777D2A8@SFMB02.exponent.com> References: <543EC42F.1000001@psychologie.uni-freiburg.de> <21566.51054.502184.443950@max.nulle.part> <543EE3F6.20907@psychologie.uni-freiburg.de> <21566.62211.262507.47211@max.nulle.part> <543FC30C.6090306@psychologie.uni-freiburg.de> <21567.51606.784535.536005@max.nulle.part> <21567.53336.38384.338507@max.nulle.part> <543FD892.70803@psychologie.uni-freiburg.de> <00F9E64B563E7C45818C85C1B7FCC726A777D2A8@SFMB02.exponent.com> Message-ID: I think John's advice is spot on here. The issue is only seen when `NDEBUG` is not defined. I can reproduce the crash (assertion failure) by ensuring I have CXXFLAGS=-UNDEBUG in my ~/.R/Makevars. Note that: 1. An assertion failure from Eigen implies you are doing something that you should not be doing, and 2. R by default sets -DNDEBUG whenever compiling by default, so I am surprised that you are not seeing it (does your package have a custom Makefile / Makevars or something to that effect? Or do you have your own custom Makevars somewhere?) Anyway, let's assume Eigen is right -- this means you're multiplying two non-conforming matrices, and hence your matrix product is undefined. Which makes sense, since you're now trying to multiply two non-conforming matrices. And if you want a scalar * matrix multiplication then you need to be using a different function. Note that this is exactly what Eigen's assertion was telling you here! On Thu, Oct 16, 2014 at 8:58 AM, John Buonagurio wrote: > Hi Henrik, > > You can just add #define EIGEN_NO_DEBUG to make it clear that you want to specifically disable Eigen assertions, without relying on what sets or does not set the DNDEBUG flag. It's in the Eigen documentation: > > http://eigen.tuxfamily.org/dox/TopicPreprocessorDirectives.html > > John > >> -----Original Message----- >> From: rcpp-devel-bounces at lists.r-forge.r-project.org [mailto:rcpp-devel- >> bounces at lists.r-forge.r-project.org] On Behalf Of Henrik Singmann >> Sent: Thursday, October 16, 2014 10:39 AM >> To: Dirk Eddelbuettel >> Cc: rcpp-devel at r-forge.wu-wien.ac.at >> Subject: Re: [Rcpp-devel] RcppEigen: Windows binary from CRAN crashes R, but >> not when installing from source. >> >> >> Hi Dirk, >> >> I am sorry to address this again, as I am in no position to argue, but the problem >> is still the following: >> The code runs perfectly as your example showed but will fail when using either >> devtools or winbuilder or CRAN when *inside a package*. The problem of >> producing a minimally reproducible example of your liking is that either of those >> conditions cannot be met: I need the package to reproduce it. >> >> I also agree that it is an issue of multiplying non-conformable vectors. But as can >> be easily shown using the code you had sent, when compiling it on owns own >> (i.e., not using the conditions reproducing the crash described above) this only >> leads to a result of 0. However, when using the binary from either of the above >> it crashes R with an assertion error. >> It is also important to note that this did not happen in the past. >> >> So I probably just need to set the correct compiler flags or disable DNDEBUG or >> such a thing, but I did not manage to do this in such a way to prohibit the crash >> under the above described circumstances. >> I would really like to receive any advice on how to avoid this crash (assertion >> error) when using the binary compiled on CRAN, this is in the end the critical >> issue. *How can I disable the assertion error compiling in my code?* Just adding >> "#undef NDEBUG" at the beginning didn't work. >> >> >> On an unrelated note, the issue of within package or outside of a package also >> concerns the question of "using Eigen::..." versus prefacing all calls to Eigen >> parts with Eigen:: directly. >> While the code you had sent works great when using sourceCpp(), I didn't >> manage to get it to work in a package (even after wildly using >> compileAttributes). I had to replace all calls of e.g., VectorXd with >> Eigen::VectorXd. Is there a trick of how to do this inside a package? >> >> Btw, I agree that using the RcppAttributes is great. I hadn't used it, because, you >> know, "never touch a running system." But as it failed now, it is perhaps time for >> a change. >> >> Thanks again, >> Henrik >> >> >> Am 16.10.2014 um 16:04 schrieb Dirk Eddelbuettel: >> > On 16 October 2014 at 08:35, Dirk Eddelbuettel wrote: >> > | >> > | >> > | On 16 October 2014 at 15:07, Henrik Singmann wrote: >> > | | Hi Dirk and Kevin, >> > | | >> > | | I have now rebuild the package using the code Dirk send me (i.e., using >> attributes) and the code still reliably crashes my R on Linux when using devtools >> (independent of RStudio), but not when installing via install.packages. When just >> using the code Dirk had send directly (i.e., outside a package) this does not >> happen. >> > | >> > | Please take that up with the devtools maintainer. I do not use devtools. >> > >> > And FWIW he used confirmed over IM that devtools sets NDEBUG. So >> > there -- devtools issues, not an Rcpp or RcppEigen issue. >> > >> > Dirk >> > >> > | It is not part of what we asked for: __a minimally reproducible >> > | example__ >> > | >> > | | Note that I had to minimally change the code Dirk had sent as I couldn't >> manage to use "using Eigen::" so had to preface every call to Eigen functions or >> structures with "Eigen::". >> > | >> > | Here is my counter example. Ubuntu 14.04. Everything current. >> > | >> > | Save the following a file "henrik.cpp" >> > | >> > | -------------------------------------------------------------------- >> > | --------- >> > | >> > | #include >> > | >> > | using namespace Rcpp; >> > | >> > | using Eigen::Map; >> > | using Eigen::VectorXd; >> > | using Eigen::RowVectorXd; >> > | using Eigen::MatrixXd; >> > | >> > | // [[Rcpp::depends(RcppEigen)]] >> > | >> > | // The following is __identical__ to mptmin::src/determinant.cpp // >> > | but at the same time much, much shorter and more readable // // The >> > | following 'tag' ensure determinant2() is accessible from R // // >> > | [[Rcpp::export]] int determinant2(int S, Map Ineq) { >> > | >> > | VectorXd thetaTMP = Rcpp::as(rbeta(S, 0.5, 0.5)); >> > | RowVectorXd theta = thetaTMP.transpose(); >> > | >> > | VectorXd IneqT = (theta*Ineq.transpose()); >> > | >> > | return 0; >> > | } >> > | >> > | /*** R >> > | >> > | # the following is equivalent to mptmin::R/minimal.cpp # but shorter >> > | and easier; also removed the leading dot >> > | oneSample2 <- function(Sx, Ineq) { >> > | #.Call("determinant2", Sx, Ineq, PACKAGE = "MPTbug") >> > | determinant2(Sx, Ineq) >> > | } >> > | >> > | # the dimensions are of course incompatible so this is user error >> > | trigger <- function() { >> > | S <- 3 >> > | # why would you create a matrix via structure() ? >> > | Ineq <- structure(0, .Dim = c(1L, 1L)) #error >> > | oneSample2(Sx = S, Ineq = Ineq) >> > | } >> > | >> > | no_trigger <- function() { >> > | S <- 3 >> > | Ineq <- structure(c(-1, 1, 0), .Dim = c(1L, 3L)) # no error >> > | oneSample2(Sx = S, Ineq = Ineq) >> > | } >> > | >> > | no_trigger() # no issue >> > | trigger() # no issue either >> > | */ >> > | >> > | -------------------------------------------------------------------- >> > | --------- >> > | >> > | >> > | In an R session, issue the following command >> > | sourceCpp("filename.cpp") with the name (plus optional path) to the >> > | file above. Here is what I get in a fresh session: >> > | >> > | -------------------------------------------------------------------- >> > | --------- >> > | R> Rcpp::sourceCpp("~/Dropbox/tmp/henrik.cpp") >> > | >> > | R> # the following is equivalent to mptmin::R/minimal.cpp # but >> > | R> shorter and easier; also removed the leading dot >> > | R> oneSample2 <- function(Sx, In .... [TRUNCATED] >> > | >> > | R> # the dimensions are of course incompatible so this is user error >> > | R> trigger <- function() { >> > | + S <- 3 >> > | + # why would you create a matrix via str .... [TRUNCATED] >> > | >> > | R> no_trigger <- function() { >> > | + S <- 3 >> > | + Ineq <- structure(c(-1, 1, 0), .Dim = c(1L, 3L)) # no error >> > | + oneSample2(Sx = S, Ineq = Ineq) >> > | + } >> > | >> > | R> no_trigger() # no issue >> > | [1] 0 >> > | >> > | R> trigger() # no issue either >> > | [1] 0 >> > | R> >> > | -------------------------------------------------------------------- >> > | --------- >> > | >> > | I consider this issue closed because __there is still no minimal >> > | reproducible bug__. >> > | >> > | There is what we could call a user error. Or if you wish a design >> > | error. You simply cannot multiply non-conformant vectors. >> > | >> > | Dirk > > _______________________________________________ > Rcpp-devel mailing list > Rcpp-devel at lists.r-forge.r-project.org > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel From bates at stat.wisc.edu Thu Oct 16 19:14:24 2014 From: bates at stat.wisc.edu (Douglas Bates) Date: Thu, 16 Oct 2014 12:14:24 -0500 Subject: [Rcpp-devel] RcppEigen: Windows binary from CRAN crashes R, but not when installing from source. In-Reply-To: References: <543EC42F.1000001@psychologie.uni-freiburg.de> <21566.51054.502184.443950@max.nulle.part> <543EE3F6.20907@psychologie.uni-freiburg.de> <21566.62211.262507.47211@max.nulle.part> <543FC30C.6090306@psychologie.uni-freiburg.de> <21567.51606.784535.536005@max.nulle.part> <21567.53336.38384.338507@max.nulle.part> <543FD892.70803@psychologie.uni-freiburg.de> <00F9E64B563E7C45818C85C1B7FCC726A777D2A8@SFMB02.exponent.com> Message-ID: On Thu, Oct 16, 2014 at 11:35 AM, Kevin Ushey wrote: > I think John's advice is spot on here. The issue is only seen when > `NDEBUG` is not defined. > > I can reproduce the crash (assertion failure) by ensuring I have > > CXXFLAGS=-UNDEBUG > > in my ~/.R/Makevars. Note that: > > 1. An assertion failure from Eigen implies you are doing something > that you should not be doing, and > 2. R by default sets -DNDEBUG whenever compiling by default, so I am > surprised that you are not seeing it (does your package have a custom > Makefile / Makevars or something to that effect? Or do you have your > own custom Makevars somewhere?) > > Anyway, let's assume Eigen is right -- this means you're multiplying > two non-conforming matrices, and hence your matrix product is > undefined. Which makes sense, since you're now trying to multiply two > non-conforming matrices. And if you want a scalar * matrix > multiplication then you need to be using a different function. > > Note that this is exactly what Eigen's assertion was telling you here! > Which brings up the issue of the default Makefile for R packages overriding other settings and enforcing -DNDEBUG. I know that I would prefer to learn that there were identifiable inconsistencies in the underlying code, even if it meant that the failed assertion caused R to crash. Those assertions are there for a reason. The decision to enforce a "fail faulty" scheme, where known errors are silently allowed to go undetected, seems peculiar to me. > > On Thu, Oct 16, 2014 at 8:58 AM, John Buonagurio > wrote: > > Hi Henrik, > > > > You can just add #define EIGEN_NO_DEBUG to make it clear that you want > to specifically disable Eigen assertions, without relying on what sets or > does not set the DNDEBUG flag. It's in the Eigen documentation: > > > > http://eigen.tuxfamily.org/dox/TopicPreprocessorDirectives.html > > > > John > > > >> -----Original Message----- > >> From: rcpp-devel-bounces at lists.r-forge.r-project.org [mailto: > rcpp-devel- > >> bounces at lists.r-forge.r-project.org] On Behalf Of Henrik Singmann > >> Sent: Thursday, October 16, 2014 10:39 AM > >> To: Dirk Eddelbuettel > >> Cc: rcpp-devel at r-forge.wu-wien.ac.at > >> Subject: Re: [Rcpp-devel] RcppEigen: Windows binary from CRAN crashes > R, but > >> not when installing from source. > >> > >> > >> Hi Dirk, > >> > >> I am sorry to address this again, as I am in no position to argue, but > the problem > >> is still the following: > >> The code runs perfectly as your example showed but will fail when using > either > >> devtools or winbuilder or CRAN when *inside a package*. The problem of > >> producing a minimally reproducible example of your liking is that > either of those > >> conditions cannot be met: I need the package to reproduce it. > >> > >> I also agree that it is an issue of multiplying non-conformable > vectors. But as can > >> be easily shown using the code you had sent, when compiling it on owns > own > >> (i.e., not using the conditions reproducing the crash described above) > this only > >> leads to a result of 0. However, when using the binary from either of > the above > >> it crashes R with an assertion error. > >> It is also important to note that this did not happen in the past. > >> > >> So I probably just need to set the correct compiler flags or disable > DNDEBUG or > >> such a thing, but I did not manage to do this in such a way to prohibit > the crash > >> under the above described circumstances. > >> I would really like to receive any advice on how to avoid this crash > (assertion > >> error) when using the binary compiled on CRAN, this is in the end the > critical > >> issue. *How can I disable the assertion error compiling in my code?* > Just adding > >> "#undef NDEBUG" at the beginning didn't work. > >> > >> > >> On an unrelated note, the issue of within package or outside of a > package also > >> concerns the question of "using Eigen::..." versus prefacing all calls > to Eigen > >> parts with Eigen:: directly. > >> While the code you had sent works great when using sourceCpp(), I didn't > >> manage to get it to work in a package (even after wildly using > >> compileAttributes). I had to replace all calls of e.g., VectorXd with > >> Eigen::VectorXd. Is there a trick of how to do this inside a package? > >> > >> Btw, I agree that using the RcppAttributes is great. I hadn't used it, > because, you > >> know, "never touch a running system." But as it failed now, it is > perhaps time for > >> a change. > >> > >> Thanks again, > >> Henrik > >> > >> > >> Am 16.10.2014 um 16:04 schrieb Dirk Eddelbuettel: > >> > On 16 October 2014 at 08:35, Dirk Eddelbuettel wrote: > >> > | > >> > | > >> > | On 16 October 2014 at 15:07, Henrik Singmann wrote: > >> > | | Hi Dirk and Kevin, > >> > | | > >> > | | I have now rebuild the package using the code Dirk send me (i.e., > using > >> attributes) and the code still reliably crashes my R on Linux when > using devtools > >> (independent of RStudio), but not when installing via install.packages. > When just > >> using the code Dirk had send directly (i.e., outside a package) this > does not > >> happen. > >> > | > >> > | Please take that up with the devtools maintainer. I do not use > devtools. > >> > > >> > And FWIW he used confirmed over IM that devtools sets NDEBUG. So > >> > there -- devtools issues, not an Rcpp or RcppEigen issue. > >> > > >> > Dirk > >> > > >> > | It is not part of what we asked for: __a minimally reproducible > >> > | example__ > >> > | > >> > | | Note that I had to minimally change the code Dirk had sent as I > couldn't > >> manage to use "using Eigen::" so had to preface every call to Eigen > functions or > >> structures with "Eigen::". > >> > | > >> > | Here is my counter example. Ubuntu 14.04. Everything current. > >> > | > >> > | Save the following a file "henrik.cpp" > >> > | > >> > | -------------------------------------------------------------------- > >> > | --------- > >> > | > >> > | #include > >> > | > >> > | using namespace Rcpp; > >> > | > >> > | using Eigen::Map; > >> > | using Eigen::VectorXd; > >> > | using Eigen::RowVectorXd; > >> > | using Eigen::MatrixXd; > >> > | > >> > | // [[Rcpp::depends(RcppEigen)]] > >> > | > >> > | // The following is __identical__ to mptmin::src/determinant.cpp // > >> > | but at the same time much, much shorter and more readable // // The > >> > | following 'tag' ensure determinant2() is accessible from R // // > >> > | [[Rcpp::export]] int determinant2(int S, Map Ineq) { > >> > | > >> > | VectorXd thetaTMP = Rcpp::as(rbeta(S, 0.5, 0.5)); > >> > | RowVectorXd theta = thetaTMP.transpose(); > >> > | > >> > | VectorXd IneqT = (theta*Ineq.transpose()); > >> > | > >> > | return 0; > >> > | } > >> > | > >> > | /*** R > >> > | > >> > | # the following is equivalent to mptmin::R/minimal.cpp # but shorter > >> > | and easier; also removed the leading dot > >> > | oneSample2 <- function(Sx, Ineq) { > >> > | #.Call("determinant2", Sx, Ineq, PACKAGE = "MPTbug") > >> > | determinant2(Sx, Ineq) > >> > | } > >> > | > >> > | # the dimensions are of course incompatible so this is user error > >> > | trigger <- function() { > >> > | S <- 3 > >> > | # why would you create a matrix via structure() ? > >> > | Ineq <- structure(0, .Dim = c(1L, 1L)) #error > >> > | oneSample2(Sx = S, Ineq = Ineq) > >> > | } > >> > | > >> > | no_trigger <- function() { > >> > | S <- 3 > >> > | Ineq <- structure(c(-1, 1, 0), .Dim = c(1L, 3L)) # no error > >> > | oneSample2(Sx = S, Ineq = Ineq) > >> > | } > >> > | > >> > | no_trigger() # no issue > >> > | trigger() # no issue either > >> > | */ > >> > | > >> > | -------------------------------------------------------------------- > >> > | --------- > >> > | > >> > | > >> > | In an R session, issue the following command > >> > | sourceCpp("filename.cpp") with the name (plus optional path) to the > >> > | file above. Here is what I get in a fresh session: > >> > | > >> > | -------------------------------------------------------------------- > >> > | --------- > >> > | R> Rcpp::sourceCpp("~/Dropbox/tmp/henrik.cpp") > >> > | > >> > | R> # the following is equivalent to mptmin::R/minimal.cpp # but > >> > | R> shorter and easier; also removed the leading dot > >> > | R> oneSample2 <- function(Sx, In .... [TRUNCATED] > >> > | > >> > | R> # the dimensions are of course incompatible so this is user error > >> > | R> trigger <- function() { > >> > | + S <- 3 > >> > | + # why would you create a matrix via str .... [TRUNCATED] > >> > | > >> > | R> no_trigger <- function() { > >> > | + S <- 3 > >> > | + Ineq <- structure(c(-1, 1, 0), .Dim = c(1L, 3L)) # no error > >> > | + oneSample2(Sx = S, Ineq = Ineq) > >> > | + } > >> > | > >> > | R> no_trigger() # no issue > >> > | [1] 0 > >> > | > >> > | R> trigger() # no issue either > >> > | [1] 0 > >> > | R> > >> > | -------------------------------------------------------------------- > >> > | --------- > >> > | > >> > | I consider this issue closed because __there is still no minimal > >> > | reproducible bug__. > >> > | > >> > | There is what we could call a user error. Or if you wish a design > >> > | error. You simply cannot multiply non-conformant vectors. > >> > | > >> > | Dirk > > > > _______________________________________________ > > Rcpp-devel mailing list > > Rcpp-devel at lists.r-forge.r-project.org > > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel > _______________________________________________ > Rcpp-devel mailing list > Rcpp-devel at lists.r-forge.r-project.org > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From henrik.singmann at psychologie.uni-freiburg.de Thu Oct 16 19:41:38 2014 From: henrik.singmann at psychologie.uni-freiburg.de (Henrik Singmann) Date: Thu, 16 Oct 2014 19:41:38 +0200 Subject: [Rcpp-devel] RcppEigen: Windows binary from CRAN crashes R, but not when installing from source. In-Reply-To: References: <543EC42F.1000001@psychologie.uni-freiburg.de> <21566.51054.502184.443950@max.nulle.part> <543EE3F6.20907@psychologie.uni-freiburg.de> <21566.62211.262507.47211@max.nulle.part> <543FC30C.6090306@psychologie.uni-freiburg.de> <21567.51606.784535.536005@max.nulle.part> <21567.53336.38384.338507@max.nulle.part> <543FD892.70803@psychologie.uni-freiburg.de> <00F9E64B563E7C45818C85C1B7FCC726A777D2A8@SFMB02.exponent.com> Message-ID: <000a01cfe968$71af7af0$550e70d0$@psychologie.uni-freiburg.de> Dear all, Actually John?s first advise was already spot on. Adding either "#define EIGEN_NO_DEBUG" or "#define NDEBUG" to the top of the cpp file (above anything else) already leads to the desired result: returning 0 instead of crashing R. When trying it the first time I somehow had put it below the "#include " line which did not work. Please accept my apologies for prolonging this discussion unnecessarily. And it would probably be wiser to not perform the computation for non-confirming vectors. I only need to make sure to understand when this occurs and how to catch it. Thank you all for your time and help. I really appreciate it. I can now start to prepare my next CRAN submission. All the best, Henrik --- Dr. Henrik Singmann PostDoc University of Z?rich, Switzerland http://singmann.org Von: dmbates at gmail.com [mailto:dmbates at gmail.com] Im Auftrag von Douglas Bates Gesendet: Donnerstag, 16. Oktober 2014 19:14 An: Kevin Ushey Cc: John Buonagurio; Henrik Singmann; rcpp-devel at r-forge.wu-wien.ac.at Betreff: Re: [Rcpp-devel] RcppEigen: Windows binary from CRAN crashes R, but not when installing from source. On Thu, Oct 16, 2014 at 11:35 AM, Kevin Ushey wrote: I think John's advice is spot on here. The issue is only seen when `NDEBUG` is not defined. I can reproduce the crash (assertion failure) by ensuring I have CXXFLAGS=-UNDEBUG in my ~/.R/Makevars. Note that: 1. An assertion failure from Eigen implies you are doing something that you should not be doing, and 2. R by default sets -DNDEBUG whenever compiling by default, so I am surprised that you are not seeing it (does your package have a custom Makefile / Makevars or something to that effect? Or do you have your own custom Makevars somewhere?) Anyway, let's assume Eigen is right -- this means you're multiplying two non-conforming matrices, and hence your matrix product is undefined. Which makes sense, since you're now trying to multiply two non-conforming matrices. And if you want a scalar * matrix multiplication then you need to be using a different function. Note that this is exactly what Eigen's assertion was telling you here! Which brings up the issue of the default Makefile for R packages overriding other settings and enforcing -DNDEBUG. I know that I would prefer to learn that there were identifiable inconsistencies in the underlying code, even if it meant that the failed assertion caused R to crash. Those assertions are there for a reason. The decision to enforce a "fail faulty" scheme, where known errors are silently allowed to go undetected, seems peculiar to me. On Thu, Oct 16, 2014 at 8:58 AM, John Buonagurio wrote: > Hi Henrik, > > You can just add #define EIGEN_NO_DEBUG to make it clear that you want to specifically disable Eigen assertions, without relying on what sets or does not set the DNDEBUG flag. It's in the Eigen documentation: > > http://eigen.tuxfamily.org/dox/TopicPreprocessorDirectives.html > > John > >> -----Original Message----- >> From: rcpp-devel-bounces at lists.r-forge.r-project.org [mailto:rcpp-devel- >> bounces at lists.r-forge.r-project.org] On Behalf Of Henrik Singmann >> Sent: Thursday, October 16, 2014 10:39 AM >> To: Dirk Eddelbuettel >> Cc: rcpp-devel at r-forge.wu-wien.ac.at >> Subject: Re: [Rcpp-devel] RcppEigen: Windows binary from CRAN crashes R, but >> not when installing from source. >> >> >> Hi Dirk, >> >> I am sorry to address this again, as I am in no position to argue, but the problem >> is still the following: >> The code runs perfectly as your example showed but will fail when using either >> devtools or winbuilder or CRAN when *inside a package*. The problem of >> producing a minimally reproducible example of your liking is that either of those >> conditions cannot be met: I need the package to reproduce it. >> >> I also agree that it is an issue of multiplying non-conformable vectors. But as can >> be easily shown using the code you had sent, when compiling it on owns own >> (i.e., not using the conditions reproducing the crash described above) this only >> leads to a result of 0. However, when using the binary from either of the above >> it crashes R with an assertion error. >> It is also important to note that this did not happen in the past. >> >> So I probably just need to set the correct compiler flags or disable DNDEBUG or >> such a thing, but I did not manage to do this in such a way to prohibit the crash >> under the above described circumstances. >> I would really like to receive any advice on how to avoid this crash (assertion >> error) when using the binary compiled on CRAN, this is in the end the critical >> issue. *How can I disable the assertion error compiling in my code?* Just adding >> "#undef NDEBUG" at the beginning didn't work. >> >> >> On an unrelated note, the issue of within package or outside of a package also >> concerns the question of "using Eigen::..." versus prefacing all calls to Eigen >> parts with Eigen:: directly. >> While the code you had sent works great when using sourceCpp(), I didn't >> manage to get it to work in a package (even after wildly using >> compileAttributes). I had to replace all calls of e.g., VectorXd with >> Eigen::VectorXd. Is there a trick of how to do this inside a package? >> >> Btw, I agree that using the RcppAttributes is great. I hadn't used it, because, you >> know, "never touch a running system." But as it failed now, it is perhaps time for >> a change. >> >> Thanks again, >> Henrik >> >> >> Am 16.10.2014 um 16:04 schrieb Dirk Eddelbuettel: >> > On 16 October 2014 at 08:35, Dirk Eddelbuettel wrote: >> > | >> > | >> > | On 16 October 2014 at 15:07, Henrik Singmann wrote: >> > | | Hi Dirk and Kevin, >> > | | >> > | | I have now rebuild the package using the code Dirk send me (i.e., using >> attributes) and the code still reliably crashes my R on Linux when using devtools >> (independent of RStudio), but not when installing via install.packages. When just >> using the code Dirk had send directly (i.e., outside a package) this does not >> happen. >> > | >> > | Please take that up with the devtools maintainer. I do not use devtools. >> > >> > And FWIW he used confirmed over IM that devtools sets NDEBUG. So >> > there -- devtools issues, not an Rcpp or RcppEigen issue. >> > >> > Dirk >> > >> > | It is not part of what we asked for: __a minimally reproducible >> > | example__ >> > | >> > | | Note that I had to minimally change the code Dirk had sent as I couldn't >> manage to use "using Eigen::" so had to preface every call to Eigen functions or >> structures with "Eigen::". >> > | >> > | Here is my counter example. Ubuntu 14.04. Everything current. >> > | >> > | Save the following a file "henrik.cpp" >> > | >> > | -------------------------------------------------------------------- >> > | --------- >> > | >> > | #include >> > | >> > | using namespace Rcpp; >> > | >> > | using Eigen::Map; >> > | using Eigen::VectorXd; >> > | using Eigen::RowVectorXd; >> > | using Eigen::MatrixXd; >> > | >> > | // [[Rcpp::depends(RcppEigen)]] >> > | >> > | // The following is __identical__ to mptmin::src/determinant.cpp // >> > | but at the same time much, much shorter and more readable // // The >> > | following 'tag' ensure determinant2() is accessible from R // // >> > | [[Rcpp::export]] int determinant2(int S, Map Ineq) { >> > | >> > | VectorXd thetaTMP = Rcpp::as(rbeta(S, 0.5, 0.5)); >> > | RowVectorXd theta = thetaTMP.transpose(); >> > | >> > | VectorXd IneqT = (theta*Ineq.transpose()); >> > | >> > | return 0; >> > | } >> > | >> > | /*** R >> > | >> > | # the following is equivalent to mptmin::R/minimal.cpp # but shorter >> > | and easier; also removed the leading dot >> > | oneSample2 <- function(Sx, Ineq) { >> > | #.Call("determinant2", Sx, Ineq, PACKAGE = "MPTbug") >> > | determinant2(Sx, Ineq) >> > | } >> > | >> > | # the dimensions are of course incompatible so this is user error >> > | trigger <- function() { >> > | S <- 3 >> > | # why would you create a matrix via structure() ? >> > | Ineq <- structure(0, .Dim = c(1L, 1L)) #error >> > | oneSample2(Sx = S, Ineq = Ineq) >> > | } >> > | >> > | no_trigger <- function() { >> > | S <- 3 >> > | Ineq <- structure(c(-1, 1, 0), .Dim = c(1L, 3L)) # no error >> > | oneSample2(Sx = S, Ineq = Ineq) >> > | } >> > | >> > | no_trigger() # no issue >> > | trigger() # no issue either >> > | */ >> > | >> > | -------------------------------------------------------------------- >> > | --------- >> > | >> > | >> > | In an R session, issue the following command >> > | sourceCpp("filename.cpp") with the name (plus optional path) to the >> > | file above. Here is what I get in a fresh session: >> > | >> > | -------------------------------------------------------------------- >> > | --------- >> > | R> Rcpp::sourceCpp("~/Dropbox/tmp/henrik.cpp") >> > | >> > | R> # the following is equivalent to mptmin::R/minimal.cpp # but >> > | R> shorter and easier; also removed the leading dot >> > | R> oneSample2 <- function(Sx, In .... [TRUNCATED] >> > | >> > | R> # the dimensions are of course incompatible so this is user error >> > | R> trigger <- function() { >> > | + S <- 3 >> > | + # why would you create a matrix via str .... [TRUNCATED] >> > | >> > | R> no_trigger <- function() { >> > | + S <- 3 >> > | + Ineq <- structure(c(-1, 1, 0), .Dim = c(1L, 3L)) # no error >> > | + oneSample2(Sx = S, Ineq = Ineq) >> > | + } >> > | >> > | R> no_trigger() # no issue >> > | [1] 0 >> > | >> > | R> trigger() # no issue either >> > | [1] 0 >> > | R> >> > | -------------------------------------------------------------------- >> > | --------- >> > | >> > | I consider this issue closed because __there is still no minimal >> > | reproducible bug__. >> > | >> > | There is what we could call a user error. Or if you wish a design >> > | error. You simply cannot multiply non-conformant vectors. >> > | >> > | Dirk > > _______________________________________________ > Rcpp-devel mailing list > Rcpp-devel at lists.r-forge.r-project.org > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel _______________________________________________ Rcpp-devel mailing list Rcpp-devel at lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel From kslowikowski at gmail.com Thu Oct 16 20:41:25 2014 From: kslowikowski at gmail.com (Kamil Slowikowski) Date: Thu, 16 Oct 2014 14:41:25 -0400 Subject: [Rcpp-devel] NULL value passed as symbol address Message-ID: Why must I call my C++ function using the `.Call()` syntax? Why can't I call it by name? Other C++ functions in my package do not have this problem. It's just this one that has the NULL symbol address. ``` > library(kamlib) Attaching package: ?kamlib? > expected_errors(c('####')) Error in .Primitive(".Call")(, xs) : NULL value passed as symbol address > .Call('kamlib_expected_errors', PACKAGE = 'kamlib', c('####')) [1] 2.52384 ``` I created a package called 'kamlib'. In that package, I have a C++ file called 'expected_errors.cpp' with this code: ``` #include #include using namespace Rcpp; // [[Rcpp::export]] NumericVector expected_errors(CharacterVector xs) { const double probs[] = { 0.79433, 0.63096, 0.50119, 0.39811, 0.31623, 0.25119, 0.19953, 0.15849, 0.12589, 0.10000, 0.07943, 0.06310, 0.05012, 0.03981, 0.03162, 0.02512, 0.01995, 0.01585, 0.01259, 0.01000, 0.00794, 0.00631, 0.00501, 0.00398, 0.00316, 0.00251, 0.00200, 0.00158, 0.00126, 0.00100, 0.00079, 0.00063, 0.00050, 0.00040, 0.00032, 0.00025, 0.00020, 0.00016, 0.00013, 0.00010, 0.00008 }; NumericVector res(xs.size()); for (int i = 0; i < xs.size(); i++) { for (int j = 0; j < strlen(xs[i]); j++) { res[i] += probs[ (int) xs[i][j] - 34 ]; } } return res; } ``` My `RcppExports.R` file looks perfectly fine: ``` # This file was generated by Rcpp::compileAttributes # Generator token: 10BE3573-1514-4C36-9D1C-5A225CD40393 expected_errors <- function(xs) { .Call('kamlib_expected_errors', PACKAGE = 'kamlib', xs) } sos <- function(xs) { .Call('kamlib_sos', PACKAGE = 'kamlib', xs) } ``` -------------- next part -------------- An HTML attachment was scrubbed... URL: From kslowikowski at gmail.com Thu Oct 16 20:44:12 2014 From: kslowikowski at gmail.com (Kamil Slowikowski) Date: Thu, 16 Oct 2014 14:44:12 -0400 Subject: [Rcpp-devel] NULL value passed as symbol address In-Reply-To: References: Message-ID: Please ignore my previous message. I solved my own problem. I defined `expected_errors()` 2 times. Once in the .cpp file and once in a .R file using `cppFunction()`. I simply forgot to delete the R file. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmoores at gmail.com Fri Oct 17 19:11:08 2014 From: mmoores at gmail.com (Matt) Date: Fri, 17 Oct 2014 18:11:08 +0100 Subject: [Rcpp-devel] lmBenchmark broken for RcppArmadillo? Message-ID: When I try running lmBenchmark.R I get the following error: Rscript -e "source(system.file(\"examples\", \"lmBenchmark.R\", package = \"RcppEigen\"))" lm benchmark for n = 100000 and p = 40: nrep = 20 Error in .Call("fastLm", mm, y, PACKAGE = "RcppArmadillo") : "fastLm" not available for .Call() for package "RcppArmadillo" Calls: source ... replicate -> sapply -> lapply -> FUN -> eval -> eval -> .Call Timing stopped at: 0.001 0 0 Execution halted This happens on both Mac OS X and Ubuntu 14, with R 3.1.1, Rcpp 0.11.3, RcppArmadillo 0.4.450.1.0, RcppEigen 0.3.2.2.0, RcppGSL 0.2.2 and rbenchmark 1.0.0 Note that if I run do_bench() manually but remove exprs$arma then it runs fine: > print(do_bench()) lm benchmark for n = 100000 and p = 40: nrep = 20 test relative elapsed user.self sys.self 3 LDLt 1.000 0.489 0.483 0.006 8 LLt 1.004 0.491 0.484 0.007 6 SymmEig 3.043 1.488 1.321 0.162 7 QR 5.681 2.778 2.612 0.166 2 PivQR 5.873 2.872 2.723 0.150 1 lm.fit 7.229 3.535 3.467 0.069 4 GESDD 18.826 9.206 8.968 0.240 5 SVD 35.307 17.265 16.893 0.376 9 GSL 140.135 68.526 68.304 0.209 RcppGSL doesn't have this problem, only RcppArmadillo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From edd at debian.org Fri Oct 17 20:02:38 2014 From: edd at debian.org (Dirk Eddelbuettel) Date: Fri, 17 Oct 2014 13:02:38 -0500 Subject: [Rcpp-devel] lmBenchmark broken for RcppArmadillo? In-Reply-To: References: Message-ID: <21569.22974.388819.227084@max.nulle.part> On 17 October 2014 at 18:11, Matt wrote: | When I try running lmBenchmark.R I get the following error: | | | Rscript -e "source(system.file(\"examples\", \"lmBenchmark.R\", package = \ | "RcppEigen\"))" | | lm benchmark for n = 100000 and p = 40: nrep = 20 | | Error in .Call("fastLm", mm, y, PACKAGE = "RcppArmadillo") :? | | ? "fastLm" not available for .Call() for package "RcppArmadillo" The signature changed when we changed the function to using Rcpp Attributes. This should be pretty easy to fix. >From src/RcppExports.cpp in RcppArmadillo: List fastLm(const arma::mat& X, const arma::colvec& y); RcppExport SEXP RcppArmadillo_fastLm(SEXP XSEXP, SEXP ySEXP) { The file examples/fastLm.r in RcppArmadillo now does fastLmPureDotCall <- function(X, y) { .Call("RcppArmadillo_fastLm", X, y, PACKAGE = "RcppArmadillo") } so try that. In case you get something working, consider sending in a patch. Thanks, Dirk | | Calls: source ... replicate -> sapply -> lapply -> FUN -> eval -> eval -> .Call | | Timing stopped at: 0.001 0 0? | | Execution halted | | | This happens on both Mac OS X and Ubuntu 14, with R 3.1.1, Rcpp 0.11.3, | RcppArmadillo?0.4.450.1.0, RcppEigen 0.3.2.2.0, RcppGSL 0.2.2 and rbenchmark | 1.0.0 | | Note that if I run do_bench() manually but remove?exprs$arma then it runs fine: | | > print(do_bench()) | lm benchmark for n = 100000 and p = 40: nrep = 20 | ? ? ?test relative elapsed user.self sys.self | 3 ? ?LDLt ? ?1.000 ? 0.489 ? ? 0.483 ? ?0.006 | 8 ? ? LLt ? ?1.004 ? 0.491 ? ? 0.484 ? ?0.007 | 6 SymmEig ? ?3.043 ? 1.488 ? ? 1.321 ? ?0.162 | 7 ? ? ?QR ? ?5.681 ? 2.778 ? ? 2.612 ? ?0.166 | 2 ? PivQR ? ?5.873 ? 2.872 ? ? 2.723 ? ?0.150 | 1 ?lm.fit ? ?7.229 ? 3.535 ? ? 3.467 ? ?0.069 | 4 ? GESDD ? 18.826 ? 9.206 ? ? 8.968 ? ?0.240 | 5 ? ? SVD ? 35.307 ?17.265 ? ?16.893 ? ?0.376 | 9 ? ? GSL ?140.135 ?68.526 ? ?68.304 ? ?0.209 | | RcppGSL doesn't have this problem, only RcppArmadillo. | _______________________________________________ | Rcpp-devel mailing list | Rcpp-devel at lists.r-forge.r-project.org | https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel -- http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org From mmoores at gmail.com Mon Oct 20 13:26:54 2014 From: mmoores at gmail.com (Matt) Date: Mon, 20 Oct 2014 12:26:54 +0100 Subject: [Rcpp-devel] lmBenchmark broken for RcppArmadillo? In-Reply-To: <21569.22974.388819.227084@max.nulle.part> References: <21569.22974.388819.227084@max.nulle.part> Message-ID: I've confirmed that this works on R 3.1.1 under OS X, using RcppArmadillo 0.4.450.1.0: *diff --git a/inst/examples/lmBenchmark.R b/inst/examples/lmBenchmark.R* *index 9037107..dd49375 100644* *--- a/inst/examples/lmBenchmark.R* *+++ b/inst/examples/lmBenchmark.R* @@ -37,7 +37,7 @@ exprs$QR <- expression(.Call("fastLm", mm, y, 1L, PACKAGE="Rcp exprs$LLt <- expression(.Call("fastLm", mm, y, 3L, PACKAGE="RcppEigen")) if (suppressMessages(require("RcppArmadillo", character=TRUE, quietly=TRUE))) { - exprs$arma <- expression(.Call("fastLm", mm, y, PACKAGE="RcppArmadillo")) + exprs$arma <- expression(.Call("RcppArmadillo_fastLm", mm, y, PACKAGE="Rcpp } if (suppressMessages(require("RcppGSL", character=TRUE, quietly=TRUE))) { -------------- next part -------------- An HTML attachment was scrubbed... URL: From edd at debian.org Mon Oct 20 14:16:38 2014 From: edd at debian.org (Dirk Eddelbuettel) Date: Mon, 20 Oct 2014 07:16:38 -0500 Subject: [Rcpp-devel] lmBenchmark broken for RcppArmadillo? In-Reply-To: References: <21569.22974.388819.227084@max.nulle.part> Message-ID: <21572.64806.435048.259531@max.nulle.part> On 20 October 2014 at 12:26, Matt wrote: | I've confirmed that this works on R 3.1.1 under OS X, using RcppArmadillo? | 0.4.450.1.0: Thanks for testing / conforming, and of course for having alterted us in the first place -- I am updating the example code. Dirk | | | diff --git a/inst/examples/lmBenchmark.R b/inst/examples/lmBenchmark.R | | index 9037107..dd49375 100644 | | --- a/inst/examples/lmBenchmark.R | | +++ b/inst/examples/lmBenchmark.R | | @@ -37,7 +37,7 @@ exprs$QR <- expression(.Call("fastLm", mm, y, 1L, PACKAGE= | "Rcp | | ?exprs$LLt <- expression(.Call("fastLm", mm, y, 3L, PACKAGE="RcppEigen")) | | ? | | ?if (suppressMessages(require("RcppArmadillo", character=TRUE, quietly=TRUE))) | { | | -? ? exprs$arma <- expression(.Call("fastLm", mm, y, PACKAGE="RcppArmadillo")) | | +? ? exprs$arma <- expression(.Call("RcppArmadillo_fastLm", mm, y, PACKAGE= | "Rcpp | | ?} | | ? | | ?if (suppressMessages(require("RcppGSL", character=TRUE, quietly=TRUE))) { | -- http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org From gustaf.granath at gmail.com Mon Oct 20 21:17:10 2014 From: gustaf.granath at gmail.com (Gustaf Granath) Date: Mon, 20 Oct 2014 15:17:10 -0400 Subject: [Rcpp-devel] convert to unsigned char* variable Message-ID: <54455FB6.701@gmail.com> Hi Im trying to use some C++ functions in R. However, these functions are build around unsigned char* variables (1D array). I have for example a large matrix in R that represents black (e.g. 1-bit image, 0 and 1s). I cant find a solution to convert a character vector into unsigned char* within Rcpp. Im new to Rcpp and C++ so I might have missed something obvious here. Please direct me to resources on this topic (google did not help much). A start: SEXP test(SEXP cM){ CharacterVector Vc(cM); int n = Vr.size(); RawVector x(n); //is this the same as unsigned char* ? //I tried to fill it with char*(Mr) but I didnt succeed } Thanks, Gustaf -- Gustaf Granath (PhD) Post doc McMaster University School of Geography & Earth Sciences From edd at debian.org Mon Oct 20 21:54:01 2014 From: edd at debian.org (Dirk Eddelbuettel) Date: Mon, 20 Oct 2014 14:54:01 -0500 Subject: [Rcpp-devel] convert to unsigned char* variable In-Reply-To: <54455FB6.701@gmail.com> References: <54455FB6.701@gmail.com> Message-ID: <21573.26713.483785.660967@max.nulle.part> Hi Gustaf, On 20 October 2014 at 15:17, Gustaf Granath wrote: | Im trying to use some C++ functions in R. However, these functions are | build around unsigned char* variables (1D array). I have for example a | large matrix in R that represents black (e.g. 1-bit image, 0 and 1s). I | cant find a solution to convert a character vector into unsigned char* | within Rcpp. Im new to Rcpp and C++ so I might have missed something Rcpp builds a bridge between R and C++, and supports (in C++) the types that R supports. Eg you won't find 'float' but only 'double' as that is what R does. Here you will get character vectors easily. If they must be unsigned char, you will probably have to cast them at the C++ level. | obvious here. Please direct me to resources on this topic (google did | not help much). | | A start: | | SEXP test(SEXP cM){ | CharacterVector Vc(cM); | int n = Vr.size(); | RawVector x(n); //is this the same as unsigned char* ? No, RawVector is for R 'raw' types -- see help("raw") in R, Dirk | //I tried to fill it with char*(Mr) but I | didnt succeed | } | | Thanks, | | Gustaf | | -- | Gustaf Granath (PhD) | Post doc | McMaster University | School of Geography & Earth Sciences | | _______________________________________________ | Rcpp-devel mailing list | Rcpp-devel at lists.r-forge.r-project.org | https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel -- http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org From romain at r-enthusiasts.com Mon Oct 20 23:09:56 2014 From: romain at r-enthusiasts.com (Romain Francois) Date: Mon, 20 Oct 2014 23:09:56 +0200 Subject: [Rcpp-devel] convert to unsigned char* variable In-Reply-To: <21573.26713.483785.660967@max.nulle.part> References: <54455FB6.701@gmail.com> <21573.26713.483785.660967@max.nulle.part> Message-ID: <56EC2190-1ED2-47A3-ABCC-DDADB6F4692B@r-enthusiasts.com> > Le 20 oct. 2014 ? 21:54, Dirk Eddelbuettel a ?crit : > > > Hi Gustaf, > > On 20 October 2014 at 15:17, Gustaf Granath wrote: > | Im trying to use some C++ functions in R. However, these functions are > | build around unsigned char* variables (1D array). I have for example a > | large matrix in R that represents black (e.g. 1-bit image, 0 and 1s). I > | cant find a solution to convert a character vector into unsigned char* > | within Rcpp. Im new to Rcpp and C++ so I might have missed something > > Rcpp builds a bridge between R and C++, and supports (in C++) the types that > R supports. Eg you won't find 'float' but only 'double' as that is what R > does. > > Here you will get character vectors easily. If they must be unsigned char, > you will probably have to cast them at the C++ level. > > | obvious here. Please direct me to resources on this topic (google did > | not help much). > | > | A start: > | > | SEXP test(SEXP cM){ > | CharacterVector Vc(cM); > | int n = Vr.size(); > | RawVector x(n); //is this the same as unsigned char* ? > > No, RawVector is for R 'raw' types -- see help("raw") in R, Guess what raw is !!! > demangle( "RawVector::stored_type" ) [1] "unsigned char" > Dirk > > | //I tried to fill it with char*(Mr) but I > | didnt succeed > | } > | > | Thanks, > | > | Gustaf > | > | -- > | Gustaf Granath (PhD) > | Post doc > | McMaster University > | School of Geography & Earth Sciences > | > | _______________________________________________ > | Rcpp-devel mailing list > | Rcpp-devel at lists.r-forge.r-project.org > | https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel > > -- > http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org > _______________________________________________ > Rcpp-devel mailing list > Rcpp-devel at lists.r-forge.r-project.org > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel From romain at r-enthusiasts.com Mon Oct 20 23:20:20 2014 From: romain at r-enthusiasts.com (Romain Francois) Date: Mon, 20 Oct 2014 23:20:20 +0200 Subject: [Rcpp-devel] convert to unsigned char* variable In-Reply-To: <54455FB6.701@gmail.com> References: <54455FB6.701@gmail.com> Message-ID: <732AB0F0-D5BF-4F67-BA4C-4D9F4764D47C@r-enthusiasts.com> Hi, that's not going to fly. A CharacterVector holds strings of arbitrary lengths, well technically it holds other R objects (SEXP) that hold pointers to strings. A RawVector holds unsigned char. Can you add some meat to your example, e.g. what you'd expect to go in, etc ... Romain > Le 20 oct. 2014 ? 21:17, Gustaf Granath a ?crit : > > Hi > Im trying to use some C++ functions in R. However, these functions are build around unsigned char* variables (1D array). I have for example a large matrix in R that represents black (e.g. 1-bit image, 0 and 1s). I cant find a solution to convert a character vector into unsigned char* within Rcpp. Im new to Rcpp and C++ so I might have missed something obvious here. Please direct me to resources on this topic (google did not help much). > > A start: > > SEXP test(SEXP cM){ > CharacterVector Vc(cM); > int n = Vr.size(); > RawVector x(n); //is this the same as unsigned char* ? > //I tried to fill it with char*(Mr) but I didnt succeed > } > > Thanks, > > Gustaf > > -- > Gustaf Granath (PhD) > Post doc > McMaster University > School of Geography & Earth Sciences > > _______________________________________________ > Rcpp-devel mailing list > Rcpp-devel at lists.r-forge.r-project.org > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel From edd at debian.org Mon Oct 20 23:35:45 2014 From: edd at debian.org (Dirk Eddelbuettel) Date: Mon, 20 Oct 2014 16:35:45 -0500 Subject: [Rcpp-devel] convert to unsigned char* variable In-Reply-To: <56EC2190-1ED2-47A3-ABCC-DDADB6F4692B@r-enthusiasts.com> References: <54455FB6.701@gmail.com> <21573.26713.483785.660967@max.nulle.part> <56EC2190-1ED2-47A3-ABCC-DDADB6F4692B@r-enthusiasts.com> Message-ID: <21573.32817.487472.114529@max.nulle.part> On 20 October 2014 at 23:09, Romain Francois wrote: | > Le 20 oct. 2014 ? 21:54, Dirk Eddelbuettel a ?crit : | > No, RawVector is for R 'raw' types -- see help("raw") in R, | | Guess what raw is !!! | | > demangle( "RawVector::stored_type" ) | [1] "unsigned char" Touche, but for all uses I have seen (eg around serialization) raw was not meant as the type Gustaf implied in his question. Then again Gustaf's post was a little short on specifics ... Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org From tkeitt at utexas.edu Tue Oct 21 16:27:56 2014 From: tkeitt at utexas.edu (Tim Keitt) Date: Tue, 21 Oct 2014 09:27:56 -0500 Subject: [Rcpp-devel] convert to unsigned char* variable In-Reply-To: <54455FB6.701@gmail.com> References: <54455FB6.701@gmail.com> Message-ID: On Mon, Oct 20, 2014 at 2:17 PM, Gustaf Granath wrote: > Hi > Im trying to use some C++ functions in R. However, these functions are > build around unsigned char* variables (1D array). I have for example a > large matrix in R that represents black (e.g. 1-bit image, 0 and 1s). I > cant find a solution to convert a character vector into unsigned char* > within Rcpp. Im new to Rcpp and C++ so I might have missed something > obvious here. Please direct me to resources on this topic (google did not > help much). > > A start: > > SEXP test(SEXP cM){ > CharacterVector Vc(cM); > int n = Vr.size(); > RawVector x(n); //is this the same as unsigned char* ? > //I tried to fill it with char*(Mr) but I > didnt succeed > } > I tend to go through the standard library as its less of a black box. Try creating a std::string and appending your chars to that string. Then call obj.c_str() to get the C-style array of chars. Or push the chars onto a std::vector and do something like &obj[0] to get a 1-D array. THK > > Thanks, > > Gustaf > > -- > Gustaf Granath (PhD) > Post doc > McMaster University > School of Geography & Earth Sciences > > _______________________________________________ > Rcpp-devel mailing list > Rcpp-devel at lists.r-forge.r-project.org > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel > -- http://www.keittlab.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustaf.granath at gmail.com Tue Oct 21 22:05:17 2014 From: gustaf.granath at gmail.com (Gustaf Granath) Date: Tue, 21 Oct 2014 16:05:17 -0400 Subject: [Rcpp-devel] convert to unsigned char* variable In-Reply-To: References: <54455FB6.701@gmail.com> Message-ID: <5446BC7D.30704@gmail.com> Hi all Thanks for the replies. After some testing it seems like I dont need the unsigned stuff and the functions seems to work fine with just a regular int variable. The functions I wanted to use were just small parts of a program and in that program bitmap images were loaded and image data stored as a unsigned char* (for bitmaps unsigned char are often used due to the 0-255 property I believe). I thought the simpliest solution was to stick to the original set up (so replicating the variables) but it seems that is not necessary which make things easier. However, I got curious how to handle this if I need it. First, I still dont get the difference between R raw and unsigned char (if there is one). E.g. this: unsigned char a = 'b'; cout << hex << a << endl; equals > charToRaw("b") [1] 62 So can unsigned char be used within Rcpp with RawVector? For example, is it possible to go from int/char to raw using Rcpp? Or is the recommended way to use unsigned char to go outside Rcpp as Tim suggested? Again, thanks for the input, Gustaf On 2014-10-21 10:27, Tim Keitt wrote: > > > On Mon, Oct 20, 2014 at 2:17 PM, Gustaf Granath > > wrote: > > Hi > Im trying to use some C++ functions in R. However, these functions > are build around unsigned char* variables (1D array). I have for > example a large matrix in R that represents black (e.g. 1-bit > image, 0 and 1s). I cant find a solution to convert a character > vector into unsigned char* within Rcpp. Im new to Rcpp and C++ so > I might have missed something obvious here. Please direct me to > resources on this topic (google did not help much). > > A start: > > SEXP test(SEXP cM){ > CharacterVector Vc(cM); > int n = Vr.size(); > RawVector x(n); //is this the same as unsigned char* ? > //I tried to fill it with char*(Mr) > but I didnt succeed > } > > > I tend to go through the standard library as its less of a black box. > Try creating a std::string and appending your chars to that string. > Then call obj.c_str() to get the C-style array of chars. Or push the > chars onto a std::vector and do something like &obj[0] to get a 1-D array. > > THK > > > Thanks, > > Gustaf > > -- > Gustaf Granath (PhD) > Post doc > McMaster University > School of Geography & Earth Sciences > > _______________________________________________ > Rcpp-devel mailing list > Rcpp-devel at lists.r-forge.r-project.org > > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel > > > > > -- > http://www.keittlab.org/ -- Gustaf Granath (PhD) Post doc McMaster University School of Geography & Earth Sciences -------------- next part -------------- An HTML attachment was scrubbed... URL: From edd at debian.org Tue Oct 21 22:30:05 2014 From: edd at debian.org (Dirk Eddelbuettel) Date: Tue, 21 Oct 2014 15:30:05 -0500 Subject: [Rcpp-devel] convert to unsigned char* variable In-Reply-To: <5446BC7D.30704@gmail.com> References: <54455FB6.701@gmail.com> <5446BC7D.30704@gmail.com> Message-ID: <21574.49741.668163.950403@max.nulle.part> Hi Gustaf, On 21 October 2014 at 16:05, Gustaf Granath wrote: | Thanks for the replies. After some testing it seems like I dont need the | unsigned stuff and the functions seems to work fine with just a regular int | variable. Sounds good. | The functions I wanted to use were just small parts of a program and | in that program bitmap images were loaded and image data stored as a unsigned | char* (for bitmaps unsigned char are often used due to the 0-255 property I | believe). I thought the simpliest solution was to stick to the original set up | (so replicating the variables) but it seems that is not necessary which make | things easier. | | However, I got curious how to handle this if I need it. | | First, I still dont get the difference between R raw and unsigned char (if | there is one). E.g.? | this: | unsigned char a = 'b'; | cout << hex << a << endl; | equals | > charToRaw("b") | [1] 62 | So can unsigned char be used within Rcpp with RawVector? Yes, what you get from something like charToRaw() should work seamlessly in RawVector. [ But in all those years with R, I have found very little use for 'raw' outside of serialization. ] | For example, is it possible to go from int/char to raw using Rcpp? Or is the Rcpp is a priori for mapping R types to the closest corresponding C++ types. So R 'raw' to Rcpp 'RawVector'. The conversion from raw to unsigned char is not something R does so Rcpp does not immediately spring to mind either. R has fewer basic types than C++ as the signed/unsigned duality does not exist, and for numeric types R only knows one precision. So Rcpp can't really translate between all combinations. | recommended way to use unsigned char to go outside Rcpp as Tim suggested? You can do that. Once you have a C++ object (and know its storage type), you can operate on it via standard casts. That said, Knuth's dictum about premature optmisation comes to mind. I'd try to get it working first, and only then worry about efficiency. Dirk ? | Again, thanks for the input, | | Gustaf | | | On 2014-10-21 10:27, Tim Keitt wrote: | | | | On Mon, Oct 20, 2014 at 2:17 PM, Gustaf Granath | wrote: | | Hi | Im trying to use some C++ functions in R. However, these functions are | build around unsigned char* variables (1D array). I have for example a | large matrix in R that represents black (e.g. 1-bit image, 0 and 1s). I | cant find a solution to convert a character vector into unsigned char* | within Rcpp. Im new to Rcpp and C++ so I might have missed something | obvious here. Please direct me to resources on this topic (google did | not help much). | | A start: | | SEXP test(SEXP cM){ | ? CharacterVector Vc(cM); | ? int n = Vr.size(); | ? RawVector x(n); //is this the same as unsigned char* ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? //I tried to fill it with | char*(Mr) but I didnt succeed | } | | | I tend to go through the standard library as its less of a black box. Try | creating a std::string and appending your chars to that string. Then call | obj.c_str() to get the C-style array of chars. Or push the chars onto a | std::vector and do something like &obj[0] to get a 1-D array. | | THK | ? | | | Thanks, | | Gustaf | | -- | Gustaf Granath (PhD) | Post doc | McMaster University | School of Geography & Earth Sciences | | _______________________________________________ | Rcpp-devel mailing list | Rcpp-devel at lists.r-forge.r-project.org | https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel | | | | | -- | http://www.keittlab.org/ | | | -- | Gustaf Granath (PhD) | Post doc | McMaster University | School of Geography & Earth Sciences | -- http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org From luckyrand at gmail.com Wed Oct 22 03:22:23 2014 From: luckyrand at gmail.com (Chenliang Xu) Date: Tue, 21 Oct 2014 20:22:23 -0500 Subject: [Rcpp-devel] inplace modification more affect other varibles Message-ID: Hello, With the following inplace sorting example, I understand the value of `a` is sorted inplace, but it's strange to see the value of `b` is also modified. This can cause some hard to detect bug, since the cpp function may modify a variable defined in other scope. It seems that rcpp doesn't respect the named field, which is adopted by R to implement copy-on-modify. I don's see an easy fix on C++ side, since the called cpp function has no information about variable binding in R. A possible fix is adding a function `inplace` to R, which ensure the returned variable has named filed = 0 so is safe to modify inplace. Then, we have to call the function as `stl_sort_inplace(inplace(a))`, which seems odd but is also informative. It shows clearly that we are breaking the pass-by-value rule in R. ```cpp #include using namespace Rcpp; // [[Rcpp::export]] void stl_sort_inplace(NumericVector x) { std::sort(x.begin(), x.end()); } ``` ```r a <- seq(1, 0.1, -0.1) b <- a # [1] 1.0 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 stl_sort_inplace(a) a # [1] 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 b # [1] 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 a <- seq(1, 0.1, -0.1) pure_function <- function (x) { y <- x stl_sort_inplace(y) print(y) } pure_function(a) a # [1] 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 ``` -------------- next part -------------- An HTML attachment was scrubbed... URL: From edd at debian.org Wed Oct 22 03:31:27 2014 From: edd at debian.org (Dirk Eddelbuettel) Date: Tue, 21 Oct 2014 20:31:27 -0500 Subject: [Rcpp-devel] inplace modification more affect other varibles In-Reply-To: References: Message-ID: <21575.2287.76329.869725@max.nulle.part> On 21 October 2014 at 20:22, Chenliang Xu wrote: | Hello, | | With the following inplace sorting example, I understand the value of `a` is | sorted inplace, but it's strange to see the value of `b` is also modified. This | can cause some hard to detect bug, since the cpp function may modify a variable | defined in other scope. Very well known issue -- maybe do a search for 'Rcpp::clone' ... In a nutshell, SEXP objects are passed by a __pointer__ and changes do therefore persist. If you want distinct copies, use Rcpp::clone(). Dirk | It seems that rcpp doesn't respect the named field, which is adopted by R to | implement?copy-on-modify. I don's see an easy fix on C++ side, since the called | cpp function has no information about variable binding in R. A possible fix is | adding a function `inplace` to R, which ensure the returned variable has named | filed = 0 so is safe to modify inplace. Then, we have to call the function as | `stl_sort_inplace(inplace(a))`, which seems odd but is also informative. It | shows clearly that we are breaking the pass-by-value rule in R. | | ```cpp | #include | using namespace Rcpp; | | // [[Rcpp::export]] | void stl_sort_inplace(NumericVector x) { | ? ? std::sort(x.begin(), x.end()); | } | | ``` | | ```r | a <- seq(1, 0.1, -0.1) | b <- a | # ?[1] 1.0 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 | | stl_sort_inplace(a) | | a | # ?[1] 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 | | b | #??[1] 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 | | a <- seq(1, 0.1, -0.1) | pure_function <- function (x) { | ? y <- x | ? stl_sort_inplace(y) | ? print(y) | } | pure_function(a) | a | # ?[1] 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 | | ``` | | _______________________________________________ | Rcpp-devel mailing list | Rcpp-devel at lists.r-forge.r-project.org | https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel -- http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org From luckyrand at gmail.com Wed Oct 22 04:13:35 2014 From: luckyrand at gmail.com (Chenliang Xu) Date: Tue, 21 Oct 2014 21:13:35 -0500 Subject: [Rcpp-devel] inplace modification more affect other varibles In-Reply-To: <21575.2287.76329.869725@max.nulle.part> References: <21575.2287.76329.869725@max.nulle.part> Message-ID: Hi Dirk, Thanks for your quick answer. I don't think Rcpp::clone is what I was looking for. I know `stl_sort_inplace(a)` modify the value of `a`, but it surprise me to see it modify `b`. And it may modify some other variables c, d, e, f..., and it's hard to know which variables point to the same place. On Tue, Oct 21, 2014 at 8:31 PM, Dirk Eddelbuettel wrote: > > On 21 October 2014 at 20:22, Chenliang Xu wrote: > | Hello, > | > | With the following inplace sorting example, I understand the value of > `a` is > | sorted inplace, but it's strange to see the value of `b` is also > modified. This > | can cause some hard to detect bug, since the cpp function may modify a > variable > | defined in other scope. > > Very well known issue -- maybe do a search for 'Rcpp::clone' ... > > In a nutshell, SEXP objects are passed by a __pointer__ and changes do > therefore persist. If you want distinct copies, use Rcpp::clone(). > > Dirk > > | It seems that rcpp doesn't respect the named field, which is adopted by > R to > | implement copy-on-modify. I don's see an easy fix on C++ side, since the > called > | cpp function has no information about variable binding in R. A possible > fix is > | adding a function `inplace` to R, which ensure the returned variable has > named > | filed = 0 so is safe to modify inplace. Then, we have to call the > function as > | `stl_sort_inplace(inplace(a))`, which seems odd but is also informative. > It > | shows clearly that we are breaking the pass-by-value rule in R. > | > | ```cpp > | #include > | using namespace Rcpp; > | > | // [[Rcpp::export]] > | void stl_sort_inplace(NumericVector x) { > | std::sort(x.begin(), x.end()); > | } > | > | ``` > | > | ```r > | a <- seq(1, 0.1, -0.1) > | b <- a > | # [1] 1.0 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 > | > | stl_sort_inplace(a) > | > | a > | # [1] 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 > | > | b > | # [1] 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 > | > | a <- seq(1, 0.1, -0.1) > | pure_function <- function (x) { > | y <- x > | stl_sort_inplace(y) > | print(y) > | } > | pure_function(a) > | a > | # [1] 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 > | > | ``` > | > | _______________________________________________ > | Rcpp-devel mailing list > | Rcpp-devel at lists.r-forge.r-project.org > | https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel > > -- > http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From romain at r-enthusiasts.com Wed Oct 22 15:24:53 2014 From: romain at r-enthusiasts.com (Romain Francois) Date: Wed, 22 Oct 2014 15:24:53 +0200 Subject: [Rcpp-devel] inplace modification more affect other varibles In-Reply-To: References: <21575.2287.76329.869725@max.nulle.part> Message-ID: <5584B5A2-988F-42EA-AAFF-20D4A8C83608@r-enthusiasts.com> a and b are the same object: > a <- seq(1, 0.1, -0.1) > b <- a > pryr::address( a ) [1] "0x7f9504534948" > pryr::address( b ) [1] "0x7f9504534948" So clone is what you need here. Implementing copy on write for that kind of example is possible, but would require a lot of additional code, i.e. the iterator would need to handle the write operation. An undesirable side effect of this is that such iterators would be quite less performant, right now Rcpp is close to the metal and uses direct pointers as iterators when it makes sense. A price that everyone would have to pay. no go. Instead, the responsibility is given to the user to clone explicitly when changes will be made to the underlying object. Romain > Le 22 oct. 2014 ? 04:13, Chenliang Xu a ?crit : > > Hi Dirk, > > Thanks for your quick answer. I don't think Rcpp::clone is what I was looking for. I know `stl_sort_inplace(a)` modify the value of `a`, but it surprise me to see it modify `b`. And it may modify some other variables c, d, e, f..., and it's hard to know which variables point to the same place. > > On Tue, Oct 21, 2014 at 8:31 PM, Dirk Eddelbuettel > wrote: > > On 21 October 2014 at 20:22, Chenliang Xu wrote: > | Hello, > | > | With the following inplace sorting example, I understand the value of `a` is > | sorted inplace, but it's strange to see the value of `b` is also modified. This > | can cause some hard to detect bug, since the cpp function may modify a variable > | defined in other scope. > > Very well known issue -- maybe do a search for 'Rcpp::clone' ... > > In a nutshell, SEXP objects are passed by a __pointer__ and changes do > therefore persist. If you want distinct copies, use Rcpp::clone(). > > Dirk > > | It seems that rcpp doesn't respect the named field, which is adopted by R to > | implement copy-on-modify. I don's see an easy fix on C++ side, since the called > | cpp function has no information about variable binding in R. A possible fix is > | adding a function `inplace` to R, which ensure the returned variable has named > | filed = 0 so is safe to modify inplace. Then, we have to call the function as > | `stl_sort_inplace(inplace(a))`, which seems odd but is also informative. It > | shows clearly that we are breaking the pass-by-value rule in R. > | > | ```cpp > | #include > | using namespace Rcpp; > | > | // [[Rcpp::export]] > | void stl_sort_inplace(NumericVector x) { > | std::sort(x.begin(), x.end()); > | } > | > | ``` > | > | ```r > | a <- seq(1, 0.1, -0.1) > | b <- a > | # [1] 1.0 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 > | > | stl_sort_inplace(a) > | > | a > | # [1] 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 > | > | b > | # [1] 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 > | > | a <- seq(1, 0.1, -0.1) > | pure_function <- function (x) { > | y <- x > | stl_sort_inplace(y) > | print(y) > | } > | pure_function(a) > | a > | # [1] 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 > | > | ``` > | > | _______________________________________________ > | Rcpp-devel mailing list > | Rcpp-devel at lists.r-forge.r-project.org > | https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel > > -- > http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org > > _______________________________________________ > Rcpp-devel mailing list > Rcpp-devel at lists.r-forge.r-project.org > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From luckyrand at gmail.com Wed Oct 22 17:53:01 2014 From: luckyrand at gmail.com (Chenliang Xu) Date: Wed, 22 Oct 2014 10:53:01 -0500 Subject: [Rcpp-devel] inplace modification more affect other varibles In-Reply-To: <5584B5A2-988F-42EA-AAFF-20D4A8C83608@r-enthusiasts.com> References: <21575.2287.76329.869725@max.nulle.part> <5584B5A2-988F-42EA-AAFF-20D4A8C83608@r-enthusiasts.com> Message-ID: Thanks a lot! Does that mean we should never modify an argument passed from R to cpp? On Wed, Oct 22, 2014 at 8:24 AM, Romain Francois wrote: > a and b are the same object: > > > a <- seq(1, 0.1, -0.1) > > b <- a > > pryr::address( a ) > [1] "0x7f9504534948" > > pryr::address( b ) > [1] "0x7f9504534948" > > So clone is what you need here. > > Implementing copy on write for that kind of example is possible, but would > require a lot of additional code, i.e. the iterator would need to handle > the write operation. > > An undesirable side effect of this is that such iterators would be quite > less performant, right now Rcpp is close to the metal and uses direct > pointers as iterators when it makes sense. A price that everyone would have > to pay. no go. > > Instead, the responsibility is given to the user to clone explicitly when > changes will be made to the underlying object. > > Romain > > > Le 22 oct. 2014 ? 04:13, Chenliang Xu a ?crit : > > Hi Dirk, > > Thanks for your quick answer. I don't think Rcpp::clone is what I was > looking for. I know `stl_sort_inplace(a)` modify the value of `a`, but it > surprise me to see it modify `b`. And it may modify some other variables c, > d, e, f..., and it's hard to know which variables point to the same place. > > On Tue, Oct 21, 2014 at 8:31 PM, Dirk Eddelbuettel wrote: > >> >> On 21 October 2014 at 20:22, Chenliang Xu wrote: >> | Hello, >> | >> | With the following inplace sorting example, I understand the value of >> `a` is >> | sorted inplace, but it's strange to see the value of `b` is also >> modified. This >> | can cause some hard to detect bug, since the cpp function may modify a >> variable >> | defined in other scope. >> >> Very well known issue -- maybe do a search for 'Rcpp::clone' ... >> >> In a nutshell, SEXP objects are passed by a __pointer__ and changes do >> therefore persist. If you want distinct copies, use Rcpp::clone(). >> >> Dirk >> >> | It seems that rcpp doesn't respect the named field, which is adopted by >> R to >> | implement copy-on-modify. I don's see an easy fix on C++ side, since >> the called >> | cpp function has no information about variable binding in R. A possible >> fix is >> | adding a function `inplace` to R, which ensure the returned variable >> has named >> | filed = 0 so is safe to modify inplace. Then, we have to call the >> function as >> | `stl_sort_inplace(inplace(a))`, which seems odd but is also >> informative. It >> | shows clearly that we are breaking the pass-by-value rule in R. >> | >> | ```cpp >> | #include >> | using namespace Rcpp; >> | >> | // [[Rcpp::export]] >> | void stl_sort_inplace(NumericVector x) { >> | std::sort(x.begin(), x.end()); >> | } >> | >> | ``` >> | >> | ```r >> | a <- seq(1, 0.1, -0.1) >> | b <- a >> | # [1] 1.0 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 >> | >> | stl_sort_inplace(a) >> | >> | a >> | # [1] 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 >> | >> | b >> | # [1] 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 >> | >> | a <- seq(1, 0.1, -0.1) >> | pure_function <- function (x) { >> | y <- x >> | stl_sort_inplace(y) >> | print(y) >> | } >> | pure_function(a) >> | a >> | # [1] 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 >> | >> | ``` >> | >> | _______________________________________________ >> | Rcpp-devel mailing list >> | Rcpp-devel at lists.r-forge.r-project.org >> | https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel >> >> -- >> http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org >> > > _______________________________________________ > Rcpp-devel mailing list > Rcpp-devel at lists.r-forge.r-project.org > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From romain at r-enthusiasts.com Wed Oct 22 18:32:32 2014 From: romain at r-enthusiasts.com (Romain Francois) Date: Wed, 22 Oct 2014 18:32:32 +0200 Subject: [Rcpp-devel] inplace modification more affect other varibles In-Reply-To: References: <21575.2287.76329.869725@max.nulle.part> <5584B5A2-988F-42EA-AAFF-20D4A8C83608@r-enthusiasts.com> Message-ID: <00AB22AF-5158-4229-9B93-A8CF2EBDFC96@r-enthusiasts.com> Pretty much. But sometimes that's what you want, and Rcpp does not get in the way. You just have to know the rules of the game. BTW, same rules apply when you use .Call C/R API, you are in charge of making the copy when it's needed. Romain > Le 22 oct. 2014 ? 17:53, Chenliang Xu a ?crit : > > Thanks a lot! > > Does that mean we should never modify an argument passed from R to cpp? > > On Wed, Oct 22, 2014 at 8:24 AM, Romain Francois > wrote: > a and b are the same object: > > > a <- seq(1, 0.1, -0.1) > > b <- a > > pryr::address( a ) > [1] "0x7f9504534948" > > pryr::address( b ) > [1] "0x7f9504534948" > > So clone is what you need here. > > Implementing copy on write for that kind of example is possible, but would require a lot of additional code, i.e. the iterator would need to handle the write operation. > > An undesirable side effect of this is that such iterators would be quite less performant, right now Rcpp is close to the metal and uses direct pointers as iterators when it makes sense. A price that everyone would have to pay. no go. > > Instead, the responsibility is given to the user to clone explicitly when changes will be made to the underlying object. > > Romain > > >> Le 22 oct. 2014 ? 04:13, Chenliang Xu > a ?crit : >> >> Hi Dirk, >> >> Thanks for your quick answer. I don't think Rcpp::clone is what I was looking for. I know `stl_sort_inplace(a)` modify the value of `a`, but it surprise me to see it modify `b`. And it may modify some other variables c, d, e, f..., and it's hard to know which variables point to the same place. >> >> On Tue, Oct 21, 2014 at 8:31 PM, Dirk Eddelbuettel > wrote: >> >> On 21 October 2014 at 20:22, Chenliang Xu wrote: >> | Hello, >> | >> | With the following inplace sorting example, I understand the value of `a` is >> | sorted inplace, but it's strange to see the value of `b` is also modified. This >> | can cause some hard to detect bug, since the cpp function may modify a variable >> | defined in other scope. >> >> Very well known issue -- maybe do a search for 'Rcpp::clone' ... >> >> In a nutshell, SEXP objects are passed by a __pointer__ and changes do >> therefore persist. If you want distinct copies, use Rcpp::clone(). >> >> Dirk >> >> | It seems that rcpp doesn't respect the named field, which is adopted by R to >> | implement copy-on-modify. I don's see an easy fix on C++ side, since the called >> | cpp function has no information about variable binding in R. A possible fix is >> | adding a function `inplace` to R, which ensure the returned variable has named >> | filed = 0 so is safe to modify inplace. Then, we have to call the function as >> | `stl_sort_inplace(inplace(a))`, which seems odd but is also informative. It >> | shows clearly that we are breaking the pass-by-value rule in R. >> | >> | ```cpp >> | #include >> | using namespace Rcpp; >> | >> | // [[Rcpp::export]] >> | void stl_sort_inplace(NumericVector x) { >> | std::sort(x.begin(), x.end()); >> | } >> | >> | ``` >> | >> | ```r >> | a <- seq(1, 0.1, -0.1) >> | b <- a >> | # [1] 1.0 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 >> | >> | stl_sort_inplace(a) >> | >> | a >> | # [1] 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 >> | >> | b >> | # [1] 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 >> | >> | a <- seq(1, 0.1, -0.1) >> | pure_function <- function (x) { >> | y <- x >> | stl_sort_inplace(y) >> | print(y) >> | } >> | pure_function(a) >> | a >> | # [1] 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 >> | >> | ``` >> | >> | _______________________________________________ >> | Rcpp-devel mailing list >> | Rcpp-devel at lists.r-forge.r-project.org >> | https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel >> >> -- >> http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org >> >> _______________________________________________ >> Rcpp-devel mailing list >> Rcpp-devel at lists.r-forge.r-project.org >> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel > > _______________________________________________ > Rcpp-devel mailing list > Rcpp-devel at lists.r-forge.r-project.org > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggrothendieck at gmail.com Wed Oct 22 18:40:05 2014 From: ggrothendieck at gmail.com (Gabor Grothendieck) Date: Wed, 22 Oct 2014 12:40:05 -0400 Subject: [Rcpp-devel] inplace modification more affect other varibles In-Reply-To: References: Message-ID: On Tue, Oct 21, 2014 at 9:22 PM, Chenliang Xu wrote: > Hello, > > With the following inplace sorting example, I understand the value of `a` is > sorted inplace, but it's strange to see the value of `b` is also modified. > This can cause some hard to detect bug, since the cpp function may modify a > variable defined in other scope. > > It seems that rcpp doesn't respect the named field, which is adopted by R to > implement copy-on-modify. I don's see an easy fix on C++ side, since the > called cpp function has no information about variable binding in R. A > possible fix is adding a function `inplace` to R, which ensure the returned > variable has named filed = 0 so is safe to modify inplace. Then, we have to > call the function as `stl_sort_inplace(inplace(a))`, which seems odd but is > also informative. It shows clearly that we are breaking the pass-by-value > rule in R. > > ```cpp > #include > using namespace Rcpp; > > // [[Rcpp::export]] > void stl_sort_inplace(NumericVector x) { > std::sort(x.begin(), x.end()); > } > > ``` > > ```r > a <- seq(1, 0.1, -0.1) > b <- a > # [1] 1.0 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 > > stl_sort_inplace(a) > > a > # [1] 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 > > b > # [1] 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 > > a <- seq(1, 0.1, -0.1) > pure_function <- function (x) { > y <- x > stl_sort_inplace(y) > print(y) > } > pure_function(a) > a > # [1] 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 > This is common among C++ software called by R that modifies R objects in place. For example, below DT2 is modified: > library(data.table) ...junk... > DT <- data.table(a = 1:3) > DT2 <- DT > DT[, b:=a] > DT2 a b 1: 1 1 2: 2 2 3: 3 3 From russell.n2012 at gmail.com Wed Oct 22 19:39:50 2014 From: russell.n2012 at gmail.com (nate russell) Date: Wed, 22 Oct 2014 13:39:50 -0400 Subject: [Rcpp-devel] dyn.load error with particular functor Message-ID: Hello, I am running into the "Error in dyn.load [...] unable to load shared object ['/tmp/...'] undefined symbol [_...]" error; however it is only happening with one particular Rcpp function, which I find puzzling. Here is my .cpp file containing two functions - I can compile the first one without any issue (in its own file), but the second brings about the noted error message: #include #include #include #include // [[Rcpp::plugins(cpp11)]] /* * Works fine. */ struct checkTwo { public: checkTwo(const std::string& s1_, const std::string& s2_) : s1(s1_), s2(s2_) {} int operator() (std::string x1, std::string x2) { return (s1==x1 && s2==x2 ? 1 : 0); } private: std::string s1; std::string s2; }; // [[Rcpp::export]] int count_if_if(const Rcpp::DataFrame& df, const std::string& c1, const std::string& c2) { std::vector vc1 = df["C1"]; std::vector vc2 = df["C2"]; int N = df.nrows(); std::vector vcount; vcount.resize( N ); std::transform(vc1.begin(),vc1.end(),vc2.begin(),vcount.begin(),checkTwo(c1,c2)); int total = std::accumulate(vcount.begin(),vcount.end(),0); return total; } /* * Does not compile. */ struct trackIdx { public: trackIdx(const std::string& s1_, const std::string& s2_) : s1(s1_),s2(s2_) {} int operator() (std::string x1, std::string x2) { tracker++; return ((s1==x1 && s2==x2) ? (tracker-1) : -1); } private: std::string s1; std::string s2; static int tracker; }; // [[Rcpp::export]] std::vector mc_index(const Rcpp::DataFrame& df, const std::string& c1, const std::string& c2) { std::vector vc1 = df["C1"]; std::vector vc2 = df["C2"]; int N = df.nrows(); std::vector vcount; vcount.resize( N ); std::vector result; result.resize( N ); std::transform(vc1.begin(),vc1.end(),vc2.begin(),vcount.begin(),trackIdx(c1,c2)); std::copy_if(vcount.begin(),vcount.end(),result.begin(), [](int i) -> bool { return !(i<0); }); return result; } The above functions (only "count_if_if" at the moment) can be tested like this: Df <- data.frame( C1=rep(LETTERS[1:4],each=15), C2=as.character(rep(rep(1:3,each=5),4)), C3=rep(rep(1:3,each=5),4), stringsAsFactors=FALSE) ## count_if_if(Df,"B","3") ## # mc_index(Df,"B","3") The exact error message I am getting is: Error in dyn.load("/tmp/Rtmpw7VSkV/sourcecpp_27046ca49cd4/sourceCpp_67600.so") : unable to load shared object '/tmp/Rtmpw7VSkV/sourcecpp_27046ca49cd4/sourceCpp_67600.so': /tmp/Rtmpw7VSkV/sourcecpp_27046ca49cd4/sourceCpp_67600.so: undefined symbol: _ZN8trackIdx7trackerE and judging by the last bit, "undefined symbol: _ZN8trackIdx7trackerE", it looks like my "trackIdx" function object is the source of the problem. I have tested this on two different platforms - my network server running CentOS 7: R version 3.1.1 Platform: x86_64-redhat-linux-gnu (64-bit) Rcpp_0.11.3 and my laptop running Ubuntu 14.04: R version 3.0.2 Platform: x86_64-pc-linux-gnu (64-bit) Rcpp_0.11.2 Both of these machines use a reasonably up-to-date version of g++ that supports c++11 (although I don't think this has anything to do with the issue). I have never had any problems compiling Rcpp functions on either of these platforms, yet the second function object & Rcpp function above produce the same error on each machine. If anyone can explain what is going wrong and/or suggest how to correct the problem with the above code I would appreciate it very much. Thank you, Nathan Russell -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattw at trdlnk.com Wed Oct 22 20:10:37 2014 From: mattw at trdlnk.com (Matthew Wright) Date: Wed, 22 Oct 2014 13:10:37 -0500 Subject: [Rcpp-devel] dyn.load error with particular functor In-Reply-To: References: Message-ID: Nate, The problem here is how you are have implemented your static member of trackIdx. You only declared it. I'd suggest one of two alternatives: // add this below the struct declaration. int trackIdx::tracker = 0; Or, just create it in the function where you actually use it instead of making it a member. int operator() (std::string x1, std::string x2) { static int tracker; tracker++; return ((s1==x1 && s2==x2) ? (tracker-1) : -1); } On Wed, Oct 22, 2014 at 12:39 PM, nate russell wrote: > Hello, > > I am running into the "Error in dyn.load [...] unable to load shared > object ['/tmp/...'] undefined symbol [_...]" error; however it is only > happening with one particular Rcpp function, which I find puzzling. Here is > my .cpp file containing two functions - I can compile the first one without > any issue (in its own file), but the second brings about the noted error > message: > > > #include > #include > #include > #include > // [[Rcpp::plugins(cpp11)]] > > /* > * Works fine. > */ > > struct checkTwo { > public: > checkTwo(const std::string& s1_, const std::string& s2_) > : s1(s1_), s2(s2_) {} > int operator() (std::string x1, std::string x2) { > return (s1==x1 && s2==x2 ? 1 : 0); > } > private: > std::string s1; > std::string s2; > }; > > // [[Rcpp::export]] > int count_if_if(const Rcpp::DataFrame& df, > const std::string& c1, > const std::string& c2) > { > std::vector vc1 = df["C1"]; > std::vector vc2 = df["C2"]; > int N = df.nrows(); > > std::vector vcount; > vcount.resize( N ); > > > std::transform(vc1.begin(),vc1.end(),vc2.begin(),vcount.begin(),checkTwo(c1,c2)); > int total = std::accumulate(vcount.begin(),vcount.end(),0); > > return total; > } > > /* > * Does not compile. > */ > > struct trackIdx { > public: > trackIdx(const std::string& s1_, const std::string& s2_) > : s1(s1_),s2(s2_) {} > int operator() (std::string x1, std::string x2) { > tracker++; > return ((s1==x1 && s2==x2) ? (tracker-1) : -1); > } > private: > std::string s1; > std::string s2; > static int tracker; > }; > > // [[Rcpp::export]] > std::vector mc_index(const Rcpp::DataFrame& df, > const std::string& c1, > const std::string& c2) > { > std::vector vc1 = df["C1"]; > std::vector vc2 = df["C2"]; > int N = df.nrows(); > > std::vector vcount; > vcount.resize( N ); > > std::vector result; > result.resize( N ); > > > std::transform(vc1.begin(),vc1.end(),vc2.begin(),vcount.begin(),trackIdx(c1,c2)); > std::copy_if(vcount.begin(),vcount.end(),result.begin(), > [](int i) -> bool { > return !(i<0); > }); > > return result; > } > > > The above functions (only "count_if_if" at the moment) can be tested like > this: > > Df <- data.frame( > C1=rep(LETTERS[1:4],each=15), > C2=as.character(rep(rep(1:3,each=5),4)), > C3=rep(rep(1:3,each=5),4), > stringsAsFactors=FALSE) > ## > count_if_if(Df,"B","3") > ## > # mc_index(Df,"B","3") > > > > The exact error message I am getting is: > > Error in > dyn.load("/tmp/Rtmpw7VSkV/sourcecpp_27046ca49cd4/sourceCpp_67600.so") : > unable to load shared object > '/tmp/Rtmpw7VSkV/sourcecpp_27046ca49cd4/sourceCpp_67600.so': > /tmp/Rtmpw7VSkV/sourcecpp_27046ca49cd4/sourceCpp_67600.so: undefined > symbol: _ZN8trackIdx7trackerE > > > and judging by the last bit, "undefined symbol: _ZN8trackIdx7trackerE", it > looks like my "trackIdx" function object is the source of the problem. > > I have tested this on two different platforms - > > my network server running CentOS 7: > > R version 3.1.1 > Platform: x86_64-redhat-linux-gnu (64-bit) > Rcpp_0.11.3 > > > and my laptop running Ubuntu 14.04: > > R version 3.0.2 > Platform: x86_64-pc-linux-gnu (64-bit) > Rcpp_0.11.2 > > > Both of these machines use a reasonably up-to-date version of g++ that > supports c++11 (although I don't think this has anything to do with the > issue). I have never had any problems compiling Rcpp functions on either of > these platforms, yet the second function object & Rcpp function above > produce the same error on each machine. If anyone can explain what is going > wrong and/or suggest how to correct the problem with the above code I would > appreciate it very much. > > Thank you, > Nathan Russell > > > > > > > _______________________________________________ > Rcpp-devel mailing list > Rcpp-devel at lists.r-forge.r-project.org > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel > -- ------------------------- Matt Wright 312-264-2987 (p) 312-479-6821 (m) -------------- next part -------------- An HTML attachment was scrubbed... URL: From luckyrand at gmail.com Wed Oct 22 20:13:29 2014 From: luckyrand at gmail.com (Chenliang Xu) Date: Wed, 22 Oct 2014 13:13:29 -0500 Subject: [Rcpp-devel] inplace modification more affect other varibles In-Reply-To: References: Message-ID: Thanks a lot! I thought that was a bug of data.table, when I tried to learn data.table. Obviously, I was wrong. It's a feature of data.table, in which all set functions change their input by reference. It also provide function copy when a copy is needed. Based on suggestion from Romain, I may just stay on the safe side and do not modify argument passed to C++ from R. The users of data.table should be aware of that data.table object is passed by reference, and call function copy when needed. For other R objects, it seems cause too much trouble. It's hard to detect variables pointing to the same place and I don't want to provide a copy function. On Wed, Oct 22, 2014 at 11:40 AM, Gabor Grothendieck < ggrothendieck at gmail.com> wrote: > On Tue, Oct 21, 2014 at 9:22 PM, Chenliang Xu wrote: > > Hello, > > > > With the following inplace sorting example, I understand the value of > `a` is > > sorted inplace, but it's strange to see the value of `b` is also > modified. > > This can cause some hard to detect bug, since the cpp function may > modify a > > variable defined in other scope. > > > > It seems that rcpp doesn't respect the named field, which is adopted by > R to > > implement copy-on-modify. I don's see an easy fix on C++ side, since the > > called cpp function has no information about variable binding in R. A > > possible fix is adding a function `inplace` to R, which ensure the > returned > > variable has named filed = 0 so is safe to modify inplace. Then, we have > to > > call the function as `stl_sort_inplace(inplace(a))`, which seems odd but > is > > also informative. It shows clearly that we are breaking the pass-by-value > > rule in R. > > > > ```cpp > > #include > > using namespace Rcpp; > > > > // [[Rcpp::export]] > > void stl_sort_inplace(NumericVector x) { > > std::sort(x.begin(), x.end()); > > } > > > > ``` > > > > ```r > > a <- seq(1, 0.1, -0.1) > > b <- a > > # [1] 1.0 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 > > > > stl_sort_inplace(a) > > > > a > > # [1] 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 > > > > b > > # [1] 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 > > > > a <- seq(1, 0.1, -0.1) > > pure_function <- function (x) { > > y <- x > > stl_sort_inplace(y) > > print(y) > > } > > pure_function(a) > > a > > # [1] 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 > > > > This is common among C++ software called by R that modifies R objects > in place. For example, below DT2 is modified: > > > library(data.table) > ...junk... > > DT <- data.table(a = 1:3) > > DT2 <- DT > > DT[, b:=a] > > DT2 > a b > 1: 1 1 > 2: 2 2 > 3: 3 3 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From russell.n2012 at gmail.com Wed Oct 22 20:29:46 2014 From: russell.n2012 at gmail.com (nate russell) Date: Wed, 22 Oct 2014 14:29:46 -0400 Subject: [Rcpp-devel] dyn.load error with particular functor In-Reply-To: References: Message-ID: Matthew, Thank you for such a quick response; both of those suggestions worked perfectly. Out of curiosity, is there any reason to use one of these implementations over the other - or are they essentially equivalent? Regards, Nathan Russell On Wed, Oct 22, 2014 at 2:10 PM, Matthew Wright wrote: > Nate, > > The problem here is how you are have implemented your static member of > trackIdx. You only declared it. > > I'd suggest one of two alternatives: > > // add this below the struct declaration. > int trackIdx::tracker = 0; > > Or, just create it in the function where you actually use it instead of > making it a member. > int operator() (std::string x1, std::string x2) { > static int tracker; > tracker++; > return ((s1==x1 && s2==x2) ? (tracker-1) : -1); > } > > > > On Wed, Oct 22, 2014 at 12:39 PM, nate russell > wrote: > >> Hello, >> >> I am running into the "Error in dyn.load [...] unable to load shared >> object ['/tmp/...'] undefined symbol [_...]" error; however it is only >> happening with one particular Rcpp function, which I find puzzling. Here is >> my .cpp file containing two functions - I can compile the first one without >> any issue (in its own file), but the second brings about the noted error >> message: >> >> >> #include >> #include >> #include >> #include >> // [[Rcpp::plugins(cpp11)]] >> >> /* >> * Works fine. >> */ >> >> struct checkTwo { >> public: >> checkTwo(const std::string& s1_, const std::string& s2_) >> : s1(s1_), s2(s2_) {} >> int operator() (std::string x1, std::string x2) { >> return (s1==x1 && s2==x2 ? 1 : 0); >> } >> private: >> std::string s1; >> std::string s2; >> }; >> >> // [[Rcpp::export]] >> int count_if_if(const Rcpp::DataFrame& df, >> const std::string& c1, >> const std::string& c2) >> { >> std::vector vc1 = df["C1"]; >> std::vector vc2 = df["C2"]; >> int N = df.nrows(); >> >> std::vector vcount; >> vcount.resize( N ); >> >> >> std::transform(vc1.begin(),vc1.end(),vc2.begin(),vcount.begin(),checkTwo(c1,c2)); >> int total = std::accumulate(vcount.begin(),vcount.end(),0); >> >> return total; >> } >> >> /* >> * Does not compile. >> */ >> >> struct trackIdx { >> public: >> trackIdx(const std::string& s1_, const std::string& s2_) >> : s1(s1_),s2(s2_) {} >> int operator() (std::string x1, std::string x2) { >> tracker++; >> return ((s1==x1 && s2==x2) ? (tracker-1) : -1); >> } >> private: >> std::string s1; >> std::string s2; >> static int tracker; >> }; >> >> // [[Rcpp::export]] >> std::vector mc_index(const Rcpp::DataFrame& df, >> const std::string& c1, >> const std::string& c2) >> { >> std::vector vc1 = df["C1"]; >> std::vector vc2 = df["C2"]; >> int N = df.nrows(); >> >> std::vector vcount; >> vcount.resize( N ); >> >> std::vector result; >> result.resize( N ); >> >> >> std::transform(vc1.begin(),vc1.end(),vc2.begin(),vcount.begin(),trackIdx(c1,c2)); >> std::copy_if(vcount.begin(),vcount.end(),result.begin(), >> [](int i) -> bool { >> return !(i<0); >> }); >> >> return result; >> } >> >> >> The above functions (only "count_if_if" at the moment) can be tested like >> this: >> >> Df <- data.frame( >> C1=rep(LETTERS[1:4],each=15), >> C2=as.character(rep(rep(1:3,each=5),4)), >> C3=rep(rep(1:3,each=5),4), >> stringsAsFactors=FALSE) >> ## >> count_if_if(Df,"B","3") >> ## >> # mc_index(Df,"B","3") >> >> >> >> The exact error message I am getting is: >> >> Error in >> dyn.load("/tmp/Rtmpw7VSkV/sourcecpp_27046ca49cd4/sourceCpp_67600.so") : >> unable to load shared object >> '/tmp/Rtmpw7VSkV/sourcecpp_27046ca49cd4/sourceCpp_67600.so': >> /tmp/Rtmpw7VSkV/sourcecpp_27046ca49cd4/sourceCpp_67600.so: undefined >> symbol: _ZN8trackIdx7trackerE >> >> >> and judging by the last bit, "undefined symbol: _ZN8trackIdx7trackerE", >> it looks like my "trackIdx" function object is the source of the problem. >> >> I have tested this on two different platforms - >> >> my network server running CentOS 7: >> >> R version 3.1.1 >> Platform: x86_64-redhat-linux-gnu (64-bit) >> Rcpp_0.11.3 >> >> >> and my laptop running Ubuntu 14.04: >> >> R version 3.0.2 >> Platform: x86_64-pc-linux-gnu (64-bit) >> Rcpp_0.11.2 >> >> >> Both of these machines use a reasonably up-to-date version of g++ that >> supports c++11 (although I don't think this has anything to do with the >> issue). I have never had any problems compiling Rcpp functions on either of >> these platforms, yet the second function object & Rcpp function above >> produce the same error on each machine. If anyone can explain what is going >> wrong and/or suggest how to correct the problem with the above code I would >> appreciate it very much. >> >> Thank you, >> Nathan Russell >> >> >> >> >> >> >> _______________________________________________ >> Rcpp-devel mailing list >> Rcpp-devel at lists.r-forge.r-project.org >> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel >> > > > > -- > ------------------------- > Matt Wright > 312-264-2987 (p) > 312-479-6821 (m) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From russell.n2012 at gmail.com Wed Oct 22 21:03:23 2014 From: russell.n2012 at gmail.com (nate russell) Date: Wed, 22 Oct 2014 15:03:23 -0400 Subject: [Rcpp-devel] dyn.load error with particular functor In-Reply-To: References: Message-ID: Just for the sake of completeness, I noticed that the value of trackIdx::tracker was persisting (and therefore continuing to be incremented) between function calls with mc_index, so in addition to your first suggestion, I added a member function to reset the value to zero, and everything seems to be working smoothly. Once again, thank you for your help. Nathan Russell #include #include #include #include // [[Rcpp::plugins(cpp11)]] class trackIdx { public: trackIdx(const std::string& s1_, const std::string& s2_) : s1(s1_),s2(s2_) {} int operator() (std::string x1, std::string x2) { tracker++; return (s1==x1 && s2==x2 ? (tracker-1) : -10); } void reset() { tracker = 0; } private: std::string s1; std::string s2; static int tracker; }; int trackIdx::tracker = 0; // [[Rcpp::export]] std::vector mc_index(const Rcpp::DataFrame& df, const std::string& c1, const std::string& c2) { std::vector vc1 = df["C1"]; std::vector vc2 = df["C2"]; int N = df.nrows(); std::vector vcount; vcount.resize( N ); trackIdx track(c1,c2); std::transform(vc1.begin(),vc1.end(),vc2.begin(),vcount.begin(),track); vcount.erase( std::remove_if(vcount.begin(),vcount.end(), [](int i) -> bool { return (i<0); }), vcount.end()); track.reset(); return vcount; } On Wed, Oct 22, 2014 at 2:29 PM, nate russell wrote: > Matthew, > > Thank you for such a quick response; both of those suggestions worked > perfectly. Out of curiosity, is there any reason to use one of these > implementations over the other - or are they essentially equivalent? > > Regards, > Nathan Russell > > On Wed, Oct 22, 2014 at 2:10 PM, Matthew Wright wrote: > >> Nate, >> >> The problem here is how you are have implemented your static member of >> trackIdx. You only declared it. >> >> I'd suggest one of two alternatives: >> >> // add this below the struct declaration. >> int trackIdx::tracker = 0; >> >> Or, just create it in the function where you actually use it instead of >> making it a member. >> int operator() (std::string x1, std::string x2) { >> static int tracker; >> tracker++; >> return ((s1==x1 && s2==x2) ? (tracker-1) : -1); >> } >> >> >> >> On Wed, Oct 22, 2014 at 12:39 PM, nate russell >> wrote: >> >>> Hello, >>> >>> I am running into the "Error in dyn.load [...] unable to load shared >>> object ['/tmp/...'] undefined symbol [_...]" error; however it is only >>> happening with one particular Rcpp function, which I find puzzling. Here is >>> my .cpp file containing two functions - I can compile the first one without >>> any issue (in its own file), but the second brings about the noted error >>> message: >>> >>> >>> #include >>> #include >>> #include >>> #include >>> // [[Rcpp::plugins(cpp11)]] >>> >>> /* >>> * Works fine. >>> */ >>> >>> struct checkTwo { >>> public: >>> checkTwo(const std::string& s1_, const std::string& s2_) >>> : s1(s1_), s2(s2_) {} >>> int operator() (std::string x1, std::string x2) { >>> return (s1==x1 && s2==x2 ? 1 : 0); >>> } >>> private: >>> std::string s1; >>> std::string s2; >>> }; >>> >>> // [[Rcpp::export]] >>> int count_if_if(const Rcpp::DataFrame& df, >>> const std::string& c1, >>> const std::string& c2) >>> { >>> std::vector vc1 = df["C1"]; >>> std::vector vc2 = df["C2"]; >>> int N = df.nrows(); >>> >>> std::vector vcount; >>> vcount.resize( N ); >>> >>> >>> std::transform(vc1.begin(),vc1.end(),vc2.begin(),vcount.begin(),checkTwo(c1,c2)); >>> int total = std::accumulate(vcount.begin(),vcount.end(),0); >>> >>> return total; >>> } >>> >>> /* >>> * Does not compile. >>> */ >>> >>> struct trackIdx { >>> public: >>> trackIdx(const std::string& s1_, const std::string& s2_) >>> : s1(s1_),s2(s2_) {} >>> int operator() (std::string x1, std::string x2) { >>> tracker++; >>> return ((s1==x1 && s2==x2) ? (tracker-1) : -1); >>> } >>> private: >>> std::string s1; >>> std::string s2; >>> static int tracker; >>> }; >>> >>> // [[Rcpp::export]] >>> std::vector mc_index(const Rcpp::DataFrame& df, >>> const std::string& c1, >>> const std::string& c2) >>> { >>> std::vector vc1 = df["C1"]; >>> std::vector vc2 = df["C2"]; >>> int N = df.nrows(); >>> >>> std::vector vcount; >>> vcount.resize( N ); >>> >>> std::vector result; >>> result.resize( N ); >>> >>> >>> std::transform(vc1.begin(),vc1.end(),vc2.begin(),vcount.begin(),trackIdx(c1,c2)); >>> std::copy_if(vcount.begin(),vcount.end(),result.begin(), >>> [](int i) -> bool { >>> return !(i<0); >>> }); >>> >>> return result; >>> } >>> >>> >>> The above functions (only "count_if_if" at the moment) can be tested >>> like this: >>> >>> Df <- data.frame( >>> C1=rep(LETTERS[1:4],each=15), >>> C2=as.character(rep(rep(1:3,each=5),4)), >>> C3=rep(rep(1:3,each=5),4), >>> stringsAsFactors=FALSE) >>> ## >>> count_if_if(Df,"B","3") >>> ## >>> # mc_index(Df,"B","3") >>> >>> >>> >>> The exact error message I am getting is: >>> >>> Error in >>> dyn.load("/tmp/Rtmpw7VSkV/sourcecpp_27046ca49cd4/sourceCpp_67600.so") : >>> unable to load shared object >>> '/tmp/Rtmpw7VSkV/sourcecpp_27046ca49cd4/sourceCpp_67600.so': >>> /tmp/Rtmpw7VSkV/sourcecpp_27046ca49cd4/sourceCpp_67600.so: undefined >>> symbol: _ZN8trackIdx7trackerE >>> >>> >>> and judging by the last bit, "undefined symbol: _ZN8trackIdx7trackerE", >>> it looks like my "trackIdx" function object is the source of the problem. >>> >>> I have tested this on two different platforms - >>> >>> my network server running CentOS 7: >>> >>> R version 3.1.1 >>> Platform: x86_64-redhat-linux-gnu (64-bit) >>> Rcpp_0.11.3 >>> >>> >>> and my laptop running Ubuntu 14.04: >>> >>> R version 3.0.2 >>> Platform: x86_64-pc-linux-gnu (64-bit) >>> Rcpp_0.11.2 >>> >>> >>> Both of these machines use a reasonably up-to-date version of g++ that >>> supports c++11 (although I don't think this has anything to do with the >>> issue). I have never had any problems compiling Rcpp functions on either of >>> these platforms, yet the second function object & Rcpp function above >>> produce the same error on each machine. If anyone can explain what is going >>> wrong and/or suggest how to correct the problem with the above code I would >>> appreciate it very much. >>> >>> Thank you, >>> Nathan Russell >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Rcpp-devel mailing list >>> Rcpp-devel at lists.r-forge.r-project.org >>> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel >>> >> >> >> >> -- >> ------------------------- >> Matt Wright >> 312-264-2987 (p) >> 312-479-6821 (m) >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wdunlap at tibco.com Wed Oct 22 21:29:28 2014 From: wdunlap at tibco.com (William Dunlap) Date: Wed, 22 Oct 2014 12:29:28 -0700 Subject: [Rcpp-devel] dyn.load error with particular functor In-Reply-To: References: Message-ID: Why don't you make track non-static instead? Bill Dunlap TIBCO Software wdunlap tibco.com On Wed, Oct 22, 2014 at 12:03 PM, nate russell wrote: > Just for the sake of completeness, I noticed that the value of > trackIdx::tracker was persisting (and therefore continuing to be > incremented) between function calls with mc_index, so in addition to your > first suggestion, I added a member function to reset the value to zero, and > everything seems to be working smoothly. Once again, thank you for your > help. > > Nathan Russell > > > > #include > #include > #include > #include > // [[Rcpp::plugins(cpp11)]] > > class trackIdx { > public: > trackIdx(const std::string& s1_, const std::string& s2_) > : s1(s1_),s2(s2_) {} > int operator() (std::string x1, std::string x2) { > tracker++; > return (s1==x1 && s2==x2 ? (tracker-1) : -10); > } > void reset() { tracker = 0; } > private: > std::string s1; > std::string s2; > static int tracker; > }; > > int trackIdx::tracker = 0; > > // [[Rcpp::export]] > std::vector mc_index(const Rcpp::DataFrame& df, > const std::string& c1, > const std::string& c2) > { > std::vector vc1 = df["C1"]; > std::vector vc2 = df["C2"]; > int N = df.nrows(); > > std::vector vcount; > vcount.resize( N ); > > trackIdx track(c1,c2); > > std::transform(vc1.begin(),vc1.end(),vc2.begin(),vcount.begin(),track); > vcount.erase( > std::remove_if(vcount.begin(),vcount.end(), > [](int i) -> bool { > return (i<0); > }), > vcount.end()); > > track.reset(); > return vcount; > } > > > > On Wed, Oct 22, 2014 at 2:29 PM, nate russell > wrote: >> >> Matthew, >> >> Thank you for such a quick response; both of those suggestions worked >> perfectly. Out of curiosity, is there any reason to use one of these >> implementations over the other - or are they essentially equivalent? >> >> Regards, >> Nathan Russell >> >> On Wed, Oct 22, 2014 at 2:10 PM, Matthew Wright wrote: >>> >>> Nate, >>> >>> The problem here is how you are have implemented your static member of >>> trackIdx. You only declared it. >>> >>> I'd suggest one of two alternatives: >>> >>> // add this below the struct declaration. >>> int trackIdx::tracker = 0; >>> >>> Or, just create it in the function where you actually use it instead of >>> making it a member. >>> int operator() (std::string x1, std::string x2) { >>> static int tracker; >>> tracker++; >>> return ((s1==x1 && s2==x2) ? (tracker-1) : -1); >>> } >>> >>> >>> >>> On Wed, Oct 22, 2014 at 12:39 PM, nate russell >>> wrote: >>>> >>>> Hello, >>>> >>>> I am running into the "Error in dyn.load [...] unable to load shared >>>> object ['/tmp/...'] undefined symbol [_...]" error; however it is only >>>> happening with one particular Rcpp function, which I find puzzling. Here is >>>> my .cpp file containing two functions - I can compile the first one without >>>> any issue (in its own file), but the second brings about the noted error >>>> message: >>>> >>>> >>>> #include >>>> #include >>>> #include >>>> #include >>>> // [[Rcpp::plugins(cpp11)]] >>>> >>>> /* >>>> * Works fine. >>>> */ >>>> >>>> struct checkTwo { >>>> public: >>>> checkTwo(const std::string& s1_, const std::string& s2_) >>>> : s1(s1_), s2(s2_) {} >>>> int operator() (std::string x1, std::string x2) { >>>> return (s1==x1 && s2==x2 ? 1 : 0); >>>> } >>>> private: >>>> std::string s1; >>>> std::string s2; >>>> }; >>>> >>>> // [[Rcpp::export]] >>>> int count_if_if(const Rcpp::DataFrame& df, >>>> const std::string& c1, >>>> const std::string& c2) >>>> { >>>> std::vector vc1 = df["C1"]; >>>> std::vector vc2 = df["C2"]; >>>> int N = df.nrows(); >>>> >>>> std::vector vcount; >>>> vcount.resize( N ); >>>> >>>> >>>> std::transform(vc1.begin(),vc1.end(),vc2.begin(),vcount.begin(),checkTwo(c1,c2)); >>>> int total = std::accumulate(vcount.begin(),vcount.end(),0); >>>> >>>> return total; >>>> } >>>> >>>> /* >>>> * Does not compile. >>>> */ >>>> >>>> struct trackIdx { >>>> public: >>>> trackIdx(const std::string& s1_, const std::string& s2_) >>>> : s1(s1_),s2(s2_) {} >>>> int operator() (std::string x1, std::string x2) { >>>> tracker++; >>>> return ((s1==x1 && s2==x2) ? (tracker-1) : -1); >>>> } >>>> private: >>>> std::string s1; >>>> std::string s2; >>>> static int tracker; >>>> }; >>>> >>>> // [[Rcpp::export]] >>>> std::vector mc_index(const Rcpp::DataFrame& df, >>>> const std::string& c1, >>>> const std::string& c2) >>>> { >>>> std::vector vc1 = df["C1"]; >>>> std::vector vc2 = df["C2"]; >>>> int N = df.nrows(); >>>> >>>> std::vector vcount; >>>> vcount.resize( N ); >>>> >>>> std::vector result; >>>> result.resize( N ); >>>> >>>> >>>> std::transform(vc1.begin(),vc1.end(),vc2.begin(),vcount.begin(),trackIdx(c1,c2)); >>>> std::copy_if(vcount.begin(),vcount.end(),result.begin(), >>>> [](int i) -> bool { >>>> return !(i<0); >>>> }); >>>> >>>> return result; >>>> } >>>> >>>> >>>> The above functions (only "count_if_if" at the moment) can be tested >>>> like this: >>>> >>>> Df <- data.frame( >>>> C1=rep(LETTERS[1:4],each=15), >>>> C2=as.character(rep(rep(1:3,each=5),4)), >>>> C3=rep(rep(1:3,each=5),4), >>>> stringsAsFactors=FALSE) >>>> ## >>>> count_if_if(Df,"B","3") >>>> ## >>>> # mc_index(Df,"B","3") >>>> >>>> >>>> >>>> The exact error message I am getting is: >>>> >>>> Error in >>>> dyn.load("/tmp/Rtmpw7VSkV/sourcecpp_27046ca49cd4/sourceCpp_67600.so") : >>>> unable to load shared object >>>> '/tmp/Rtmpw7VSkV/sourcecpp_27046ca49cd4/sourceCpp_67600.so': >>>> /tmp/Rtmpw7VSkV/sourcecpp_27046ca49cd4/sourceCpp_67600.so: undefined >>>> symbol: _ZN8trackIdx7trackerE >>>> >>>> >>>> and judging by the last bit, "undefined symbol: _ZN8trackIdx7trackerE", >>>> it looks like my "trackIdx" function object is the source of the problem. >>>> >>>> I have tested this on two different platforms - >>>> >>>> my network server running CentOS 7: >>>> >>>> R version 3.1.1 >>>> Platform: x86_64-redhat-linux-gnu (64-bit) >>>> Rcpp_0.11.3 >>>> >>>> >>>> and my laptop running Ubuntu 14.04: >>>> >>>> R version 3.0.2 >>>> Platform: x86_64-pc-linux-gnu (64-bit) >>>> Rcpp_0.11.2 >>>> >>>> >>>> Both of these machines use a reasonably up-to-date version of g++ that >>>> supports c++11 (although I don't think this has anything to do with the >>>> issue). I have never had any problems compiling Rcpp functions on either of >>>> these platforms, yet the second function object & Rcpp function above >>>> produce the same error on each machine. If anyone can explain what is going >>>> wrong and/or suggest how to correct the problem with the above code I would >>>> appreciate it very much. >>>> >>>> Thank you, >>>> Nathan Russell >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rcpp-devel mailing list >>>> Rcpp-devel at lists.r-forge.r-project.org >>>> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel >>> >>> >>> >>> >>> -- >>> ------------------------- >>> Matt Wright >>> 312-264-2987 (p) >>> 312-479-6821 (m) >> >> > > > _______________________________________________ > Rcpp-devel mailing list > Rcpp-devel at lists.r-forge.r-project.org > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel From russell.n2012 at gmail.com Wed Oct 22 21:59:07 2014 From: russell.n2012 at gmail.com (nate russell) Date: Wed, 22 Oct 2014 15:59:07 -0400 Subject: [Rcpp-devel] dyn.load error with particular functor In-Reply-To: References: Message-ID: Matt and Bill, Thank you both for your input. I was under the impression that std::transform would be calling a new trackIdx(c1,c2) object for each step along the input vectors, and therefore a static data member would be needed to ensure that the count was being accumulated properly (my knowledge of C++ is pretty basic, as you might have picked up on). I took your suggestions about using a non-static data member, though, and it worked correctly. Thanks again for the help guys. Nate On Wed, Oct 22, 2014 at 3:32 PM, Matthew Wright wrote: > Hi Nate, > > No problem. > > So the reason it's persisting across method calls is because you made it a > static, which means there's just one instance of that data across the > entire program. In your usage, it doesn't look like you need it to be > static. You could just make it an instance variable and you'd probably get > what you want, so you'd just remove the static keyword and don't initialize > it outside the struct definition. > > In terms of why you initialize statics this way, this stack overflow > question might prove helpful, I always found it a bit confusing: > http://stackoverflow.com/questions/185844/initializing-private-static-members > > Matt > > > On Wed, Oct 22, 2014 at 2:03 PM, nate russell > wrote: > >> Just for the sake of completeness, I noticed that the value of >> trackIdx::tracker was persisting (and therefore continuing to be >> incremented) between function calls with mc_index, so in addition to your >> first suggestion, I added a member function to reset the value to zero, and >> everything seems to be working smoothly. Once again, thank you for your >> help. >> >> Nathan Russell >> >> >> >> #include >> #include >> #include >> #include >> // [[Rcpp::plugins(cpp11)]] >> >> class trackIdx { >> public: >> trackIdx(const std::string& s1_, const std::string& s2_) >> : s1(s1_),s2(s2_) {} >> int operator() (std::string x1, std::string x2) { >> tracker++; >> return (s1==x1 && s2==x2 ? (tracker-1) : -10); >> } >> void reset() { tracker = 0; } >> private: >> std::string s1; >> std::string s2; >> static int tracker; >> }; >> >> int trackIdx::tracker = 0; >> >> // [[Rcpp::export]] >> std::vector mc_index(const Rcpp::DataFrame& df, >> const std::string& c1, >> const std::string& c2) >> { >> std::vector vc1 = df["C1"]; >> std::vector vc2 = df["C2"]; >> int N = df.nrows(); >> >> std::vector vcount; >> vcount.resize( N ); >> >> trackIdx track(c1,c2); >> >> std::transform(vc1.begin(),vc1.end(),vc2.begin(),vcount.begin(),track); >> vcount.erase( >> std::remove_if(vcount.begin(),vcount.end(), >> [](int i) -> bool { >> return (i<0); >> }), >> vcount.end()); >> >> track.reset(); >> return vcount; >> } >> >> >> >> On Wed, Oct 22, 2014 at 2:29 PM, nate russell >> wrote: >> >>> Matthew, >>> >>> Thank you for such a quick response; both of those suggestions worked >>> perfectly. Out of curiosity, is there any reason to use one of these >>> implementations over the other - or are they essentially equivalent? >>> >>> Regards, >>> Nathan Russell >>> >>> On Wed, Oct 22, 2014 at 2:10 PM, Matthew Wright >>> wrote: >>> >>>> Nate, >>>> >>>> The problem here is how you are have implemented your static member of >>>> trackIdx. You only declared it. >>>> >>>> I'd suggest one of two alternatives: >>>> >>>> // add this below the struct declaration. >>>> int trackIdx::tracker = 0; >>>> >>>> Or, just create it in the function where you actually use it instead of >>>> making it a member. >>>> int operator() (std::string x1, std::string x2) { >>>> static int tracker; >>>> tracker++; >>>> return ((s1==x1 && s2==x2) ? (tracker-1) : -1); >>>> } >>>> >>>> >>>> >>>> On Wed, Oct 22, 2014 at 12:39 PM, nate russell >>> > wrote: >>>> >>>>> Hello, >>>>> >>>>> I am running into the "Error in dyn.load [...] unable to load shared >>>>> object ['/tmp/...'] undefined symbol [_...]" error; however it is only >>>>> happening with one particular Rcpp function, which I find puzzling. Here is >>>>> my .cpp file containing two functions - I can compile the first one without >>>>> any issue (in its own file), but the second brings about the noted error >>>>> message: >>>>> >>>>> >>>>> #include >>>>> #include >>>>> #include >>>>> #include >>>>> // [[Rcpp::plugins(cpp11)]] >>>>> >>>>> /* >>>>> * Works fine. >>>>> */ >>>>> >>>>> struct checkTwo { >>>>> public: >>>>> checkTwo(const std::string& s1_, const std::string& s2_) >>>>> : s1(s1_), s2(s2_) {} >>>>> int operator() (std::string x1, std::string x2) { >>>>> return (s1==x1 && s2==x2 ? 1 : 0); >>>>> } >>>>> private: >>>>> std::string s1; >>>>> std::string s2; >>>>> }; >>>>> >>>>> // [[Rcpp::export]] >>>>> int count_if_if(const Rcpp::DataFrame& df, >>>>> const std::string& c1, >>>>> const std::string& c2) >>>>> { >>>>> std::vector vc1 = df["C1"]; >>>>> std::vector vc2 = df["C2"]; >>>>> int N = df.nrows(); >>>>> >>>>> std::vector vcount; >>>>> vcount.resize( N ); >>>>> >>>>> >>>>> std::transform(vc1.begin(),vc1.end(),vc2.begin(),vcount.begin(),checkTwo(c1,c2)); >>>>> int total = std::accumulate(vcount.begin(),vcount.end(),0); >>>>> >>>>> return total; >>>>> } >>>>> >>>>> /* >>>>> * Does not compile. >>>>> */ >>>>> >>>>> struct trackIdx { >>>>> public: >>>>> trackIdx(const std::string& s1_, const std::string& s2_) >>>>> : s1(s1_),s2(s2_) {} >>>>> int operator() (std::string x1, std::string x2) { >>>>> tracker++; >>>>> return ((s1==x1 && s2==x2) ? (tracker-1) : -1); >>>>> } >>>>> private: >>>>> std::string s1; >>>>> std::string s2; >>>>> static int tracker; >>>>> }; >>>>> >>>>> // [[Rcpp::export]] >>>>> std::vector mc_index(const Rcpp::DataFrame& df, >>>>> const std::string& c1, >>>>> const std::string& c2) >>>>> { >>>>> std::vector vc1 = df["C1"]; >>>>> std::vector vc2 = df["C2"]; >>>>> int N = df.nrows(); >>>>> >>>>> std::vector vcount; >>>>> vcount.resize( N ); >>>>> >>>>> std::vector result; >>>>> result.resize( N ); >>>>> >>>>> >>>>> std::transform(vc1.begin(),vc1.end(),vc2.begin(),vcount.begin(),trackIdx(c1,c2)); >>>>> std::copy_if(vcount.begin(),vcount.end(),result.begin(), >>>>> [](int i) -> bool { >>>>> return !(i<0); >>>>> }); >>>>> >>>>> return result; >>>>> } >>>>> >>>>> >>>>> The above functions (only "count_if_if" at the moment) can be tested >>>>> like this: >>>>> >>>>> Df <- data.frame( >>>>> C1=rep(LETTERS[1:4],each=15), >>>>> C2=as.character(rep(rep(1:3,each=5),4)), >>>>> C3=rep(rep(1:3,each=5),4), >>>>> stringsAsFactors=FALSE) >>>>> ## >>>>> count_if_if(Df,"B","3") >>>>> ## >>>>> # mc_index(Df,"B","3") >>>>> >>>>> >>>>> >>>>> The exact error message I am getting is: >>>>> >>>>> Error in >>>>> dyn.load("/tmp/Rtmpw7VSkV/sourcecpp_27046ca49cd4/sourceCpp_67600.so") : >>>>> unable to load shared object >>>>> '/tmp/Rtmpw7VSkV/sourcecpp_27046ca49cd4/sourceCpp_67600.so': >>>>> /tmp/Rtmpw7VSkV/sourcecpp_27046ca49cd4/sourceCpp_67600.so: undefined >>>>> symbol: _ZN8trackIdx7trackerE >>>>> >>>>> >>>>> and judging by the last bit, "undefined symbol: >>>>> _ZN8trackIdx7trackerE", it looks like my "trackIdx" function object is the >>>>> source of the problem. >>>>> >>>>> I have tested this on two different platforms - >>>>> >>>>> my network server running CentOS 7: >>>>> >>>>> R version 3.1.1 >>>>> Platform: x86_64-redhat-linux-gnu (64-bit) >>>>> Rcpp_0.11.3 >>>>> >>>>> >>>>> and my laptop running Ubuntu 14.04: >>>>> >>>>> R version 3.0.2 >>>>> Platform: x86_64-pc-linux-gnu (64-bit) >>>>> Rcpp_0.11.2 >>>>> >>>>> >>>>> Both of these machines use a reasonably up-to-date version of g++ that >>>>> supports c++11 (although I don't think this has anything to do with the >>>>> issue). I have never had any problems compiling Rcpp functions on either of >>>>> these platforms, yet the second function object & Rcpp function above >>>>> produce the same error on each machine. If anyone can explain what is going >>>>> wrong and/or suggest how to correct the problem with the above code I would >>>>> appreciate it very much. >>>>> >>>>> Thank you, >>>>> Nathan Russell >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rcpp-devel mailing list >>>>> Rcpp-devel at lists.r-forge.r-project.org >>>>> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel >>>>> >>>> >>>> >>>> >>>> -- >>>> ------------------------- >>>> Matt Wright >>>> 312-264-2987 (p) >>>> 312-479-6821 (m) >>>> >>> >>> >> > > > -- > ------------------------- > Matt Wright > 312-264-2987 (p) > 312-479-6821 (m) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 2009lxh at gmail.com Wed Oct 29 09:08:40 2014 From: 2009lxh at gmail.com (=?UTF-8?B?5p2O5pmT6L6J?=) Date: Wed, 29 Oct 2014 16:08:40 +0800 Subject: [Rcpp-devel] The problem i encountered about RcppEigen double -(k/2)*std::log(2*M_PI)+rooti.diagonal().log().sum(); can not run . Message-ID: These days i rewrote the dmvnorm() function from the mvtnorm package with RcppEigen which is publised in http://gallery.rcpp.org/articles/dmvnorm_arma/. The code as follows: > #include > using namespace Rcpp; > // [[Rcpp::depends(RcppEigen)]] > //[[Rcpp::export]] > using Eigen::Map; > using Eigen::MatrixXd; > using Eigen::VectorXd; > using Eigen::LLT; > VectorXd dmvnrm_Eigen(Map X,Map mu,Map > Sigma){ > const int k = X.cols(); > int n = X.rows(); > MatrixXd D(k,k); > LLTlltOfsigma(Sigma); > MatrixXd L = lltOfsigma.matrixL(); > MatrixXd rooti = L.inverse()*Eigen::MatrixXd::Identity(k,k); > MatrixXd MU = mu.replicate(1,n); > MatrixXd Q = rooti.transpose()*(X.transpose()-MU); > MatrixXd QUAD = Q.cwiseProduct(Q); > VectorXd quads = QUAD.colwise().sum(); > VectorXd FD(n); > double Con = -(k/2)*std::log(2*M_PI)+rooti.diagonal().log().sum(); > FD.setConstant(Con); > return (FD - 0.5*quads).exp(); > } /*** R > sigma <- bayesm::rwishart(10,diag(8))$IW > means <- rnorm(8) > X <- mvtnorm::rmvnorm(90, means, sigma) > dmvnrm_Eigen(X,means,sigma) > */ When i run above code with RStudio, it often got an error message *:R Session Aborted* it seems that* double Con = -(k/2)*std::log(2*M_PI)+rooti.diagonal().log().sum(); *got a problem.Actually,if i rewrite these code as follow: > double Con=0.; > for (int i=0;i Con+=log(rooti(i,i)); > } > Con+=-(k/2)*std::log(2*M_PI) it work well. I do not know what is wrong with *double Con = -(k/2)*std::log(2*M_PI)+rooti.diagonal().log().sum();* -------------- next part -------------- An HTML attachment was scrubbed... URL: From edd at debian.org Wed Oct 29 13:06:12 2014 From: edd at debian.org (Dirk Eddelbuettel) Date: Wed, 29 Oct 2014 07:06:12 -0500 Subject: [Rcpp-devel] The problem i encountered about RcppEigen double -(k/2)*std::log(2*M_PI)+rooti.diagonal().log().sum(); can not run . In-Reply-To: References: Message-ID: <21584.55348.144371.460255@max.nulle.part> On 29 October 2014 at 16:08, ??? wrote: | These days i rewrote the??dmvnorm()?function from the?mvtnorm?package with | RcppEigen which is publised in?http://gallery.rcpp.org/articles/dmvnorm_arma/. | The code as follows: | | #include | using namespace Rcpp; | // [[Rcpp::depends(RcppEigen)]] | //[[Rcpp::export]] | using Eigen::Map; ? ? ? ? ? ? ?? | using Eigen::MatrixXd; | using Eigen::VectorXd; | using Eigen::LLT; | VectorXd dmvnrm_Eigen(Map X,Map mu,Map Sigma) | { | ? const int k = X.cols(); | ? ?int n = X.rows(); | ? ?MatrixXd D(k,k);? | ? ?LLTlltOfsigma(Sigma);? | ? ?MatrixXd L = lltOfsigma.matrixL(); | ? ?MatrixXd rooti = L.inverse()*Eigen::MatrixXd::Identity(k,k); | ? ?MatrixXd MU = mu.replicate(1,n); | ? ?MatrixXd Q = rooti.transpose()*(X.transpose()-MU); | ? ?MatrixXd QUAD = Q.cwiseProduct(Q); ? | ? ?VectorXd quads = QUAD.colwise().sum(); | ? ?VectorXd FD(n); | ? ?double Con = -(k/2)*std::log(2*M_PI)+rooti.diagonal().log().sum(); | ? ?FD.setConstant(Con); | ? ?return (FD - 0.5*quads).exp(); | } | | /*** R | sigma <- bayesm::rwishart(10,diag(8))$IW | means <- rnorm(8) | X ? ? <- mvtnorm::rmvnorm(90, means, sigma) | dmvnrm_Eigen(X,means,sigma) | */? | | | When i run above code with RStudio, it often got an error message :R Session | Aborted | ?it seems that double Con = -(k/2)*std::log(2*M_PI)+rooti.diagonal().log().sum | (); got a problem.Actually,if i rewrite these code as follow: | | double Con=0.; | ? ?for (int i=0;i Dear list, I am trying to call R?s negative binomial function with Rcpp, but encountered some weird behaviour. Here is an example using inline: rcpp_Rf_dnbinom <- rcpp(signature(), ' return wrap(Rf_dnbinom( 4.0, 0.5, 0.9, 1)); ') rcpp_Rf_dnbinom_mu <- rcpp(signature(), ' return wrap(Rf_dnbinom_mu( 4.0, 0.5, 0.9, 1)); ') rcpp_dnbinom <- rcpp(signature(), ' return wrap(R::dnbinom( 4.0, 0.5, 0.9, 1)); ') rcpp_dnbinom_mu <- rcpp(signature(), ' return wrap(R::dnbinom_mu( 4.0, 0.5, 0.9, 1)); ') rcpp_dnbinom_sugar <- rcpp(signature(y="numeric"), ' NumericVector x = NumericVector(y); NumericVector res = dnbinom( x, 0.5, 0.9,1); return wrap(res); ') rcpp_dnbinom_mu_sugar <- rcpp(signature(y="numeric"), ' NumericVector x = NumericVector(y); NumericVector res = dnbinom_mu( x, 0.5, 0.9,1); return wrap(res); ') rcpp_Rf_dnbinom() #-10.5597 rcpp_Rf_dnbinom_mu() #-3.578823 rcpp_dnbinom() #-10.5597 rcpp_dnbinom_mu() #-10.5597 rcpp_dnbinom_sugar(y=4.0) #-10.5597 rcpp_dnbinom_mu_sugar(y=4.0) #-3.578823 dnbinom(x=4,size=0.5,mu=0.9,log=TRUE) #[1] -3.578823 dnbinom(x=4,size=0.5,prob=0.9,log=TRUE) #[1] -10.5597 So it looks like that everything is fine when using Rcpp sugar or Rf_dbinom_mu directly, but when using form R::dbinom both dnbinom and dnbinom_mu calls actually use dnbinom. I am not sure if this is relevant, but Rmath.h in Rcpp contains lines: 129 inline double dnbinom(double x, double sz, double pb, int lg) { return ::Rf_dnbinom(x, sz, pb, lg); } 130 inline double pnbinom(double x, double sz, double pb, int lt, int lg) { return ::Rf_pnbinom(x, sz, pb, lt, lg); } 131 inline double qnbinom(double p, double sz, double pb, int lt, int lg) { return ::Rf_qnbinom(p, sz, pb, lt, lg); } 132 inline double rnbinom(double sz, double pb) { return ::Rf_rnbinom(sz, pb); } 133 134 inline double dnbinom_mu(double x, double sz, double mu, int lg) { return ::Rf_dnbinom(x, sz, mu, lg); } 135 inline double pnbinom_mu(double x, double sz, double mu, int lt, int lg) { return ::Rf_pnbinom(x, sz, mu, lt, lg); } 136 inline double qnbinom_mu(double x, double sz, double mu, int lt, int lg) { return ::Rf_qnbinom(x, sz, mu, lt, lg); } 137 inline double rnbinom_mu(double sz, double mu) { return ::Rf_rnbinom(sz, mu); } To me this looks like that both dnbinom and dnbinom_mu calls the same function. So, is there something wrong with my code or is there a typo in R:: dnbinom_mu? To be honest, I don't really understand the differences between the three versions, except that the sugar version needs NumericVector as first argument and it is vectorized regards that parameter. I would actually need version which is vectorized wrt all arguments (except log), but since there isn't one I am doing something like this: #include "RcppArmadillo.h" // [[Rcpp::depends(RcppArmadillo)]] double fun(const arma::mat& y, const arma::mat& x ,const arma::mat& theta){ double res=0.0; for(unsigned int i=0; i From yixuan.qiu at cos.name Wed Oct 29 15:56:54 2014 From: yixuan.qiu at cos.name (Yixuan Qiu) Date: Wed, 29 Oct 2014 10:56:54 -0400 Subject: [Rcpp-devel] The problem i encountered about RcppEigen double -(k/2)*std::log(2*M_PI)+rooti.diagonal().log().sum(); can not run . In-Reply-To: References: Message-ID: Hi Xiaohui, There are several problems in the code I have found: 1. MatrixXd rooti = L.inverse()*Eigen::MatrixXd::Identity(k,k) is not necessary. You are multiplying a matrix with an identity matrix, so it can be simplified as MatrixXd rooti = L.inverse(); 2. k is an integer, so you need to use k / 2.0 in calculating Con. 3. Most importantly, the reason to cause segfault is the misuse of .log() and .exp() in the "double Con = " and "return" statements. When you want to do coefficient-wise operations on a vector or a matrix, you should first convert it to Array class. So these two lines should be double Con = -(k/2.0)*std::log(2*M_PI)+rooti.diagonal().array().log().sum(); and return (FD - 0.5*quads).array().exp(); 4. To correctly computing the quadratic terms, you should write MatrixXd Q = rooti*(X.transpose()-MU); instead of MatrixXd Q = rooti.transpose()*(X.transpose()-MU); Best, Yixuan 2014-10-29 4:08 GMT-04:00 ??? <2009lxh at gmail.com>: > These days i rewrote the dmvnorm() function from the mvtnorm package > with RcppEigen which is publised in > http://gallery.rcpp.org/articles/dmvnorm_arma/. > The code as follows: > >> #include >> using namespace Rcpp; >> // [[Rcpp::depends(RcppEigen)]] >> //[[Rcpp::export]] >> using Eigen::Map; >> using Eigen::MatrixXd; >> using Eigen::VectorXd; >> using Eigen::LLT; >> VectorXd dmvnrm_Eigen(Map X,Map mu,Map >> Sigma){ >> const int k = X.cols(); >> int n = X.rows(); >> MatrixXd D(k,k); >> LLTlltOfsigma(Sigma); >> MatrixXd L = lltOfsigma.matrixL(); >> MatrixXd rooti = L.inverse()*Eigen::MatrixXd::Identity(k,k); >> MatrixXd MU = mu.replicate(1,n); >> MatrixXd Q = rooti.transpose()*(X.transpose()-MU); >> MatrixXd QUAD = Q.cwiseProduct(Q); >> VectorXd quads = QUAD.colwise().sum(); >> VectorXd FD(n); >> double Con = -(k/2)*std::log(2*M_PI)+rooti.diagonal().log().sum(); >> FD.setConstant(Con); >> return (FD - 0.5*quads).exp(); >> } > > /*** R >> sigma <- bayesm::rwishart(10,diag(8))$IW >> means <- rnorm(8) >> X <- mvtnorm::rmvnorm(90, means, sigma) >> dmvnrm_Eigen(X,means,sigma) >> */ > > > When i run above code with RStudio, it often got an error message *:R > Session Aborted* > it seems that* double Con = > -(k/2)*std::log(2*M_PI)+rooti.diagonal().log().sum(); *got a > problem.Actually,if i rewrite these code as follow: > >> double Con=0.; >> for (int i=0;i> Con+=log(rooti(i,i)); >> } >> Con+=-(k/2)*std::log(2*M_PI) > > > it work well. > I do not know what is wrong with > *double Con = -(k/2)*std::log(2*M_PI)+rooti.diagonal().log().sum();* > > > _______________________________________________ > Rcpp-devel mailing list > Rcpp-devel at lists.r-forge.r-project.org > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel > -- Yixuan Qiu Department of Statistics, Purdue University -------------- next part -------------- An HTML attachment was scrubbed... URL: From edd at debian.org Wed Oct 29 18:31:47 2014 From: edd at debian.org (Dirk Eddelbuettel) Date: Wed, 29 Oct 2014 12:31:47 -0500 Subject: [Rcpp-devel] R::nbinom and R::nbinom_mu give identical results? In-Reply-To: <7FC11B33B8C53E4EB9510C0BAA73EAE33077D10A@mbs2.ad.jyu.fi> References: <7FC11B33B8C53E4EB9510C0BAA73EAE33077D10A@mbs2.ad.jyu.fi> Message-ID: <21585.9347.875838.684672@max.nulle.part> On 29 October 2014 at 14:48, Helske Jouni wrote: | Dear list, | | | | I am trying to call R?s negative binomial function with Rcpp, but encountered | some weird behaviour. Here is an example using inline: | | | | | rcpp_Rf_dnbinom <- rcpp(signature(), | ' return wrap(Rf_dnbinom( 4.0, 0.5, 0.9, 1)); ') | | rcpp_Rf_dnbinom_mu <- rcpp(signature(), | ' return wrap(Rf_dnbinom_mu( 4.0, 0.5, 0.9, 1)); ') | | | rcpp_dnbinom <- rcpp(signature(), | ' return wrap(R::dnbinom( 4.0, 0.5, 0.9, 1)); ') | | rcpp_dnbinom_mu <- rcpp(signature(), | ' return wrap(R::dnbinom_mu( 4.0, 0.5, 0.9, 1)); ') | | rcpp_dnbinom_sugar <- rcpp(signature(y="numeric"), | ' NumericVector x = NumericVector(y); | NumericVector res = dnbinom( x, 0.5, 0.9,1); | return wrap(res); ') | | | rcpp_dnbinom_mu_sugar <- rcpp(signature(y="numeric"), | ' NumericVector x = NumericVector(y); | NumericVector res = dnbinom_mu( x, 0.5, 0.9,1); | return wrap(res); ') | | rcpp_Rf_dnbinom() | #-10.5597 | rcpp_Rf_dnbinom_mu() | #-3.578823 | rcpp_dnbinom() | #-10.5597 | rcpp_dnbinom_mu() | #-10.5597 | rcpp_dnbinom_sugar(y=4.0) | #-10.5597 | rcpp_dnbinom_mu_sugar(y=4.0) | #-3.578823 | dnbinom(x=4,size=0.5,mu=0.9,log=TRUE) | #[1] -3.578823 | dnbinom(x=4,size=0.5,prob=0.9,log=TRUE) | #[1] -10.5597 | | | | So it looks like that everything is fine when using Rcpp sugar or Rf_dbinom_mu | directly, but when using form R::dbinom both dnbinom and dnbinom_mu calls | actually use dnbinom. | | | I am not sure if this is relevant, but Rmath.h in Rcpp contains lines: | | | | 129 inline double dnbinom(double x, double sz, double pb, int lg) { return :: | Rf_dnbinom(x, sz, pb, lg); } | | 130 inline double pnbinom(double x, double sz, double pb, int lt, int lg) { | return ::Rf_pnbinom(x, sz, pb, lt, lg); } | | 131 inline double qnbinom(double p, double sz, double pb, int lt, int lg) { | return ::Rf_qnbinom(p, sz, pb, lt, lg); } | | 132 inline double rnbinom(double sz, double pb) { return ::Rf_rnbinom(sz, pb); | } | | 133 | | 134 inline double dnbinom_mu(double x, double sz, double mu, int lg) { return | ::Rf_dnbinom(x, sz, mu, lg); } | | 135 inline double pnbinom_mu(double x, double sz, double mu, int lt, int lg) { | return ::Rf_pnbinom(x, sz, mu, lt, lg); } | | 136 inline double qnbinom_mu(double x, double sz, double mu, int lt, int lg) { | return ::Rf_qnbinom(x, sz, mu, lt, lg); } | | 137 inline double rnbinom_mu(double sz, double mu) { return ::Rf_rnbinom(sz, | mu); } | | | | To me this looks like that both dnbinom and dnbinom_mu calls the same | function. That is likely a bug due an oversight of mine. The four lines in 134 to 137 want to call the variants from R ending in _mu. | So, is there something wrong with my code or is there a typo in R:: dnbinom_mu? | | | To be honest, I don't really understand the differences between the three See eg help(qbinom): one can either supply mu or prob when using the _R_ variant, so when I wrote this interface I tried to mimic this, offer the differnt functions with and without mu (in which case prob is used) but then dropped the ball amd didn't add _mu in the call. Will fix -- t hanke for the bug report! | versions, except that the sugar version needs NumericVector as first argument | and it is vectorized regards that parameter. I would actually need version | which is vectorized wrt all arguments (except log), but since there isn't one I | am doing something like this: | | | #include "RcppArmadillo.h" | | // [[Rcpp::depends(RcppArmadillo)]] | | double fun(const arma::mat& y, const arma::mat& x ,const arma::mat& theta){ | double res=0.0; | for(unsigned int i=0; i References: <7FC11B33B8C53E4EB9510C0BAA73EAE33077D10A@mbs2.ad.jyu.fi> <21585.9347.875838.684672@max.nulle.part> Message-ID: <21585.13682.975094.500646@max.nulle.part> One more: Turns out R 3.1.1 does not have the required define for the Rf_[dpqr]nbinom_mu, so I had to "park" the definition. Come Friday and R 3.1.2 we can re-enable this as R 3.1.2 appears to correct this. From its NEWS file: * A few recently added C entry points were missing the remapping to Rf_, notably [dpq]nbinom_mu. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org