[Rcpp-devel] Broken conversion from R-type integer to uvec after update to newer Rcpp version

[Kevin Ushey]

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 <kevinushey at gmail.com> 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 <edd at debian.org>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 | edd at debian.org | http://dirk.eddelbuettel.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: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20140420/90eecc00/attachment.html>