Generation of random values

[Darin.K]

---

@altenbach wrote:

Yes, I reproduces this too, now that I sit at the computer. 😄 However, "initialize?" is also TRUE in all older versions I tested (2012, 2013sp1). (I think it should be false). EDIT: actually, if initialize=true, and seed=-1 (the default!) it will pick a random seed with each call, so this looks OK.

I agree that setting initialize=false in the gaussian random signal generation fixes the problem.

I did not test this, because it had no effect in the original VI. If you set initialize to FALSE in the original code using the chis-quared instance of "Continuous Random VI", the problem persists. Somehow something gets reset internally anyway, but I cannot tell where...

---

Initialize does equal true in the older versions of that VI.  As I mentioned, the previous versions of Continuous Random used an obsolete version of that VI and not the new one (which added the reset/initialize function).  The bug showed up in LV14 when the obsolete version was finally replaced.

I am sure that there is some irony (in the Alanis Morisette sense) to getting a solution for saying I was wrong when I was right....

[altenbach]

---

@Darin.K wrote:
Not sure which problem you say persists.  Besides, diffing LV13 and LV14 versions point directly at this being the culprit as well.

---

Yes, I was comparing the "gaussian whilte noise" (from the signal generation palette) and they agree between recent versions. Yes, the difference is that prior to 2014, the "Continuous random (chi squared instance)" internally used the obsolete version of "Gaussian white noise", which does not even have a reset terminal.

So the new version generates a new seed with every call (since seed=-1). I don't understand why that would cause the difference we see. Strange....

[Darin.K]

The seed is random, but the state of the PRNG is being reset to the same value repeatedly which gives the subtle effects we see.

[altenbach]

The problem is that the seed is only in the range of 0..16383 (x3FFF), so it is highly restricted for an I32 (only 14 bits used!). If I change the multiplier to a higher number, the function start smoothing out even with reset=true! Not sure what the value should be, depends on the internals.

I guess NI needs to explain why the random seed is restricted to such a small range. 😄

(This must be a leftover from ancient times and somebody failed to adjust the range when seed became I32!)

[altenbach]

If Gaussian White Noise is e.g. adjusted as follows, The problem is clearly much smaller..

 

(Of course I don't know how many bits of the seed are actually used, but it is clearly more than 14)

[Darin.K]

That is interesting.  It does not solve the problem, but it does make it much more subtle and probably effectively solves it for most uses.  Would not trust it father than it could throw me for cryptographic or n-body simulations.  Of course, had it been this subtle to begin with, we probably would never have noticed.  Even if it uses all available bits, it still sets an artificial limit on the period.

I did a quick test.  With a single point I can determine the seed value with a small lookup table assuming the std dev is left at the default value.  With just a couple hundred points I can infer the std dev, assume it is set to a normal multiple (0.2 or 0.5 say) and infer the seed again and then move in lock-step.

[altenbach]

According to the help, the seed is I32, but must be positive, so a mulitplier of 7FFFFFFF would probably be OK.

But yes, I also agree that "initialize?" should probably default to false. I don't understant why the default is true, since it gets initialzed on first run anyway.

What is the algorithm? (how are seed x,y,z (all I32) and gauss state (I32, DBL)  used?)

[Darin.K]

---

altenbach wrote:

What is the algorithm? (how are seed x,y,z (all I32) and gauss state (I32, DBL)  used?)

---

With the complete lack of an official response as well as references for the code hidden behind the CLFN I had to resort to a bit of detective work this morning.  My initial guesses were correct:  based on the 3 integer seeds and their respective periodicities I assumed a Wichman Hill random number generator was used for the uniform white noise.  Based on the stored value in the Gaussian White noise case I assumed the Box Muller transform was used since it finds two value at a time.  Simple mapping of the seed value to the inital state for the PNRG was all that was left (I probably could find a tidy math expression, but I don't care so I left the case structures I used to tweak things).

Attached LLB contains drop-in replacements for the Uniform White Noise and Gaussian White Noise VIs.  You can verify that you get the same results with the same seeds (or at least the same to 13-16 digits since I am not going to start fussing with the ordering of the math operations to get an exact match).  Now without the CLFNs you can see exactly what is going on.

Extending the random value beyond 16283 is going to cause trouble in certain cases.  There is a fixed point in the mapping functions between the seed and the initial state combined with a poor choice (seed = 0 should not indicate keep the current state, but rather be a fixed seed.  seed <0 should be used for keeping the current state).  Choosing a seed=16284 results in two of the seed values being "frozen" at zero leading to a repeating pattern of ~30000 values with only 15 random bits.

A far better choice for the seed is to create an initial state which spans all three state values (x,y,z) instead of the current method of mapping a single seed to all three.  The current mapping is also what limits the seed to 16383 or less, the WH algorithm can handle values from 1-30000 for all three state values.

The WH method is pretty decent, fairly solid in fact, passes many of the important tests, but has a much shorter period than many more modern methods (few people care, and those few absolutely do not use an undocumented function in the first place).  And at least they got the implementation correct, Excel has flubbed it on two separate occasions.  The default value of true for the the initialize input and the ineffective choice of mapping a seed value to an initial state are some serious drawbacks.