RE: [OpenSTA-devel] Re: When is Random not random?
Brought to you by:
dansut
From: Wickersham, P. <Pet...@di...> - 2006-01-12 22:57:22
|
Ok, so now that I can build, I have added a random number generator class based on the Mersenne Twister PRNG. It is fast, uniform, and has a long period (iterations before repeating). However, I have run into issues in actually getting the seed from the script set in the code. I reviewed the current code in CECRangeVar and CECListVar and it looked like those classes were always ignoring the seed and just using a random one to start. So, I decided to test this, but I can't seem to get any SEED I set in the script to actually get passed into the constuctors for these variable classes. They always get 0, which is the default higher in the stack if no seed is specified.=20 Does anyone know the SCL parsing/compilation pieces enough to help me track down where the SEED seems to get lost. -peter -----Original Message----- From: ope...@li... [mailto:ope...@li...] On Behalf Of Wickersham, Peter Sent: Tuesday, January 10, 2006 2:10 PM To: ope...@li... Subject: RE: [OpenSTA-devel] Re: When is Random not random? I agree with Dan, the issue is not the window between srand() and rand() calls, it is that fact the Windows rand() doesn't actually use its' last result as the new seed. So, the call to srand() is messing up the uniformity of the number distribution. Not to mention that rand() is not 32-bit, which is another problem. So, I have been trying to get things built to take a look at a new generator class that is 32-bit, allows for multiple generators and is highly uniform.=20 My issue is that I only have Visual Studio 2003 at the moment. I decided to give this a try, but have found that omniOrb 3.0.4 doesn't compile with VS 2003, so I decided to try omniOrb 4.0.6, which does. Since I am using VS 2003, I don't need the Platform SDK. However, I keep running into little issues along the way. The most recent being a difference between omniOrb 3 and 4 WRT to connections and thread pools. I guess thread pools were a new feature in omniOrb 4. At this point, I'm looking for VS 6 and plan on going back to the basic components for the 1.4.3 source.=20 I'll keep you all posted. -peter -----Original Message----- From: ope...@li... [mailto:ope...@li...] On Behalf Of Daniel Sutcliffe Sent: Sunday, January 08, 2006 6:45 PM To: ope...@li... Subject: [OpenSTA-devel] Re: When is Random not random? Mark Elam wrote: > Yes, but we're calling srand(A1),rand(),srand(a2),rand(),srand(a3) > ... So the 'initialize with seed' is occuring before each call to > rand, which should reset the seed before each call. However if > another thread called srand() before the first thread rand() had > occured I can see the problem you are describing which is why I > wondered whether just making the srand(),rand() pair atomic (with a > mutex) would solve the issue. As rand() would always be called > after a reset with srand() using the same seed this should give the > same sequence. I think you are correct Mark. I've tried to stimulate this potential concurrency and timing issue to occur using some contrived scripts and I can't seem to - that's not to say it won't happen, just that it seems it is unlikely to happen. Maybe it's something to do with how the work is assigned to the threads in a Test Executer, or the potential points of context switch on my single CPU test host. The above doesn't matter though, as the whole method of always reseeding is obviously a really bad way of generating "random" numbers... I created a little script like this: Definitions CHARACTER*512 USER_AGENT INTEGER USE_PAGE_TIMERS INTEGER RandInt(1-10), RANDOM INTEGER Occurrence[10] INTEGER Idx Code Entry[USER_AGENT,USE_PAGE_TIMERS] DO Idx =3D 1, 1000 GENERATE RandInt SET Occurrence[RandInt] =3D Occurrence[RandInt] + 1 ENDDO DO Idx =3D 1, 10 LOG Idx, " occurred ", Occurrence[Idx], " times" ENDDO Running this, very simple, test several times was enough to tell me that there is definitely not an equal probabiliy of getting each of the possible returns of RandInt. I found by, unscientifically, eyeing the results that there was always much more chance of getting a 1, 3, or 8; and much less of a chance of getting 2, 5, or 7... not good! Obviously the behavior of RANDOM variables needs fixing - it looks like there's 3 seperate bugs that can be addressed in one update: - limited range of returns (bug#415144) - less than random distribution of returns (not logged) - small chance of REPEATABLE failing due to timing (not logged) I'm still concerned about keeping the old (bad) behavior of REPEATABLE as default, with a logged warning, that can then have the good behavior, or warning, defeated using the .ini file. My feeling is that it is not worthwhile keeping the behavior of regular RANDOM but other opinions are welcome. I'm starting to put a shortlist together for a 1.4.4 release and it would be great if Peter (or someone) could donate some code to get these problems, at least partially, fixed for this release. Cheers /dan --=20 Daniel Sutcliffe <DanSut@OpenSTA.org> OpenSTA part-time caretaker - http://OpenSTA.org/ ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick _______________________________________________ OpenSTA-devel mailing list Ope...@li... https://lists.sourceforge.net/lists/listinfo/opensta-devel ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dick _______________________________________________ OpenSTA-devel mailing list Ope...@li... https://lists.sourceforge.net/lists/listinfo/opensta-devel |