Use a more random Random Number algorithm in LabVIEW

[mlok]

I recently found out that LabVIEW uses the Wichmann-Hill (1984) random number generator.

http://digital.ni.com/public.nsf/allkb/9D0878A2A596A3DE86256C29007A6B4A

...which in some fields is completely unacceptable for not being random enough (cycle length of 6.9536e12?)

A much better (and arguably a much more currently standard one) would be Mersenne Twister (cycle length of 2e19937−1).

http://www.mathworks.com/help/matlab/ref/randstream.list.html

[GregSands]

>>Yes, some legacy code might even depend on a specific seed vaue.

> I should hope not... ...

It could be fairly common to depend on a seed value, such as for a unit test for a routine that used the random number generator, but wanted a repeatable set of input values (yes you could store them as an array, but if you can specify the seed there's no reason to).  Plus it safeguards against NI changing the Random algorithm without telling anyone...

I like the idea of multiple Random options - not Random and Randomer 🙂 but the names of the algorithms.  Assume that the users who want to select the option are doing so because they know and understand (or can look up) what they are using.

This would also make sense to add to Uniform White Noise and its variants (see the link already mentioned), but also to Uniform White Noise PtByPt, which appears to have the Wichmann-Hill algorithm coded in G for some unknown reason.

[AristosQueue (NI)]

> the Wichmann-Hill algorithm coded in G for some unknown reason.

I am just guessing but it would make sense if they needed to maintain state for a particular caller in order to have a reproducible random sequence for a given point-by-point operation.

[Darin.K]

Let me help with "unknown" reason.  Nowhere in the LV help is the algorithm behind the Uniform White Noise described.  In fact, the only so-called hint is the claimed cycle length which is off my many, many orders of magnitude.  From the underlying CLFN I was able to infer the algorithm, and the undocumented "enhancements" that NI made.  Instead of making baseless claims, I posted the full code so you can compare for yourself and decide if I figured it out.  Then you can decide if what NI does makes sense.

[altenbach]

LabVIEW is much older than the Mersenne Twister (1997) and back in the days, Wichman-Hill was modern.

Times have changed, and according to Wikipedia,  MT is  now a widely adapted default for many environments (C++, Python, Maple, MATLAB, etc.). If they can handle the state size, LabVIEW should not stay behind and it should become the new default.

I do like the option of selecting a slimmer version if speed is needed. Note that there is also SFMT, which is optimized for SSE2 hardware (see quoted article).

[Rob_Calhoun]

I'm voting this up. LabView definitely needs a new random number generator. For backwards compatibility reasons I think it is fine to leave the existing function alone. (Just deprecate it and introduce a new one; it's not hard for us to search and replace the old one.)

The seed behavior of the existing "Random Number (0-1)" function is pretty lousy and can lead to difficult-to-find bugs. Having gotten burned by such a bug I am whole-heartedly in favor of introducing something better!

Here is an example of how the existing behavior generates "unexpected" results. The code below writes a random string into a file:

Or at least you might think it writes a random string. But it doesn't...not if you launch more than one instance of it at the same time!

We run multiple instances of our application, use the allowmultipleinstances=TRUE setting of the LabView ini file. This works great. However, after a system reboot all of the instances launch at the same time. "Random Number (0-1)" uses a seed that appears to be the application launch time (or similar), which can result in multiple instances having the same seed. When this happens, all more than one instance can get the same sequence of "random" numbers!

Here is the output of building the above VI into an application, setting allowmultipleinstances=TRUE, and launching it 20 times as fast as possible in a for loop. I've highlighted random strings that occur more than once. Nine collisions out of 20 launches!

3/4/2015 9:23:18 AM JRMBPKHOFSJC
3/4/2015 9:23:18 AM JRMBPKHOFSJC
3/4/2015 9:23:19 AM HFSUYYUBUUTI
3/4/2015 9:23:19 AM SGKZXYBSLITM
3/4/2015 9:23:19 AM GNBSABVNZBMN
3/4/2015 9:23:20 AM SGKZXYBSLITM
3/4/2015 9:23:20 AM WFDBKYZVTHCN
3/4/2015 9:23:20 AM SGKZXYBSLITM
3/4/2015 9:23:20 AM SGKZXYBSLITM
3/4/2015 9:23:20 AM MSVXJEGDWLVA
3/4/2015 9:23:20 AM JRMBPKHOFSJC
3/4/2015 9:23:20 AM YQQVSQIAEYHV
3/4/2015 9:23:20 AM PYYTZBHZWYHL
3/4/2015 9:23:20 AM CQJFSRCVHNYM
3/4/2015 9:23:20 AM SGKZXYBSLITM
3/4/2015 9:23:20 AM RNSQLZHMVYDC
3/4/2015 9:23:20 AM HFSUYYUBUUTI
3/4/2015 9:23:20 AM BKGAJTMQQATI
3/4/2015 9:23:20 AM UDMCENKMPTHS
3/4/2015 9:23:20 AM CTPOIIYHHVBG

My bug was to assume my temp file paths were unique, when actually they were not, so my instances would occassionally stomp on each other during startup. (Of course I was deleting my temp files after I used them, thus removing the evidence...)

What we do now is read environment variables and use those to uniquify temporary file names etc. (We pass per-instance config data as environment variables: we have a service runner called FireDaemon that sets these, and each instance gets its own values.)  We also hash the "instance name" environment variable into a big number and burn through that number of "Random Number (0-1)"'s, but that doesn't prevent the RNG from emitting the same sequence, it just gives us some phase offset.

The lack of "seedability" is one reason why there should be a new random number generator function. It should be "more random" even at the expense of greater computational complexity (computers are a lot faster now), and it should allow itself to be seeded by the user. Then one could pull a seed from random.org if the default seed is deemed insufficiently random.

Rob Calhoun

[SamShearman]

A seeded random number generator is very useful for communications applications.