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

[Venelin Mitov]

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 <kevinushey at gmail.com>:

> 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
>>>
>>
>>
>


-- 
Venelin MITOV
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20140420/253f8e33/attachment-0001.html>