Don Schlesinger: Help: A weird problem

[Don Schlesinger]

Maybe someone can help with this weird problem.

John Auston's Random Walk feature of BJRM 2002 has been revamped. I have downloaded the latest version of it, and we are certain that, indeed, I am running the correct version 4.0.3.

However, when I try to generate "trips," I can get some incredibly weird results, such as 4.02 SD, 3.77 SD, and a host of 2.5 to 3.0 SDs, with only a handful (20-30) of trials. John gets nothing remotely as severe as this on his system.

I have a 4-year-old Compaq Presario 5600. It runs on a Pentium II chip, 350 Mhz, 8.0 GB hard drive with 96 RAM. I understand how "dinosaur"-like this is, but that's not the point.

The question is: can the system somehow not be equipped to handle the randomizing process that John has established? I'm also running Windows 98.

Any help would be appreciated. We're going crazy trying to understand why John's results are all "normal," while mine are consistently bizarre.

Thanks.

Don

[AsZehn]

I can't imagine processor speed having any effect other than processing slower. Is it possibe that you did not load all of the SBA files from earlier versions of BJRM? Is it possible that one of you has more indices loaded or aren't running the same counting method. Just a guess.

[Slowhand]

A few years ago there was a flaw revealed in some of the pentium chips that came out. It was mostly noticed in Excel because so many people used Excel. It would incorrectly calculate a result out to many decimal places and the result would be close but not exact. I am sorry I can't remember the specifics off the top of my head, but you may have one of those chips. Hopefully someone else may be able to post more detail about this old problem.
Good luck.
Slowhand

[Slowhand]

[Norm Wattenberger]

Is your clock working?

[Don Schlesinger]

> Is your clock working?

Yes, perfectly.

Don

[Don Schlesinger]

> I can't imagine processor speed having any
> effect other than processing slower. Is it
> possibe that you did not load all of the SBA
> files from earlier versions of BJRM? Is it
> possible that one of you has more indices
> loaded or aren't running the same counting
> method. Just a guess.

Thanks for trying to help. Actually, this has nothing to do with an actual BJ problem or sim, per se. Rather, it refers to the Random Walk feature and to the RNG that John is using.

One more hint: for fewer numbers of hours in my "trip (10, 20), things seems to be "normal." As I increase the trip hours to 100, things begin to get funky. By the time the trip reaches 500 hours, 3-Sd and even 4-SD events are a dime a dozen!!

On John's system, he gets NONE of the above problems. Our setting, of course, are identical in every respect. We've triple-checked that aspect.

Norm, you mentioned something about 30,000 seeds and "degrading"?? Can this be the problem?

Don

[Norm Wattenberger]

> Norm, you mentioned something about 30,000
> seeds and "degrading"?? Can this
> be the problem?

Linear congruential generators follow very simple formulae. In the case of VB, the formula is:

x=(1140671485x+12820163) MOD 2^24

The problems with LCGs are that they all have a very limited period (VBs will repeat in a couple seconds,) all experience correlation problems in four dimensions and some suffer from dispersion degradation over time. That is, the more calls you make the worse the dispersion. Use of the RNG can also affect its performance. For example, VBs RNG is known to have serious correlation problems in the bits beyond the two first bits of the result. But, the performance should not vary by machine, unless you have a clock problem that seeds the RNG poorly.

Before someone starts jumping on non-randomness of BJ simulators, the RNG used by CVData/CVCX is NOT an LCG and passes the 19 Marsaglia Diehard tests. The period is 10^30. That means that if I had been running a sim on a 1Ghz PC starting at the Big Bang, it would have only used .0001% of the available random numbers

As Knuth once said, ?Random numbers should not be generated with a method chosen at random.?

[John Auston]

> As Knuth once said, ?Random numbers should
> not be generated with a method chosen at
> random.?

:-)

I've heard of a similar quote:

"Random numbers are too important to be left to chance."

Anyway, I guess I'm still in need of some VB code that will return a number between 0 and 1, better than the Rnd() does.

If I continue to use the VB Rnd() function, then I guess I need to decide how often I precede the call with the Randomize statement, which sets the seed from the clock.

I am calling the Rnd() function quite a few times in a VERY short time frame.

For every SD event I need, it gets called 108 times. For a 500 hour trip, 54,000 times.

My choices are to issue the Randomize before every one of the 54,000, or limit it to 500 times (once before the 108 call loop), just once, or not at all.

I guess I'll have to experiment, unless you have any suggestions, Norm.

-John

[Norm Wattenberger]

Randomize should only be called once. Otherwise you're using the clock as a random number generator and it is a terrible rng. Multiple calls to Randomize could cause a problem like the one Don is seeing. That is, one that varies by PC.

[John Auston]

> Randomize should only be called once.
> Otherwise you're using the clock as a random
> number generator and it is a terrible rng.
> Multiple calls to Randomize could cause a
> problem like the one Don is seeing. That is,
> one that varies by PC.

Terrific! Thanks so much, Norm. That explains a lot.

John

[Hal Marcus]

of your problem, try restarting your computer, and then run BJRM again.

Depending on how many times you have started and ended programs since your computer was last restarted, the Windows resources may be discombulated (it's more of an issue with Win 95, but it's still an issue in Win 98) to the extent that you are getting erroneous data.

-Hal

[Magician]

> A few years ago there was a flaw revealed in
> some of the pentium chips that came out. It
> was mostly noticed in Excel because so many
> people used Excel. It would incorrectly
> calculate a result out to many decimal
> places and the result would be close but not
> exact. I am sorry I can't remember the
> specifics off the top of my head, but you
> may have one of those chips. Hopefully
> someone else may be able to post more detail
> about this old problem.
> Good luck.
> Slowhand

The infamous Pentium FDIV bug existed only in some orginal Pentium chips with clock speeds of 60-100MHz. I suspect Norm and John have nailed the problem below.

Intel's FDIV FAQ