From: Nikodemus S. <nik...@ra...> - 2009-10-08 11:24:51
|
SB-KERNEL::INIT-RANDOM-STATE does this currently. I plan to provide an exported interface for this -- marked "experimental" for now, though. I'm currently tempted to just accept a non-zero 32-bit integer as the STATE argument to MAKE-RANDOM-STATE. The other option is to provide a separate SB-EXT:MAKE-RANDOM-STATE-FROM-SEED. Any comments in favor of either? Cheers, -- Nikodemus |
From: Malcolm R. <mal...@gm...> - 2009-10-08 11:37:34
|
> I'm currently tempted to just accept a non-zero 32-bit integer as the > STATE argument to MAKE-RANDOM-STATE. The other option is to provide a > separate SB-EXT:MAKE-RANDOM-STATE-FROM-SEED. I'd have a preference for it being an argument for make-random-state simply because that's where I looked first when I needed to do this a while back (I wanted my unit tests to run/fail deterministically, and i had a machine learning program which used a lot of randomness in generating the tests, so I wanted to load a known state into the rng before each test run). It seems like the logical place to put a fairly core piece of the rng functionality, rather than an extension package. Thanks for adding this, my previous solution was a horrendous hack which involved dumping a random state and saving it in a huge file, using some reader macros I still don't really understand. It'll be great to have a simple method for adding determinism to code that uses #'random. Malcolm |
From: Malcolm R. <mal...@gm...> - 2009-10-08 12:50:33
|
On Thu, Oct 8, 2009 at 12:34 AM, Raymond Toy <ray...@st...> wrote: > Doesn't sbcl support printing specialized arrays readably? The printing the *random-state* should produce a nice object that can be read back in. Yes, but there were some fairly nasty complications which meant it wasn't this simple. I can't remember them but the solution I have was hacked together with the help of #lisp, I'm sure if there was a really trivial way someone would have pointed it out. > Also, doesn't sbcl use /dev/urandom to initialize the state? If you only use a 32-bit integer for the state, your rng is not so random anymore. I don't know what affect that might have. This doesn't affect me in terms of what I would use this facility for.. but I'm intrigued to know, as it appears there are several hundred 32 bit integers in the dumped random state I have saved. Malcolm |
From: Nikodemus S. <nik...@ra...> - 2009-10-08 13:02:35
|
2009/10/8 Malcolm Reynolds <mal...@gm...>: > Thanks for adding this, my previous solution was a horrendous hack > which involved dumping a random state and saving it in a huge file, > using some reader macros I still don't really understand. It'll be > great to have a simple method for adding determinism to code that uses > #'random. While waiting for this, you can use (sb-kernel::%make-random-state :state (sb-kernel::init-random-state 123)) which is obviously elbow-deep in internals, but does work today. (123 being any non-zero unsigned-byte 32 integer you want to use as a seed.) Attached is a patch that implements the extension under discussion. Cheers, -- Nikodemus |
From: Christophe R. <cs...@ca...> - 2009-10-08 13:28:15
|
Nikodemus Siivola <nik...@ra...> writes: > While waiting for this, you can use > > (sb-kernel::%make-random-state :state (sb-kernel::init-random-state 123)) > > which is obviously elbow-deep in internals, but does work today. (123 > being any non-zero unsigned-byte 32 integer you want to use as a > seed.) > > Attached is a patch that implements the extension under discussion. I agree with Ray: a 32-bit initializer is not good. I don't understand why Malcolm couldn't save and load a known random state to and from a file, but if we're going to expose something like this let's at least expose something that allows users to use the full space of the PRNG. (I'd also suggest changing %make-random-state, and the initial random state initialization, to use more than 32 bits, as has been discussed before) As an aside: when documenting an extension like this, consider the potential consequences of changing the RNG implementation, or making it user-extensible... Cheers, Christophe |
From: Malcolm R. <mal...@gm...> - 2009-10-08 13:39:09
|
> I agree with Ray: a 32-bit initializer is not good. I don't understand > why Malcolm couldn't save and load a known random state to and from a > file, I did, my problem was that the easiest way to get this to work (the cause of this maybe that I wanted to also define a macro DO-DETERMINISTICALLY) was using the reader macros #S and #. - at the time I had no knowledge of these and it seemed a pretty complex operation for something that was easy in other programming languages. I also had to put the saved array in a different file which was loaded before the file where it was used, due to some read/compile/load time shenanigans. But anyway I have probably derailed this discussion enough with my lack of lisp skills and knowledge.. I am glad this feature is on the way! Malcolm |
From: Faré <fa...@gm...> - 2009-10-08 14:17:34
|
Dear Malcolm, I'm also interested in some macro to do things deterministically. Currently, I'm using (let* ((hash (sxhash goal)) (*gensym-counter* (* hash 10000)) #+sbcl (sb-impl::*gentemp-counter* (* hash 10000)) (*random-state* #+sbcl (sb-kernel::%make-random-state :state (sb-kernel::init-random-state (logand (1- (ash 1 32)) hash))) #-sbcl (make-random-state *initial-random-state*))) (funcall thunk))) What else do you use? [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] You worry too much about your job. Stop it. You're not paid enough to worry. 2009/10/8 Malcolm Reynolds <mal...@gm...>: >> I agree with Ray: a 32-bit initializer is not good. I don't understand >> why Malcolm couldn't save and load a known random state to and from a >> file, > > I did, my problem was that the easiest way to get this to work (the > cause of this maybe that I wanted to also define a macro > DO-DETERMINISTICALLY) was using the reader macros #S and #. - at the > time I had no knowledge of these and it seemed a pretty complex > operation for something that was easy in other programming languages. > I also had to put the saved array in a different file which was loaded > before the file where it was used, due to some read/compile/load time > shenanigans. But anyway I have probably derailed this discussion > enough with my lack of lisp skills and knowledge.. I am glad this > feature is on the way! > > Malcolm > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > > |
From: Malcolm R. <mal...@gm...> - 2009-10-08 14:24:13
|
On Thu, Oct 8, 2009 at 3:17 PM, Faré <fa...@gm...> wrote: > Dear Malcolm, > > I'm also interested in some macro to do things deterministically. ... snip > What else do you use? Mine is nowhere near as sophisticated as yours, but I wasn't bothered about keeping gensyms or anything like that the same between runs. I just wanted my numerical answers to be the same, even when I was generating entirely random graphs and then doing various calculations on them. I pasted my version, for what it's worth: http://paste.lisp.org/display/88376 http://paste.lisp.org/display/88377 Malcolm |
From: Faré <fa...@gm...> - 2009-10-08 14:29:43
|
2009/10/8 Malcolm Reynolds <mal...@gm...>: > On Thu, Oct 8, 2009 at 3:17 PM, Faré <fa...@gm...> wrote: > I just wanted my numerical answers to be the same, even when I was > generating entirely random graphs and then doing various calculations > on them. I pasted my version, for what it's worth: > > http://paste.lisp.org/display/88376 > http://paste.lisp.org/display/88377 > Note that if you don't need to vary the seed deterministically depending on some context, you can just portably use (defvar *initial-random-state* (make-random-state nil)) at the beginning of your file, then (let ((*random-state* *initial-random-state*)) ...) later. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Any sufficiently advanced bug is indistinguishable from a feature. -- Rich Kulawiec |
From: Malcolm R. <mal...@gm...> - 2009-10-08 14:40:45
|
> Note that if you don't need to vary the seed deterministically > depending on some context, you can just portably use > (defvar *initial-random-state* (make-random-state nil)) > at the beginning of your file, then > (let ((*random-state* *initial-random-state*)) ...) > later. As far as I can see this wouldn't result in deterministic execution across different Lisp sessions... I wanted it so that if a unit test which used random numbers failed, it would fail in exactly the same way if I ran the tests again straight away, or if I ran the tests again after rebooting. I take your point that it was portable, but this was code that didn't need to be portable (university Msc project). Malcolm |
From: Tobias C. R. <tc...@fr...> - 2009-10-13 09:04:34
|
Nikodemus Siivola <nik...@ra...> writes: > 2009/10/8 Malcolm Reynolds <mal...@gm...>: > >> Thanks for adding this, my previous solution was a horrendous hack >> which involved dumping a random state and saving it in a huge file, >> using some reader macros I still don't really understand. It'll be >> great to have a simple method for adding determinism to code that uses >> #'random. > > While waiting for this, you can use > > (sb-kernel::%make-random-state :state (sb-kernel::init-random-state 123)) > > which is obviously elbow-deep in internals, but does work today. (123 > being any non-zero unsigned-byte 32 integer you want to use as a > seed.) > > Attached is a patch that implements the extension under discussion. Could the print representation of random-states also be based on this instead of printing the whole state vector? I think it makes sense for randomizing testing suites to print out the seed so failures can be reproduced later on. At the moment, however, a random-state object in SBCL prints to about 300 lines. -T. |
From: Nikodemus S. <nik...@ra...> - 2009-10-13 11:17:22
|
2009/10/13 Tobias C. Rittweiler <tc...@fr...>: >> Attached is a patch that implements the extension under discussion. > > Could the print representation of random-states also be based on this > instead of printing the whole state vector? I a word, no. A seed can be used to initialize the state vector, but the reverse is not true in general. > At the moment, however, a random-state object in SBCL prints to about > 300 lines. We could just print unreadably unless *print-readably* is requested. #<RANDOM-STATE {...}> Cheers, -- Nikodemus |
From: Christophe R. <cs...@ca...> - 2009-10-13 11:30:17
|
"Tobias C. Rittweiler" <tc...@fr...> writes: > Nikodemus Siivola <nik...@ra...> writes: > >> 2009/10/8 Malcolm Reynolds <mal...@gm...>: >> >>> Thanks for adding this, my previous solution was a horrendous hack >>> which involved dumping a random state and saving it in a huge file, >>> using some reader macros I still don't really understand. It'll be >>> great to have a simple method for adding determinism to code that uses >>> #'random. >> >> While waiting for this, you can use >> >> (sb-kernel::%make-random-state :state (sb-kernel::init-random-state 123)) >> >> which is obviously elbow-deep in internals, but does work today. (123 >> being any non-zero unsigned-byte 32 integer you want to use as a >> seed.) >> >> Attached is a patch that implements the extension under discussion. > > Could the print representation of random-states also be based on this > instead of printing the whole state vector? No. (There are 2^19937 or so possible states, and only 2^32 possible 32-bit integers). Best, Christophe |