Thread: RE: [OpenSTA-devel] Re: When is Random not random?
Brought to you by:
dansut
Menu
▾
▴
opensta-devel
|
From: Wickersham, P. <Pet...@di...> - 2006-01-06 22:00:39
|
The issue as I see it is the following. Let's say we have defined two SCRIPT variables as REPEATABLE RANDOM. A and B with 2 different seeds A1 and B1 Now, lets say that if you called srand(A1), you would see the following sequence of numbers from rand(). a2, a3, a4, a5, a6.=20 Now, let's say that you called srand(B1) and would normally see the following sequence of numbers on successive calls to rand(): b2, b3, b4, b5 First off, srand() will reset the seed for all calls to rand() for all threads in the process. So, a sequence like below would occur <initialize A with seed> GENERATE A =3D> a2 <initialize B with seed> GENERATE B =3D> b2 GENERATE A =3D> b3 GENERATE B =3D> b4 OR <initialize A with seed> GENERATE A =3D> a2 GENERATE A =3D> a3 <initialize B with seed> GENERATE B =3D> b2 GENERATE B =3D> b3 GENERATE A =3D> b4 You can see how the actual sequences for A and B could often not repeat just depending on when one or the other was called. I would imagine that you would want to always be able to count the sequence of values generated for A and for B to be the same across multiple runs. I would like to always see A =3D> a2, a3, a4, a5 and B = =3D> b2, b3, b4, b5=20 Now, some *nix systems have a rand_r() which is meant to allow a process to have multiple sequences seeded at different starting points. But, I don't see this in Windows. -peter PS. Looking at the current code, I am guessing that they had this constant calling of srand() in order to deal with this issue. However, the result of rand() is not usually the next seed in the sequence within the actual system call. So, this workaround doesn't work very well. -----Original Message----- From: ope...@li... [mailto:ope...@li...] On Behalf Of Mark Elam Sent: Friday, January 06, 2006 1:14 PM To: ope...@li... Subject: Re: [OpenSTA-devel] Re: When is Random not random? Wickersham, Peter wrote: >=20 > In fact, there already is an issue with this code for REPEATABLE RANDOM > and that is the fact that we are using rand() in the first place. This > is a global function and the seed is a global, as well. So, if you want > more than one REPEATABLE RANDOM sequence, this won't work. I see what you mean, but if the two lines srand (_cur_seed); _cur_seed =3D rand(); were an atomic operation, wouldn't that take care of the problem as far=20 as repeatable random is concerned? Then the #define VOREPRAND could be checked for in _options as to=20 whether repeatable or otherwise (no srand() call) should be used. Or have I missed something obvious? Mark ------------------------------------------------------- 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 |
|
From: Wickersham, P. <Pet...@di...> - 2006-01-10 22:10:16
|
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
|
|
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 <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
|
|
From: Daniel S. <da...@Op...> - 2006-01-16 02:12:50
|
Peter Wickersham wrote: > 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). That's great! Can't wait to give it a go ... > 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. Nice, I can't believe this one has never been reported before. I've verified and reported this, it's now bug# 1406872: http://sourceforge.net/tracker/index.php?func=detail&aid=1406872&group_id=10857&atid=110857 I'm sure you've also seen I've also logged the fact that RANDOMs are not uniformly distributed. This is bug# 1406888: http://sourceforge.net/tracker/index.php?func=detail&aid=1406888&group_id=10857&atid=110857 I'm not going to log the fact there is a small possibility of repeatable breaking because of threading and the non-atomicity of srand(),rand() in the current implementation. I didn't log because reproducing wouldn't ever be easy and I'm sure that whatever code replaces this will bear this possibility in mind, and avoid it ... ;-) > Does anyone know the SCL parsing/compilation pieces enough to help > me track down where the SEED seems to get lost. I just tried out Mark's 1 line fix and tested out the results - seems to totally fix the problem, which makes sense ... looks like it was just an oversight somewhere down the line, the runtime looks for "seed" in the TOF and the SCL compiler creates this qualifier as an "ivalue". Once I've got my build environments straight, re: STLport, PSDK, etc. then I'll commit this into the CVS HEAD. Hoping this will be tomorrow... Cheers /dan -- Daniel Sutcliffe <Da...@Op...> OpenSTA part-time caretaker - http://OpenSTA.org/ |
|
From: Wickersham, P. <Pet...@di...> - 2006-01-12 23:39:35
|
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
|
|
From: Mark E. <ma...@bo...> - 2006-01-13 17:56:39
|
Wickersham, Peter wrote:
> 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.
>
> Does anyone know the SCL parsing/compilation pieces enough to help me
> track down where the SEED seems to get lost.
>
try the file varlist.cxx
CECVar * Cvarlist::define_variable(const string& scriptname, const
TRecord * rec, const string& dir, bool use_decl)
...
has the lines
// Extract seed for random values
long seed;
par = rec->param("seed");
if(par == NULL)
seed = 0;
else
seed = par->intVal();
to extract the seed from the TOF
however SCL seem to be generating an ivalue object not "seed"
GenericObjects.odl seem to be expecting an ivalue so the above code
should probably change the literal "seed" to the constant
TParam::stIvalue.
If that still doesn't work I can look a bit further.
Mark
|
|
From: Mark E. <ma...@bo...> - 2006-01-06 22:27:50
|
Wickersham, Peter wrote: > The issue as I see it is the following. Let's say we have defined two > SCRIPT variables as REPEATABLE RANDOM. A and B with 2 different seeds A1 > and B1 > > Now, lets say that if you called srand(A1), you would see the following > sequence of numbers from rand(). a2, a3, a4, a5, a6. <snip> > <initialize A with seed> > GENERATE A => a2 > GENERATE A => a3 > <initialize B with seed> > GENERATE B => b2 > GENERATE B => b3 > GENERATE A => b4 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. Or should it? I haven't written anything like this for a few years now so I could be way off the mark:-) On an earlier note, I can't see anything really wrong with having a class like you suggested earlier I'm just wondering what I've missed here. Mark |
|
From: Daniel S. <da...@Op...> - 2006-01-09 02:44:59
|
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 = 1, 1000
GENERATE RandInt
SET Occurrence[RandInt] = Occurrence[RandInt] + 1
ENDDO
DO Idx = 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
--
Daniel Sutcliffe <Da...@Op...>
OpenSTA part-time caretaker - http://OpenSTA.org/
|
Thanks for helping keep SourceForge clean.
X