RE: [OpenSTA-devel] Re: When is Random not random?

[Wickersham, P. <Pet...@di...>]

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 <Da...@Op...>
  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