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

[Oligarlicky]

What's the computation time difference? I could see right click configure option being useful. The user could select "Faster" or "Randomer"

[mlok]

Hmm that's a good point, I was wondering about that too. Yesterday after I posted this I noticed that Dr. Matsumoto and his student Mutsuo Saito were up to their usual tricks again, and have gone and invented a new algorithm that's twice as fast.

http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.html

What won't they do...

[MDC]

We need to be careful in making this kind of change.  LabVIEW's Random Number primitive maintains internal state so that each generator on the block diagram is independent from all others and can be executed in parallel.  This means that, for example, we would want to steer away from algorithms that maintain a large state (original MT uses 624 integers).

We therefore need an algorithm that initializes quickly, is computationally efficient and deterministic in generating a new sample, uses a modest amount of state memory, and, of course, yields significantly superior random sequences.

[AristosQueue (NI)]

mlok: Any idea how many bytes of state the new SFMT algorithim uses?

[altenbach]

Some of the random number tools in LabVIEW are actually less random than what they could be for the given algorithm. Have a look at this discussion.

[mlok]

AristosQueue: I'm sure that I'm not as familiar with the algorithms behind this as MDC is, but when I downloaded the SFMT code and took a look at the SMFT-params.h code I found this:

#if !defined(SFMT_MEXP)
#if defined(__GNUC__) && !defined(__ICC)
  #warning "SFMT_MEXP is not defined. I assume MEXP is 19937."
#endif
  #define SFMT_MEXP 19937
#endif
/*-----------------
  BASIC DEFINITIONS
  -----------------*/
/** Mersenne Exponent. The period of the sequence
 *  is a multiple of 2^MEXP-1.
 * #define SFMT_MEXP 19937 */
/** SFMT generator has an internal state array of 128-bit integers,
 * and N is its size. */
#define SFMT_N (SFMT_MEXP / 128 + 1)
/** N32 is the size of internal state array when regarded as an array
 * of 32-bit integers.*/
#define SFMT_N32 (SFMT_N * 4)
/** N64 is the size of internal state array when regarded as an array
 * of 64-bit integers.*/
#define SFMT_N64 (SFMT_N * 2)

.. which suggests that it uses 157 128-bit integers, 314 64-bit integers, or 628 32-bit integers to determine the internal state.

Interesting trivia: apparently SFMT is used on the Playstation 3.

If the size of the internal states is an issue, there is also TinyMT, which reduces the internal state size from 19937 bits to 127.

http://www.math.sci.hiroshima-u.ac.jp/~%20m-mat/MT/TINYMT/index.html

This seems to dramatically reduce the cycle length from 2¹⁹⁹³⁷−1 down to 2¹²⁷−1, but compared to the Wichmann-Hill, TinyMT would probably still improve the cycle length significantly (2.45e25 times? if it's ok to divide cycle length like that and get meaningful answers).

[AristosQueue (NI)]

Sounds worth investigating. I'll add considering a change to our random algorithm to the long-term research list. I hate to call it "long-term", but there aren't many within NI who are capable of vetting this sort of fundamental algorithm change, and we move very cautiously when doing such changes -- we don't want to cause some weird break in existing user applications. I can't imagine any apps depending upon a short cycle time, for example, but I have seen some weird dependencies over the years.

[johnsold]

AQ,

Keep the existing generator and add a new one rather than changing things? Put good notes in the documentation.

Like Tick Count and High Resolution Relative Seconds.  Let the user choose the appropriate function.

[altenbach]

> Let the user choose the appropriate function.

Random and Randomer? 😄

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

[mlok]

Thanks AristosQueue, glad to hear it seems worth considering for future implementation.

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

I should hope not... :S...