Hi Kevin, I gave it a try and my program works as expected now. Thanks a lot! I had also to update my R to version 3.1.0 and RTools to 3.1. Best, Venelin
2014-04-20 22:35 GMT+02:00 Kevin Ushey <[email protected]>: > Hi Mitov, > > I've pushed some fixes to RcppArmadillo: > https://github.com/RcppCore/RcppArmadillo > > Can you try installing the development version > (devtools::install_github("RcppCore/RcppArmadillo")) and confirm everything > works as expected? > > Thanks, > Kevin > > > On Sun, Apr 20, 2014 at 12:24 PM, Kevin Ushey <[email protected]>wrote: > >> Hi guys, >> >> Here's what I think is going on. RcppArmadillo has the following >> 'InputParameter' class to handle 'as': >> >> template <typename T, typename VEC, typename REF> >> class ArmaVec_InputParameter { >> public: >> ArmaVec_InputParameter( SEXP x_ ) : v(x_), vec( >> reinterpret_cast<T*>( v.begin() ), v.size(), false ){} >> >> inline operator REF(){ >> return vec ; >> } >> >> private: >> Rcpp::Vector< Rcpp::traits::r_sexptype_traits<T>::rtype > v ; >> VEC vec ; >> } ; >> >> We are trying to re-use memory from an R vector, and here we are just >> reinterpreting the 'int' contents of the R vector as 'unsigned int' without >> any coercion. This won't work. >> >> (Interestingly, in the 'base' case (ie, arma::uvec vs. const or >> ref-qualified arma::uvec), we are just dispatching to an internal Rcpp as, >> not any of the RcppArmadillo 'as'es. That's why we don't see it here -- >> that dispatch explicitly uses 'as') >> >> To fix this, we need to coerce when necessary. I believe the >> r_sexptype_traits class has a bit of 'does this fit in an R vector, or does >> it need coercion?' in it, so maybe we can leverage that. >> >> I have a fix that I will submit to RcppArmadillo as a pull request in a >> few moments. >> >> Thanks for the bug report! >> >> Kevin >> >> >> On Sun, Apr 20, 2014 at 11:36 AM, Dirk Eddelbuettel <[email protected]>wrote: >> >>> >>> On 20 April 2014 at 20:18, Mitov Venelin wrote: >>> | Hi Dirk, >>> | >>> | Had a look at your example (function named venelin). It seems to me >>> that the problem is not only the const qualifier but also the passing of an >>> argument by reference. >>> | >>> | uvec touvec(uvec& v) { //fails! >>> | return v; >>> | } >>> | >>> | uvec touvec(uvec v) { // works! >>> | return v; >>> | } >>> | >>> | Don’t know if this helps…. >>> >>> It seems the combination of either/or/both const and & AND use of uvec >>> triggers this. A base uvec vector seems to pass in fine, as does const >>> ref >>> use of a normal int vector. >>> >>> I think we are being tripped up by a partial conversion. We will try to >>> get >>> to it. In the meantime, maybe just avoid 'uvec' which has no direct R >>> counterpart. >>> >>> Dirk >>> >>> -- >>> Dirk Eddelbuettel | [email protected] | http://dirk.eddelbuettel.com >>> _______________________________________________ >>> Rcpp-devel mailing list >>> [email protected] >>> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel >>> >> >> > -- Venelin MITOV
_______________________________________________ Rcpp-devel mailing list [email protected] https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
