To finish up this thread, it turns out that the VC++ problems did<br>help to reveal an architecture-dependent behavior of Rprintf <br>(under GCC) that<br>developers probably should be aware of, and it also points to<br>a potential problem with the way temporary references are<br>
initialized in the expression template code.<br><br>On the other hand, the non-Rprintf related problems seem to<br>be due to the fact that I did not update RcppCommon.h in<br>my VC++ builds. After updating RcppCommon.h (and adding<br>
VC++ to the list of supported compilers), the expression<br>template code works fine. I still get the warnings about the<br>initialization of reference temporaries though.<br><br>On Rprintf, it is safest to not use format controls like<br>
"%lf" and "%Lf". Use "%f" instead. Since I have programmed<br>in C/C++ for a long time I was in the habit of using "%lf",<br>but the "l" qualifier has since been redefined to apply to<br>
ints (and long ints) only, and "%Lf" is intended for use<br>with 'long double' type.<br><br>Dominick<br><br><div class="gmail_quote">On Sun, Jan 16, 2011 at 3:34 PM, Dominick Samperi <span dir="ltr"><<a href="mailto:djsamperi@gmail.com">djsamperi@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">It appears that this is a matter of compiler interpretation of the C++ standards,<br>and it is not easy to see which compiler is correct (g++ or VC++).<br>
<br>When I disable the VC++ work-around I get the following warning from this<br>
compiler about the Plus_Vector_Vector constructor:<br><br>c:\w\dev\stats\rbuild\Rcpp\inst\include\Rcpp/sugar/operators/plus.h(39): warning C4413: 'Rcpp::sugar::Plus_Vector_Vector<RTYPE,LHS_NA,LHS_T,RHS_NA,RHS_T>::lhs' : reference member is initialized to a temporary that doesn't persist after the constructor exits<br>
<br>Obviously this is perfectly consistent with the kind of problem I reported earlier in<br>this thread. What is not obvious is why the reference is initialized to<br>a temporary. <br><br>I tried reproducing the problem (using VC++) with a simpler example taken from<br>
the Wiki page on expression templates. I simply added a get_ref() method<br>and used this in the VecDifference constructor initialization. There were no<br>warnings and the program ran without problems, so the reason for the<br>
warning in the case of Rcpp expression templates is not clear.<br><br>The C++0x standard includes some changes in the way references are<br>handled. I don't know if this is relevant.<br><font color="#888888"><br>Dominick</font><div>
<div></div><div class="h5"><br><br><div class="gmail_quote">
On Sat, Jan 15, 2011 at 10:55 PM, Dominick Samperi <span dir="ltr"><<a href="mailto:djsamperi@gmail.com" target="_blank">djsamperi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Romain,<br><br>I found a work-around for the VC++ problem. All I have to do<br>is make sure the code that is currently ifdef-ed in Extractor.h<br>is NOT enabled under VC++ (when _MSC_VER is defined).<br>Currently this code is conditionally compiled with<br>
#ifndef IF_GCC_450_OR_LATER, so the additional condition<br>
that _MSC_VER is NOT defined must be added, and only<br>
the identity class at the top of Extractor.h is used.<br>
<br>A comment in this file suggests that you have already<br>observed problems under windows with Rcpp::Fast<br>vector extraction, presumably with MinGW/g++. The<br>comment goes on to say that it may be a g++ 4.5<br>issue and not a Windows issue. Obviously this thread<br>
has shown that this is not the complete story.<br><br>I do not know why VC++ has a problem with<br>Rcpp::Fast vector extraction. With all of the pointer<br>manipulation it may have something to do with<br>incompatible word sizes, memory alignment,<br>
or related low-level issues.<br><br>Thanks,<br><font color="#888888">Dominick</font><div><div></div><div><br><br><div class="gmail_quote">On Sat, Jan 15, 2011 at 2:27 PM, Dominick Samperi <span dir="ltr"><<a href="mailto:djsamperi@gmail.com" target="_blank">djsamperi@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">So that there is no confusion, I should add that the problems that I report<br>here do not occur under Linux/g++ or under MinGW/g++ (the supported<br>
environments), where Rcpp/sugar seems to work fine.<div><div></div><div><br><br><div class="gmail_quote">
On Sat, Jan 15, 2011 at 1:23 PM, Dominick Samperi <span dir="ltr"><<a href="mailto:djsamperi@gmail.com" target="_blank">djsamperi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br><br><div class="gmail_quote"><div><div></div><div>On Sat, Jan 15, 2011 at 4:15 AM, Romain Francois <span dir="ltr"><<a href="mailto:romain@r-enthusiasts.com" target="_blank">romain@r-enthusiasts.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Le 13/01/11 16:29, Dominick Samperi a écrit :<div><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
The template expression code is very interesting, but it<br>
does not work as expected under<br>
Windows/g++/MinGW/32bit/Rterm.exe. The problem<br>
does not appear when I use Rgui.exe, or if I use<br>
64bit Windows!<br>
<br>
Consider the following C++ code called using<br>
.Call('testsugar',1:5,1:5):<br>
<br>
RcppExport SEXP testsugar(SEXP x_, SEXP y_) {<br>
Rcpp::NumericVector x(x_), y(y_);<br>
Rprintf("%d, %lf, %lf\n", (x+y).size(), (x+y)[0], (x+y)[1]);<br>
return R_NilValue;<br>
}<br>
<br>
Under Linux/GCC, or 64bit Windows/g++, or<br>
32bit Windows/g++ I get the expected result:<br>
<br>
5, 2.0, 4.0<br>
<br>
Under Windows/32bit/Rterm.exe I get:<br>
<br>
5, 0.0, 0.0<br>
</blockquote>
<br></div>
Intriguing. Maybe Rprintf is to blame. Can you try this instead:</blockquote><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div>
<br>
<br>
RcppExport SEXP testsugar(SEXP x_, SEXP y_) {<br>
Rcpp::NumericVector x(x_), y(y_);<br></div>
int n = (x+y).size() ;<br>
double xy0 = (x+y)[0] ;<br>
double xy1 = (x+y)[1] ;<br>
Rprintf("%d, %lf, %lf\n", n, xy0, xy1);<br>
return R_NilValue;<div><br>
}<br></div></blockquote></div></div><div><br> Good guess, I found a problem with Rprintf yesterday, but this<br>
will not fix it. The problem is not caused by the arbitrary evaluation<br>
order of the arguments to Rprintf. It is caused by the different<br>
behavior of the format control "%lf" under different architectures!<br>
In particular, the problem goes away under i386/32bit Windows using<br>
MinGW/g++ when "%lf" is replaced with "%f". I could not find this<br>
documented anywhere.<br><br>Of course, this has nothing to do with Rcpp, and it might<br>be of interest to r-devel.<br><br>For me this was just a distraction because the problem with<br>Visual C++ is still alive and well and has nothing to do with<br>
Rprintf. As this information might be helpful in other <br>(non-VC++) contexts here is what I am seeing.<br><br>Consider:<div><br><br>RcppExport SEXP testsugar(SEXP x_, SEXP y_) {<br> Rcpp::NumericVector x(x_), y(y_);<br>
</div> Rprintf("val = %f\n", (x+y)[0]);<br>
return R_NilValue;<br>}<br><br>This goes through operator+(lhs,rhs) in plus.h, which triggers the<br>construction of an object of type Plus_Vector_Vector, and the<br>construction seems to happen without problems, because the<br>
following Rprint's print what you would expect in the<br>constructor:<br><br>Rprintf("RTYPE = %d\n", RTYPE); // get 14, REALSXP<br>Rprintf("size: %d, %d, %d\n", lhs.size(), rhs.size(), this->size()); // 5, 5, 5<br>
Rprintf("vals: %f, %f, %f, %f\n", lhs[0], rhs[0], lhs[1], rhs[1]); // 1.0, 1.0, 2.0, 2.0<br>Rprintf("ptrs: %p, %p\n", &lhs, &rhs); // reasonable addresses<br><br>But when you leave the constructor the two objects lhs and rhs get<br>
clobbered, even though their respective addresses seem not to<br>change. In particular, the following print statements when inserted<br>into operator[](int i) show garbage (and sometimes cause a crash):<br><br>Rprintf("ptrs: %p, %p\n", &lhs, &rhs); // this is OK, same addresses as above<br>
Rprintf("lhs_ = %f\n", lhs_); // 0.0 or garbage<br>Rprintf("rhs_ = %f\n", rhs_); // 0.0 or garbage<br>Rprintf("size = %d\n", lhs.size()); // usually crashes.<br><font color="#888888"><br>Dominick<br>
<br></font></div><div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
(Under VC++ there are more serious problems including<br>
corruption of other in the wrap-up function<br>
Vector(VectorBase& other), but since VC++ is not<br>
supported I will not elaborate here.)<br>
<br>
Thanks,<br>
Dominick<br>
</blockquote>
<br>
<br></div>
-- <br>
Romain Francois<br>
Professional R Enthusiast<br>
+33(0) 6 28 91 30 30<br>
<a href="http://romainfrancois.blog.free.fr" target="_blank">http://romainfrancois.blog.free.fr</a><br>
|- <a href="http://bit.ly/fT2rZM" target="_blank">http://bit.ly/fT2rZM</a> : highlight 0.2-5<br>
|- <a href="http://bit.ly/gpCSpH" target="_blank">http://bit.ly/gpCSpH</a> : Evolution of Rcpp code size<br>
`- <a href="http://bit.ly/hovakS" target="_blank">http://bit.ly/hovakS</a> : RcppGSL initial release<br>
<br>
<br>
_______________________________________________<br>
Rcpp-devel mailing list<br>
<a href="mailto:Rcpp-devel@lists.r-forge.r-project.org" target="_blank">Rcpp-devel@lists.r-forge.r-project.org</a><br>
<a href="https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel" target="_blank">https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel</a><br>
</blockquote></div></div><br>
</blockquote></div><br>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br>