[Push] RANDOM-SEED parameter

[Lee Spector]

Wow that's a lot of RNG initialization time.

I see that there are some interesting issues here, potentially from the distributions etc. you'd get from re-seeding and/or use of seeded RNGs as funky ways to store or refer to sequences. But for what it's worth my practice has historically been just to seed once at startup (as illustrated by the fact that my method for re-seeding didn't work :-). 

In the Clojush/concurrent context I've been actually been using as many RNGs as there are individuals in the population, as a quick hack to ensure that there's never contention for the same RNG from different threads. But I initialize each of these only once, at the start of a run.

 -Lee


On Jun 30, 2010, at 12:20 PM, PerPlex Ed wrote:

> This question was actually related to the question about performance.
> 
> Currently when I evaluate the fitness of the population, I pick a random seed for each interpreter.
> 
> I discovered that I spend almost half of the time to initialize (=seed) the random number generators.
> 
> I'm using a Mersenne Twister which is "high quality" and fast to use but it's very slow to initialize. The standard random generator available on my platform is probably good enough for genetic programming. I could use that instead of the MT but it would improve things, it takes 4 times less initialize. But for code size of 80-130 points initializing the random number generators (to generate only few numbers, in fact) will be a big part of executing the program on a fresh interpreter.
> 
> If I just want every run to have a different sequence of numbers, I could just use 1 random number generator for all interpreters (actually one random generator for each core used). Interpreters running on the same core will use the generator sequentially.
> Unless you want to reproduce exacly an old run you basically always just need different random numbers to drive ephemeral and code generation, that looks ok to me. Please correct me if I'm wrong.
> 
> This works UNLESS you you allow Push code to re-seed the generator at runtime and use the random generator as a data storage.
> 
> Now I'm sure it would be cool to publish a paper where you describe that you evolved some program that does amazing things using that specific random generator as a vacuum-based data storage but is it worth?
> 
> PerPlexEd
> 
> 
> ----------------------------
> 
> Lee said:
> 
> This has always been murky and should indeed be fixed/clarified in some way in various places.
> 
> You are basically right about the behavior of the Common Lisp version -- it only actually seeds the random number generator when setting up (or configuring) an interpreter. There's an ENV instruction but that just sets the value of a global variable *RANDOM-SEED* without actually using it to seed the RNG. That's a bug, which I don't think ever bit me because I don't think I ever tried to set the seed this way. I think the right behavior would be to re-seed immediately when executing the ENV instruction.
> 
> FWIW not only has RNG seeding been poorly standardized/documented (and doing it *really* right might get complex, since different platforms have different default RNGs, etc.) but also in general ENV instructions are another point of wide divergence among implementations. For example I haven't implemented any of them in Clojush and didn't even think to mention this in the docs! :-(. To me this underlines the need for an overhaul of the docs from the ground up, in a way that somehow sensibly deals with the inevitable differences between implementations... a project that Tom Helmuth is beginning to scope out.
> 
> I've made a note to fix this particular bug in push3.lisp.
> 
> -Lee
> 
> 
> On Jun 29, 2010, at 1:08 PM, PerPlex Ed wrote:
> 
>> Is the random seed updated only when the interpreter is setup?
>> 
>> As far as I understand this is what the lisp Push interpreter does.
>> 
>> When I first wrote my implementation, I followed only the specification. When describing the initialization files, it lists all possible parameters including RANDOM-SEED.
>> 
>> Then it says that that an alternative method of setting those parameters is running initialization code, specifically the ENV instructions.
>> 
>> To me that means that there is an Env.RandomSeed instruction.
>> On the other hand (random::seed-state *RANDOM-SEED* *RANDOM-SEED*) is called only in "configure-push-from-file" and "complete-push-pre-configuration". In any case, even if you implemented an Env.RandomSeed instruction it seems that it won't have any effect at runtime.
>> 
>> Could you clarify this?
>> 
>> Details like this one can make a significant difference when implementing Push from scratch. Thanks.
>> 
>> PerPlexEd.
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Push mailing list
>> Push at lists.hampshire.edu
>> https://lists.hampshire.edu/mailman/listinfo/push
> 
> --
> Lee Spector, Professor of Computer Science
> School of Cognitive Science, Hampshire College
> 893 West Street, Amherst, MA 01002-3359
> lspector at hampshire.edu, http://hampshire.edu/lspector/
> Phone: 413-559-5352, Fax: 413-559-5438
> 
> Check out Genetic Programming and Evolvable Machines:
> http://www.springer.com/10710 - http://gpemjournal.blogspot.com/
> 
> 
> 
> 
> _______________________________________________
> Push mailing list
> Push at lists.hampshire.edu
> https://lists.hampshire.edu/mailman/listinfo/push

--
Lee Spector, Professor of Computer Science
School of Cognitive Science, Hampshire College
893 West Street, Amherst, MA 01002-3359
lspector at hampshire.edu, http://hampshire.edu/lspector/
Phone: 413-559-5352, Fax: 413-559-5438

Check out Genetic Programming and Evolvable Machines:
http://www.springer.com/10710 - http://gpemjournal.blogspot.com/