arma::randu incorrect output about rcpparmadillo HOT 14 CLOSED

Before I dive into this any further are you aware that we on purpose and by default wire RcppArmadillo up with the R RNGs so that seeding from R works as expected? See inst/tinytest/test_rng.R (in the source, installed as tinytest/test_rng.R). There is also a config option to not to this if you'd rather have the default behavior, you would need this for your first example.

From glancing at RcppArmadilloForward.h it seems that setting a #define ARMA_USE_CXX11_RNG

from rcpparmadillo.

I did not know that RNGs from R were used. Is it just the seed or the whole RNG? Regardless, this is not the expected behavior.

from rcpparmadillo.

It is the expected and documented behaviour for the R package connecting Armadillo to R.

from rcpparmadillo.

Also your first code example is just wrong. You never use R headers with a main(). If you want plain Armadillo for your own projects, I think you know where to get it. This package is for using Armadillo from R by via Rcpp.

> Rcpp::cppFunction("arma::mat outerProd(arma::vec& x) { return x * x.t(); }", depends="RcppArmadillo")
> outerProd(1:3)
     [,1] [,2] [,3]
[1,]    1    2    3
[2,]    2    4    6
[3,]    3    6    9
> 

from rcpparmadillo.

Sure thing. I noticed this behavior in the Rcpp code I was writing for my package. I am no Rcpp Internals expert, and I wanted to see whether it can reproduced in a plain C++ file, hence the examples I posted.

from rcpparmadillo.

For use from R, we connect to R's seeding and RNGs:

> Rcpp::cppFunction("arma::vec myrand(int n) { return arma::vec(n, arma::fill::randu); }", depends="RcppArmadillo")
> set.seed(123); myrand(4)
         [,1]
[1,] 0.287578
[2,] 0.788305
[3,] 0.408977
[4,] 0.883017
> set.seed(123); myrand(4)      # reproducibility from R which is what R users want
         [,1]
[1,] 0.287578
[2,] 0.788305
[3,] 0.408977
[4,] 0.883017
> myrand(4)                      # else random
          [,1]
[1,] 0.9404673
[2,] 0.0455565
[3,] 0.5281055
[4,] 0.8924190
> 

from rcpparmadillo.

This works on my system also. So maybe this is something relating to the compile flags?

from rcpparmadillo.

Can please calmly explain what you think your problem is? Your initial post (1st par above) is plain invalid. You cannot use RcppArmadillo that way. End of story.

If you think you have a deficieny in using RcppArmadillo from and with R, please document it here.

from rcpparmadillo.

Also:

> Rcpp::cppFunction("arma::vec myrand(int n) { return arma::vec(n, arma::fill::randu); }", depends="RcppArmadillo")
> v <- myrand(1e6)
> summary(v)
       V1          
 Min.   :0.000001  
 1st Qu.:0.249158  
 Median :0.499153  
 Mean   :0.499528  
 3rd Qu.:0.749496  
 Max.   :1.000000  
> 

There are also many far more sophisticated ways to look at the distribution of a sampled vector in a statistical environment such as R ...

from rcpparmadillo.

Also note that you used rand() whose manual page on my Ubuntu machine says not to use it:

NOTES

The versions of rand() and srand() in the Linux C Library use the same random number generator as random(3) and srandom(3), so the lower‐order bits should be as random as the higher‐order bits.
However, on older rand() implementations, and on current implementations on different systems, the lower‐order bits are much less random than the higher‐order bits. Do not use this function in ap‐
plications intended to be portable when good randomness is needed. (Use random(3) instead.)

from rcpparmadillo.

At this point, we need to agree upon a minimum reproducible example. I don't know why the inclusion of the main() makes the behavior invalid, but I am not here to dispute that. Do you want me to try and reproduce that by developing a small Rcpp package?

I came across this behavior while trying to initialize a vector with arma::randu while developing my Rcpp package. There, I did not include a main() call and I was getting the same behavior.

Maybe generating a dynamic library which is loaded during runtime (in R) can reproduce the behavior? (Pure speculation)

from rcpparmadillo.

You seem fairly new to Rcpp and its tools so I will give you time to catch up. The Extending R with Rcpp introductory vignette included with the package (and a published paper) is a good start, it even covers simulation via random number generation. And you do not need a main (those build very differently) and you do not need a package (though a package is a good idea in general). I have shown you several one-line examples, you would find other for examples at the Rcpp Gallery. At this point it is most likely that you overlooked or misunderstood a small step somewhere so I will close this now. When you have an actual reproducible error by all means to come back and reopen. Until then, trust 15 years of RcppArmadillo in widespread use: it is a robust tool.

from rcpparmadillo.

Also note that you used rand() whose manual page on my Ubuntu machine says not to use it:

NOTES
The versions of rand() and srand() in the Linux C Library use the same random number generator as random(3) and srandom(3), so the lower‐order bits should be as random as the higher‐order bits.
However, on older rand() implementations, and on current implementations on different systems, the lower‐order bits are much less random than the higher‐order bits. Do not use this function in ap‐
plications intended to be portable when good randomness is needed. (Use random(3) instead.)

There is this great talk that explains this in more detail: https://www.youtube.com/watch?v=LDPMpc-ENqY

I ended up using other std::mt19937 from the std c++ library:

https://github.com/pati-ni/harmony/blob/census-integration/src/utils.cpp#L26C8-L26C15

I will give myself some time catching up with Rcpp and will come again with more information, thanks

from rcpparmadillo.

Absolutely. There are also a couple great RNG packages for R such as dqrng.

from rcpparmadillo.