id,summary,reporter,owner,description,type,status,priority,milestone,component,version,resolution,keywords,cc
152,get and set state of RNG,Peter,Jari Häkkinen,"""It is often useful to be able to save and restore the state."" - GSL docs
http://cbbp.thep.lu.se/~jari/documents/gsl-ref.html/Copying-random-number-generator-state.html#Copying%20random%20number%20generator%20state
I would like to rewind the RNG so I could get the same permutations again. Why? Well, my use case is (a bit simplified) as follows: I'm doing a permutation test scoring each feature in a dataset. I calculate what the average score S_100 is of the 100th ranked feature, then I wanna know how many scores that were larger than S100. That is obviously impossible to do until you know S_100, and I cannot keep all the scores in memory becasue number of permutations and number features are typically large numbers. Therefore, I would like to go through the permutations in 2 rounds. In the first round I'm calculating S_100 and in the second round I'm calculating how often a score is larger than S_100. As now I have to run he two runs over different permutations, which is not optimal.
Suggestion: It's not obvious to me how one should be able to set and get state in RNG as RNG is a singleton. However, it is supported in GSL through functions ""int gsl_rng_memcpy(gsl_rng * dest, const gsl_rng * src)"" and ""gsl_rng* gsl_rng_clone(const gsl_rng* r)"", respectively. Using the gsl_rng* right ahead seems sub-optimal, as gsl_rng_clone appears to allocate memory that the user then is responsible for. I guess a better solution would be to wrap it into a ""RNG_state"" class taking care of the memory issues. The only functionality would be in RNG where it could be passed in a function to set the state, and obviously in that function is gsl_rng_memcpy called. Likewise, the RNG_state is constructed from a RNG where the gsl_rng_clone is called.
Any problems? Any principles violated?
",enhancement,closed,minor,yat 0.3 (Public release),random,trunk,fixed,,