2

i have the following problem (and cannot really produce a minimal test)-- i am porting a package from C++ via Rcpp to R. the tests (i am testing if the output matrix is exactly what i would get if calling c++ directly) under linux and osx are absolutely equal, no difference.

but when testing either via build_win() or via a win 8.1 virtual machine i get different results (but the results between both are consistent, so i have linux/osx vs win results) i already replaced the one rand() call with the corresponding Rcpp sugar, so this should be no problem (i hope at least). as calling the tests via "R -d valgrind" also produce no error, i am a bit puzzled how to proceed. all tests are done with R 3.2.0 (local machines) and latest unstable (via build_win()) so my questions are:

  • are there any known Rcpp differences when compiling (e.g. the compiler provided by Rtools on windows is too old and therefore numeric computations (using STL, no other library like boost/eigen etc) are expected to be slightly different?
  • is there a good way to debug the problem? i would need to trace basically the C++ code line by line, i am even not sure how to do that except for heavy std::couts.

thanks.

complexM
  • 337
  • 1
  • 2
  • 8
  • i just realize that the i386/x64 results from build_win() are different, so might hint to 32/64bit problems in the code. will try to google, what i possibly did wrong. – complexM Jun 18 '15 at 14:17
  • ok, its a 32bit vs 64bit problem, as an ubuntu 15.04 with 32bit did yield different results than my ubuntu 15.04 with 64bit. – complexM Jun 18 '15 at 15:10
  • now it becomes even more weird: if i run the script via command line directly (R --vanilla < ./demo.R) i get the wrong results in 32bit. but if i go ahead and let it run through valgrind to debug (R -d "valgrind" --vanilla < demo.R) i get the *correct* results. is valgrind fixing some R bugs?? :/ – complexM Jun 23 '15 at 10:27

1 Answers1

1

the truth about the 32bit/64bit problem is indeed written up here different behaviour or sqrt when compiled with 64 or 32 bits

adding the -ffloat-store option did fix my problem. never expected that, thought the problem is in the source code.

Community
  • 1
  • 1
complexM
  • 337
  • 1
  • 2
  • 8
  • Hey, I am having the same problem. Where do I specify -ffloat-store? Do I just add that to my .cpp file? Do I have to tell -ffloat-store to the compiler somehow? Thanks – Carl Dec 07 '15 at 01:48
  • 2
    you add this to the Makevars file in the src directory, and like this: PKG_CXXFLAGS= -ffloat-store (so the whole file is just that line, in case you do not have this already). please note that this did NOT fix my problem. somehow there were over/underflows in the code (i believe), and this again will be handled differently on each platform it seems. finally i just hard-rounded the floating numbers in that code section to 14 digits and this way i could make sure every platform computes the same. – complexM Dec 08 '15 at 07:48
  • Worked for me, thanks @complexM. I had Rcpp code on a 64bit Windows laptop. I was doing a pairwise summation over 25000 points so ~25000^2 computations and storing in `double` vars. The laptop result was 7.04 but the HPC Linux cluster was 7.59! If this hadn't worked, my only other solution would've been changing `double` to `long double` in my .cpp code. – Timothy M Pollington Sep 10 '21 at 11:57