From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7618 invoked by alias); 18 Aug 2008 21:12:33 -0000 Received: (qmail 7608 invoked by uid 22791); 18 Aug 2008 21:12:32 -0000 X-Spam-Check-By: sourceware.org Received: from mail.phy.duke.edu (HELO mail.phy.duke.edu) (152.3.182.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 18 Aug 2008 21:11:20 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.phy.duke.edu (Postfix) with ESMTP id B307B1501A1; Mon, 18 Aug 2008 17:11:17 -0400 (EDT) Received: from mail.phy.duke.edu ([127.0.0.1]) by localhost (mail.phy.duke.edu [127.0.0.1]) (amavisd-new, port 10026) with LMTP id EIXBoFNrrGte; Mon, 18 Aug 2008 17:11:17 -0400 (EDT) Received: from phy12.phy.duke.edu (phy12.phy.duke.edu [152.3.183.112]) by mail.phy.duke.edu (Postfix) with ESMTP id 88F4C150196; Mon, 18 Aug 2008 17:11:17 -0400 (EDT) Date: Mon, 18 Aug 2008 21:12:00 -0000 From: "Robert G. Brown" To: Brian Gough cc: GSL Discussion list Subject: Re: RNG question In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Mailing-List: contact gsl-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gsl-discuss-owner@sourceware.org X-SW-Source: 2008-q3/txt/msg00018.txt.bz2 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