Added random number generator unit tests (closes #28) #514

Merged
merged 3 commits into from Jul 24, 2016

Projects

None yet

2 participants

@coatless
Contributor

Adds unit test for random generation for the R:: namespace where Rmath
is kept.

Added section breaks in C++ code for each distribution

@coatless coatless Added random number generator unit tests (closes #28)
Adds unit test for random generation for the R:: namespace where Rmath
is kept.

Added section breaks in C++ code for each distribution
fceeff5
@eddelbuettel
Member

That's nice. Setting the seed 'on both sides' makes sure we didn't spill the milk.

@eddelbuettel
Member

When I merge #513 this one will conflict as both alter Changelog.

@coatless
Contributor

I'll resync with main branch and then reload this commit.

@coatless
Contributor
coatless commented Jul 22, 2016 edited

Weird, works fine under the local check. I'll look into the failure.

I have a funny feeling it is due to the RNG seed generation difference.

https://travis-ci.org/RcppCore/Rcpp/builds/146754299#L4243-L4292

@eddelbuettel
Member

But Travis 'just' running Ubuntu Linux too.

I think we can mod this part of .travis.yml:

after_failure:
  - ./travis-tool.sh dump_logs

and look into what the shell script for dump_logs and add to that.

@coatless coatless Force default RNG Kind & RNG Normal in testing environment to be "Mer…
…seene-Twister" and "Inversion" (the defaults).

Switched from = to <- in file.
db68cba
@eddelbuettel
Member

@coatless and I took this off-line and found that the concatenation of two subvectors, ie c(a1, a2) appears to results in c(a2, a1) making the comparison fail.

@coatless
Contributor

@eddelbuettel : Modified the test bit to avoid having to rev() the vector.

Cpp now generates under a for instead of ::create()

R now generates under the vectorized r*(n,...) functions.

Though, this exercise did reveal something interesting: The concatenation order differs between R & Cpp. I'm still trying to repo this on my end. Might be a bigger bug.

@eddelbuettel
Member

Not sure it is a bug or a just a, well, hesitating, err, feature. The way you had lined up your expression, these were actually not yet evaluated. So we are racing against both concatenation and whether evaluation happens a certain way. Could be a tricky corner to play in.

@eddelbuettel
Member

There is one thing that this now lacks (but which we can add): vectorised, ie sugar, accessors. Ie when you do

NumericVector o(5);

for(int i = 0; i < o.size(); i++)
        o[i] = R::rnorm(a, b);

you are testing the (scalar) accessor from Rmath via the R:: namespace. We also need

RcppNumericVector o = Rcpp::rnorm(5, a, b);

but that can be added.

@eddelbuettel eddelbuettel merged commit 4cee7ca into RcppCore:master Jul 24, 2016

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@eddelbuettel
Member

I started to add some more in this new branch via this first commit.

@coatless coatless deleted the unknown repository branch Jul 24, 2016
@coatless
Contributor

@eddelbuettel I have no write access on that branch =(

@eddelbuettel
Member

It's ok -- I'm already done.

@coatless
Contributor

@eddelbuettel

Need to also do sugar testing for p/d/q * functions as well.

@eddelbuettel
Member

Maybe, maybe not. The the very highest priority but we should keep it in mind. It is really just looping over scalar version. The 'r' variants are equally close but do have the RNG draw business so are potentially more easily breakable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment