RFTrainer causes error about random number generator

[rstub]

This issue is a result of investigating https://stackoverflow.com/questions/45455318/rcppshark-random-forest-example-throws-exception-about-the-random-number-generat

When one tries to follow the example in https://www.2021.ai/randsharkmachinelearning/, one ends up with th error message:

Error in SharkRFTrain(X, Y, nTrees = 100) : 
  Should not call this. Fix the random numbers generator if you need this. 478

This error message is produced here: https://github.com/aydindemircioglu/RcppShark/blob/master/src/shark/Rng/Runif.h#L71

If I run R in gdb, I get the following backtrace at that point:

(gdb) bt
#0  boost::random::rand47::rand47 (x0=<optimized out>, this=<synthetic pointer>)
    at ./shark/Rng/Runif.h:71
#1  shark::RFTrainer::train (this=this@entry=0x7fffffff92d0, model=..., dataset=...)
    at src/Algorithms/RFTrainer.cpp:178
#2  0x00007fffe7493a42 in SharkRFTrain (X=..., Y=..., nTrees=nTrees@entry=100) at RandomForest.cpp:31
#3  0x00007fffe749f122 in mySharkPackage_SharkRFTrain (XSEXP=0x5555573f6e30, YSEXP=<optimized out>, 
    nTreesSEXP=<optimized out>) at RcppExports.cpp:41
#4  0x00007ffff788ecb4 in ?? () from /usr/lib/R/lib/libR.so
#5  0x00007ffff78c71bf in Rf_eval () from /usr/lib/R/lib/libR.so
#6  0x00007ffff78c98b4 in ?? () from /usr/lib/R/lib/libR.so
#7  0x00007ffff78c6fb1 in Rf_eval () from /usr/lib/R/lib/libR.so
#8  0x00007ffff78c887d in Rf_applyClosure () from /usr/lib/R/lib/libR.so
#9  0x00007ffff78c6d8d in Rf_eval () from /usr/lib/R/lib/libR.so
#10 0x00007ffff78caa26 in ?? () from /usr/lib/R/lib/libR.so
#11 0x00007ffff78c6fb1 in Rf_eval () from /usr/lib/R/lib/libR.so
#12 0x00007ffff78cbf17 in ?? () from /usr/lib/R/lib/libR.so
#13 0x00007ffff78bd799 in ?? () from /usr/lib/R/lib/libR.so
#14 0x00007ffff78c6c00 in Rf_eval () from /usr/lib/R/lib/libR.so
#15 0x00007ffff78c887d in Rf_applyClosure () from /usr/lib/R/lib/libR.so
#16 0x00007ffff78bee26 in ?? () from /usr/lib/R/lib/libR.so
#17 0x00007ffff78c6c00 in Rf_eval () from /usr/lib/R/lib/libR.so
#18 0x00007ffff78c74cb in ?? () from /usr/lib/R/lib/libR.so
#19 0x00007ffff78c7220 in Rf_eval () from /usr/lib/R/lib/libR.so
#20 0x00007ffff78cc141 in ?? () from /usr/lib/R/lib/libR.so
#21 0x00007ffff78f9f46 in ?? () from /usr/lib/R/lib/libR.so
#22 0x00007ffff78bd902 in ?? () from /usr/lib/R/lib/libR.so
#23 0x00007ffff78c6c00 in Rf_eval () from /usr/lib/R/lib/libR.so
#24 0x00007ffff78c887d in Rf_applyClosure () from /usr/lib/R/lib/libR.so
#25 0x00007ffff78bee26 in ?? () from /usr/lib/R/lib/libR.so
#26 0x00007ffff78c6c00 in Rf_eval () from /usr/lib/R/lib/libR.so
#27 0x00007ffff78c887d in Rf_applyClosure () from /usr/lib/R/lib/libR.so
#28 0x00007ffff78c6d8d in Rf_eval () from /usr/lib/R/lib/libR.so
#29 0x00007ffff78ee6aa in Rf_ReplIteration () from /usr/lib/R/lib/libR.so
#30 0x00007ffff78eeab1 in ?? () from /usr/lib/R/lib/libR.so
#31 0x00007ffff78eeb68 in run_Rmainloop () from /usr/lib/R/lib/libR.so
#32 0x000055555555489b in main ()
#33 0x00007ffff6ff02b1 in __libc_start_main (main=0x555555554880 <main>, argc=1, argv=0x7fffffffe088, 
    init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe078)
    at ../csu/libc-start.c:291
#34 0x00005555555548da in _start ()

I have tried to go from SHARK_PARALLEL_FOR to normal for and use shark::Rng::globalRng inside of RFTrainer::train, but that only changed the point where the error was thrown.

AFAIK, R extensions must not produce their own random numbers but must use the random number generator configured in R. I don't know how to interface this properly with parallel processing, where independent streams of random numbers are needed. Setting consecutive seeds is probably not the best way to do this. I know, that in R one would normally use an approach like described in section 6 of https://stat.ethz.ch/R-manual/R-devel/library/parallel/doc/parallel.pdf.

[aydindemircioglu]

thanks for the resport, i'll look into it, but it will take some time.
all calls to random number generators inside shark should have been wrapped to use the R version,
but i afaik the number generators in shark did change in the last months. so maybe there are some
new random generators my conversion script does not see.

sorry for the trouble you have. i didn't even know anyone was using this package ;)

[rstub]

Thanks. I have been thinking about this some more. I expect it will be very difficult to use the RNG from R for a parallel program. In Writing R Extensions it says:

Calling any of the R API from threaded code is ‘for experts only’: they will need to read the source code to determine if it is thread-safe. In particular, code which makes use of the stack-checking mechanism must not be called from threaded code.

I am not sure if the RNGs are thread-safe. However, I have also been wondering, where the requirement to use R's RNG comes from. The best I could find is the follwoing

Compiled code should not call the system random number generators such as rand, drand48 and random, but rather use the interfaces to R’s RNGs described in Random numbers. In particular, if more than one package initializes the system RNG (e.g. via srand), they will interfere with each other.

Nor should the C++11 random number library be used.

(https://cran.rstudio.com/doc/manuals/r-release/R-exts.html#Writing-portable-packages, emphasis is mine)

In addition, there exist packages like https://cran.r-project.org/package=RcppZiggurat that include different RNGs. I am not sure what to make from this.

[aydindemircioglu]

hard to tell, i'd first put emphasis to just replace all the RNGs. then at least would run and we can test it.
if it doesnt work because of thread-locking problems, then either we could remove the parallelism
or figure out how to fix it. besides, shark is waiting for a new implementation, see
Shark-ML/Shark#179
and the thing seems to have problems anyway
Shark-ML/Shark#167

is the randomforest feature important to you?

[rstub]

For me it is/was a way of learning about extending R. I will try to get the OP from stackoverflow into the loop.

[OphirCarmi]

I asked the question in stackoverflow that started this thread. The reason I needed this RCppShark-random-forest implementation is because of a benchmark of random forest C++ implementations I did. I am a software developer who works with our AI team. They develop their algorithm in R. I need to implement it in C++. I did the benchmark of several C++ implementation vs. R-Ranger package implementation. It seems that the Shark random forest C++ implementation is very accurate but takes too much time to run. So we wanted to check the R interface of Shark to see If I did something wrong in wrapping the Shark C++ implementation.

[aydindemircioglu]

thanks for the info. i did not use the RFTrainer in shark yet-- and from the above mentioned issue i think your observations are accurate. so is there still a need from your side to get it wrapped? as said, it will take some time, as i currently am not able to work on it. maybe some time next month. if not, i'd rather just wait for the faster RFTrainer implementation that is mentioned in the issue (though this might take much longer?)