[Rcpp-devel] sugar under Wingows/g++ (MinGW) odd behavior.

[Dominick Samperi]

On Sat, Jan 15, 2011 at 4:15 AM, Romain Francois
<romain at r-enthusiasts.com>wrote:

> Le 13/01/11 16:29, Dominick Samperi a écrit :
>
>  The template expression code is very interesting, but it
>> does not work as expected under
>> Windows/g++/MinGW/32bit/Rterm.exe. The problem
>> does not appear when I use Rgui.exe, or if I use
>> 64bit Windows!
>>
>> Consider the following C++ code called using
>> .Call('testsugar',1:5,1:5):
>>
>> RcppExport SEXP testsugar(SEXP x_, SEXP y_) {
>>     Rcpp::NumericVector x(x_), y(y_);
>>     Rprintf("%d, %lf, %lf\n", (x+y).size(), (x+y)[0], (x+y)[1]);
>>     return R_NilValue;
>> }
>>
>> Under Linux/GCC, or 64bit Windows/g++, or
>> 32bit Windows/g++ I get the expected result:
>>
>> 5, 2.0, 4.0
>>
>> Under Windows/32bit/Rterm.exe I get:
>>
>> 5, 0.0, 0.0
>>
>
> Intriguing. Maybe Rprintf is to blame. Can you try this instead:


>
> RcppExport SEXP testsugar(SEXP x_, SEXP y_) {
>    Rcpp::NumericVector x(x_), y(y_);
>        int n = (x+y).size() ;
>        double xy0 = (x+y)[0] ;
>        double xy1 = (x+y)[1] ;
>    Rprintf("%d, %lf, %lf\n", n, xy0, xy1);
>    return R_NilValue;
>
> }
>

 Good guess, I found a problem with Rprintf yesterday, but this
will not fix it. The problem is not caused by the arbitrary evaluation
order of the arguments to Rprintf. It is caused by the different
behavior of the format control "%lf" under different architectures!
In particular, the problem goes away under i386/32bit Windows using
MinGW/g++ when "%lf" is replaced with "%f". I could not find this
documented anywhere.

Of course, this has nothing to do with Rcpp, and it might
be of interest to r-devel.

For me this was just a distraction because the problem with
Visual C++ is still alive and well and has nothing to do with
Rprintf. As this information might be helpful in other
(non-VC++) contexts here is what I am seeing.

Consider:

RcppExport SEXP testsugar(SEXP x_, SEXP y_) {
    Rcpp::NumericVector x(x_), y(y_);
    Rprintf("val = %f\n", (x+y)[0]);
    return R_NilValue;
}

This goes through operator+(lhs,rhs) in plus.h, which triggers the
construction of an object of type Plus_Vector_Vector, and the
construction seems to happen without problems, because the
following Rprint's print what you would expect in the
constructor:

Rprintf("RTYPE = %d\n", RTYPE); // get 14, REALSXP
Rprintf("size: %d, %d, %d\n", lhs.size(), rhs.size(), this->size()); // 5,
5, 5
Rprintf("vals: %f, %f, %f, %f\n", lhs[0], rhs[0], lhs[1], rhs[1]); // 1.0,
1.0, 2.0, 2.0
Rprintf("ptrs: %p, %p\n", &lhs, &rhs); // reasonable addresses

But when you leave the constructor the two objects lhs and rhs get
clobbered, even though their respective addresses seem not to
change. In particular, the following print statements when inserted
into operator[](int i) show garbage (and sometimes cause a crash):

Rprintf("ptrs: %p, %p\n", &lhs, &rhs); // this is OK, same addresses as
above
Rprintf("lhs_ = %f\n", lhs_); // 0.0 or garbage
Rprintf("rhs_ = %f\n", rhs_); // 0.0 or garbage
Rprintf("size = %d\n", lhs.size()); // usually crashes.

Dominick


>  (Under VC++ there are more serious problems including
>> corruption of other in the wrap-up function
>> Vector(VectorBase& other), but since VC++ is not
>> supported I will not elaborate here.)
>>
>> Thanks,
>> Dominick
>>
>
>
> --
> Romain Francois
> Professional R Enthusiast
> +33(0) 6 28 91 30 30
> http://romainfrancois.blog.free.fr
> |- http://bit.ly/fT2rZM : highlight 0.2-5
> |- http://bit.ly/gpCSpH : Evolution of Rcpp code size
> `- http://bit.ly/hovakS : RcppGSL initial release
>
>
> _______________________________________________
> 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/20110115/d0baddda/attachment.htm>