An updated version 0.2.2 of the random-number generator tester RDieHarder (based on the DieHarder suite developed / maintained by Robert Brown with contributions by David Bauer and myself) is now on CRAN.
I should dub this the ‘due to Brian Ripley’ release. He sent me a detailed five-point email a few days ago which detailed a change I could not have tested (“no access”), a change I would not have known (“somewhat obscure C language bit-level manipulation”), a change I had missed (how my build setup failed for M1mac), another advanced C level fix, and one more simple fix I actually knew. Speechless. The man (I presume) does not sleep and is just so generous with his time and expertise.
So based on the input I rejigged the package over the weekend and made two more (substantial) changes. First, extending on what 0.2.0 brought, I will no longer attempt to use an external
libdieharder library (or build one on the fly) – that was issue one. Now we just declare all C files as dependents of the package shared library, and things are simpler and more consistent. Sadly, that also implies “everything is in the package” so I had to edit out a metric ton of
exit() reference with the appropriate R C API hooks to appease the CRAN Policy deities. Win some, loose some. But the package is now simpler, and cleaner, and should be in good standing. (Or so one hopes. Earlier today, and within hours of it hitting CRAN, I got an issue ticket from a motivated user about yet another (“mostly harmless” in the Douglas Adams sense) compiler warning… Good now too.)
If you like this or other open-source work I do, you can now sponsor me at GitHub.
A new version, now at 0.2.1, of the random-number generator tester RDieHarder (based on the DieHarder suite developed / maintained by Robert Brown with contributions by David Bauer and myself) is now on CRAN.
This version has only internal changes. Brian Ripley, tireless as always, is testing the impact of gcc 10 on CRAN code and found that the ‘to-be-default’ option
-fno-common throws off a few (older) C code bases, this one (which is indeed old) included. So in a nutshell, we declared all global variables
extern and defined them once and only once in new file
globals.c. Needless to say, this affects the buildability options. In the past we used to rely on an external library libdieharder (which e.g. I had put together for Debian) but we now just build everything internally in the package.
Which builds on the changes in RDieHarder 0.2.0 which I apparently had not blogged about when it came out on December 21 last year. I had refactored the package to use either the until-then-required-but-now-optional external library, or the included library code. Doing so meant more builds on more systems including Windows.
This (very old) package has no NEWS.Rd file to take a summary from, but the ChangeLog file has all the details.
Per a CRAN email sent to 300+ maintainers, this package (just like many others) was asked to please register its S3 method. So we did, and also overhauled a few other packagaging standards which changed since the last upload in 2014.
No NEWS.Rd file to take a summary from, but the top of the ChangeLog has details.
vignettes/to help finalize that transition of the R / CRAN Package Policy. Courtesy of CRANberries, there is also a diffstat report relative to the previous release. As always, more detailed information is on the RDieHarder page.
The package still comes with a vignette describing both DieHarder and the RDieHarder package. And because pictures speak louder than a thousand (blogged) words, here is the first chart from the vignette:
ran0function. The histogram illustrating the distribution of test scores is somewhat uneven. An ideal (and asymptotic) outcode is a uniform distribution of p-values from the test. The empirical cumulative distribution function (ECDF) below indicates a somewhat pronounced departure from the diagonal. Informally speaking, this is what the (Kuiper-)Kolmogorov-Smirnov test quantifies, and we see (in the text in the chart) that the null of can be rejected an conventional levels. Based on this example (which had a short run-time with few samples) we would indeed mistrust this (known bad) RNG.
On the right, we have a more recent and trusted RNG, the well-known Mersenne Twister. The ten histogram buckets are all closer to the expected value of one-tenth, the estimated density is closer to flat, the ECDF is closer to the diagonal and the tests don't reject---so no reason to mistrust this RNG based on this test alone.