Enhance Random Number (0-1) Function with Random Seed

[Sergey_Kolbunov]

Random Number (0-1) Function from Numeric palette is widely used, but it misses such important feature as Seed to initialize a pseudorandom number generator.

Seed is present in TestStand's Random() function for instance and described there as: "An optional number the function uses to determine where in the virtual sequence of random numbers the function obtains its random numbers. When you seed the Random function with the same value, subsequent calls to Random return the same sequence of numbers. If you pass a seed value of 0.0, the function generates a seed value based on the current time. If you do not pass a seed value, the function returns the next number in the current sequence of random numbers."

[GregSands]

You can use the Uniform White Noise PtByPt VI in the Signal Processing/Point By Point/Signal Generation palette to generate single random numbers (scaled [-1:1] though), or Uniform White Noise in the Signal Generation palette to give an array of numbers, or Continuous Random in the Probability VIs palette with a Uniform distribution.

[Mark_Yedinak]

Greg, Your solution indeed works. The only issue that I see with this is that is it not obviously to anyone who is not familar with the signal library. A programmer is unaware of this capability when simply looking at the Random Number VI. If nothing else, NI should update the Help page for the Random Number VI to document this alternative in order to get a repeatable random number sequence.

[Brian_Powell]

The usual reason someone wants a seed is so that they can have the random number generator produce the same pseudo-random sequence each time.  Is that your use case, or do you have a different reason?

Let's think, for a moment, about what it means to have a seeded random number generator in a parallel dataflow programming language.

Would you want to be able to "tie" two different random() primitive icons together, so that they were part of the same sequence?  Or would you always want them to be independent?  I.e., is the seed a global for the entire development environment, or is it private to a VI, or is it private to each specific random() icon on the diagram?

I'd argue you don't want it to be global for the entire environment, because you can't control whether some other VI runs and happens to have a random() function which takes your next random number.  Private to a VI is a little strange, because what if there is no dataflow dependency between two random() icons, and they don't always execute in the same order?  Private to each primitive is somewhat limiting, but probably has the most predictable semantics.

I suppose you could propose the idea of a reference to a random number generator, and wire that reference to your random() icons to indicate which seeded sequence you want to be using.  That's probably the most powerful solution.  It's not as easy to use as our current icon, but maybe it could default to being that easy.

When I was in graduate school working in probability and statistics, we usually just created the random numbers once, and saved the sequence to use over and over.  I.e., we didn't put the generation "in line"; it was part of our initialization sequence.  (Keep in mind that we were also thinking up front about how big the sequence needed to be, so we could precompute enough random values.)  This is pretty much what GregS suggested by using the Uniform White Noise VI.  (Note that the PtByPt version maintains state per instance.)

Personally, I would propose one of two solutions...

1) Make one of the existing Uniform White Noise VIs as easy to use and prominent as the current generator.

2) Add an Initialize ("Seed") and a reference wire for the random number generators.

Thoughts?

[Mark_Yedinak]

Yes, the use case is to be able to regenerate the same random sequence. For instance, in quite a bit of our testing we choose a random value for a test parameter. This helps to increase the total coverage for testing over multiple test iterations since we are varying the test data. Now if a failure occurs you would like to have the ability to run the exact same test to help in the debugging phase. So you need to seed the random number generator to get the same values out. I would envision using a random seed (let's say the current time) initially and the seed value would be saved with the test results.

I agree that this seed should apply to a single "instance" of a random number generator so you don't get side effects from other code using a random number.

[Sergey_Kolbunov]

Mark has described our usecase quite well. "Private to each primitive" behavior is what I'm looking for.

Create a random numbers once at initialization may work for us, but we usually don't know how many numbers we need. I more incline to "in line" generation.

One more useful feature would be to output the current seed value after generating a set of numbers. Say, we use a random sequence with known initial seed for a long test suite consisted of number of test cases. One test case in the middle is failed. To repeat this test case exactly we need to run all test suite with known initial seed from the beginning again, or run just this test case with known seed for this test case which we can get from the previous test case. Alternatively, a counter of used number from a random sequence can be recorded for each test case.

Sergey 

[GregSands]

I'd agree with updating the Help to point to the other routines, but I think the Random Number primitive is ok as-is.

[EngrStudent]

Reproducibility is important in the sciences.  If LabVIEW is going to have good credibility as a simulation or analysis tool, then it has to have the fundamentals down well. 

Also, this is fun:

Coveyou, Robert R. "Random number generation is too important to be left to chance." Applied Probability and Monte Carlo Methods and modern aspects of dynamics. Studies in applied mathematics 3 (1969): 70-111.