Re: RNG question

["Robert G. Brown" <rgb@phy.duke.edu>]

On Fri, 8 Aug 2008, Robert G. Brown wrote:

>> The macro is really an internal implementation detail and not intended
>> to be a limit (as far as I'm aware it's not publically accessible).
>> There are currently about 60 generators so if you wanted to give them
>> numbers 100 is too small but 1000 or 500 shouldn't be a problem.
>
> I looked over the code again and decided that was probably true on my
> own.  I'm preparing to basically clone the types.c module but create a
> larger vector of types.  I'll then run through a loop to populate it
> with the gsl ones, then add my own, in ranges.

I've done exactly this, and it works fine in dieharder 2.27.11.

If you are interested in contributed rngs all wrapped up and ready to
literally drop into place, let me know.  I have gsl-ready code for the
hardware/entropy /dev/random "generator", the related /dev/urandom
"generator" and the (BSD) /dev/arandom "generator" if you'd like it.  I
put these inside conditionals so that they are only added and show up in
the list of available generators (which I generate with fairly obvious
code) if they exist.

A suggestion:  I cannot realloc the built-in types[] (I'm pretty sure)
because it is statically allocated in types.c.  Right now in order to
get a types[] long enough to hold the GSL generator and the various
source dieharder generators in ranges, I have to allocate space for e.g.
dieharder_types[1000], create a pointer to gsl_types, initialize
gsl_types with gsl_rng_types_setup(), and then copy over the types (or
duplicate the specific code in gsl_rng_types_setup(), which then might
change without warning as GSL bumps a version and leave dieharder out of
sync with GSL where they overlap).  I then fill in my own and
contributed and R-derived generators in various ranges in
dieharder_types and it all works fine, BUT it is a bit of a hassle and
the alternative is a segment violation.

So, a minor request for a future snapshot of the GSL:  I think that if
you JUST increased N to 1000 (and maybe set the entire types vector to
zero before filling it as that makes it easy to test for where
generators are installed in the types vector) it wouldn't affect current
code in any way -- as you say it is hidden inside the source -- but it
would keep me from having to allocate a types[] vector of my own as I
could then just fill in the upper ranges of the one returned by the GSL.
I can easily imagine filling up the GSL-provided vector with only 100
slots, but I think it will take a bit of time to fill up a GSL-provided
types vector with 1000 slots.

> Are future/new rngs going to always be added at the end (new numbers) or
> will they get inserted in typed groupings?  I ask because IIRC the new
> MT's went in next to the original MT and displaced all the numbers.
> This makes logical sense, but breaks code that has hard coded rng
> numbers.  I can make dieharder work either way, but to lock in the
> numbers in dieharder in the latter case I have to work harder...;-).

I've decided to stick with the GSL numbers rigorously (reserving the
bottom 200 for the current GSL and any future expansion) -- if they
shift they shift.  Just remember that if you add new e.g. MT's grouped
in with the old ones (and displace e.g. the taus generators up a couple
of number-notches) you WILL break a lot of code that uses the old
numbers (which will all change).  I personally don't care -- dieharder
documents the generator name-to-number match automagically -- but
somebody that selected a generator by number in simulation code might
not notice and could end up getting "wrong answers" in the worst case
scenario as they run a few hundred CPU-months of simulation using a
different generator from the one they thought they were using...;-)

     rgb

-- 
Robert G. Brown                            Phone(cell): 1-919-280-8443
Duke University Physics Dept, Box 90305
Durham, N.C. 27708-0305
Web: http://www.phy.duke.edu/~rgb
Book of Lilith Website: http://www.phy.duke.edu/~rgb/Lilith/Lilith.php
Lulu Bookstore: http://stores.lulu.com/store.php?fAcctID=877977