This is the mail archive of the gsl-discuss@sourceware.org mailing list for the GSL project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]