This is the mail archive of the
gsl-discuss@sourceware.org
mailing list for the GSL project.
More dieharder stuff
- From: "Robert G. Brown" <rgb at phy dot duke dot edu>
- To: GSL Discussion list <gsl-discuss at sources dot redhat dot com>
- Date: Wed, 19 Jul 2006 18:47:41 -0400 (EDT)
- Subject: More dieharder stuff
OK, so I was missing one test (there are a lot of them and I miscounted)
-- NOW dieharder has all of the diehard tests on board.
I've also written a LONG documentation PDF on the tool and random number
testing in general (preparatory to writing a paper on the subject,
maybe) and included in /usr/share/doc in the RPM and in the tarball just
lying around (it should probably be in the docs subdirectory, hmmm).
I have a couple of questions for the list and GSL developers in general
about RNGs.
a) Are there any plans to put a BBS (Blum-Blum-Shub) RNG into the GSL?
It is supposedly slow but cryptographically strong and I'd like to
verify that in dieharder as I start to work on the crypto tests from
STS. If I write one in a standard GSL wrapper, will you add it?
b) I've written GSL-compatible RNG wrappers for /dev/random and
/dev/urandom for systems where they exist. /dev/random in particular is
a good source of seeds for both simulations and cryptography, and
writing a file based snippet to do so in code is a PITA compared to
using a GSL call.
c) Indeed, adding a gsl_newseed() function that uses /dev/random if
available and black magic if not to make a "high quality seed" is a
really good idea. Naturally I have a routine that does this that I move
around into my code as needed, but the whole point of a library is to
not have to write or maintain commonly used reusable code any more. I'd
be happy to take a stab at writing this, as well, if adding the function
is acceptable.
d) I also have written GSL-compatible wrappers for file based input of
random numbers, as people persist in wanting to test rands from files
instead of wrapping them up GSL-style even though I provide them nice
templates for doing so in dieharder. The raw binary interface in
particular seems like it would be a useful addtion to the GSL itself
(formatted ascii input works for a lot of the scanf formats, but is a
bit more of a PITA). Any takers?
Just suggetions.
rgb
--
Robert G. Brown http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@phy.duke.edu