Bug Report: Random function RANDOM() in TS2016 delivers always the same number (after a long time)

[run321]

Hi,

I used the random function from TestStand (expressionBrowser -> Operators/Functions).

According to the documentation it should generate a new number each time it is called and the time

should be used as seed (random(min,max,0.0)).

Unfortunately the random number becomes always the same after some days!!!

This is critical and the random generator can only be restarted (correct behaviour) by closing TS --- and this can

not be done programmatically.

Is there any other way I can try to reset the random generator.

I used TS 2016 on Windows 10.

Best regards

Matthias S.

[dug9000]

If you call Random(min, max, 0.0) in a tight loop (especially with tracing off), it is expected that you will get repeated values that are the same because there is a finite resolution to the clock, so if you repeat the calls very close together you are effectively giving the same seed to the number generator for calls that are close in time together. In order to get an evenly distributed set of random numbers, you should not be constantly re-seeding the random number generator.

In general, re-seeding a pseudo-random number generator is something that should be done once, or at least rarely, for the lifetime of the use of that generator because it resets the pseudo random sequence. For example, if you had reseeded with the number 5 every time you ask for a random number, you will always get the same number. If you only reseed once and then on subsequent calls, do not reseed, you will get an evenly distributed set of pseudo-random numbers. Even though you will tend to get different numbers when constantly re-seeding with the clock, the clock value is not random and thus the resulting number you get will not be as random either as if you had only re-seeded once. Also the clock has a resolution limit, so if you re-seed very close in time together you will get the same value for multiple calls. I verified this with a tight loop in TestStand with tracing off and got the results as shown in the attached screenshot.

Basically you should be doing:

Random(min, max)

rather than

Random(min, max, 0.0)

The main reason why TestStand allows for the specification of a seed is that sometimes people will want the same sequence of numbers repeated for reproducibility of problems, and in that case specifying a fixed seed at the beginning of the operation and not reseeding for subsequent calls to Random will give the desired results. If you just want a random sequence of numbers and don't care about getting the same sequence each time, you don't really need to seed the generator at all. You can just leave out the seed argument to Random entirely.

Hope this helps,

-Doug

[run321]

Hi Doug,

thanks a lot for your answer. In the future I will never use the re-seeding again, thanks for your hint.

But the time between the calls of the random function was 108 seconds!!! I do not think that the resolution of the time in TestStand is such bad. This strange beviour was only observed jet after a time of about 3 days or longer (duration test),.... so something changed in the random generator after a long time.....

I need to check if I can post the report here....

Best regards

Matthias

[run321]

...and an additional information which I forgot to add:

Everytime this behaviour was observed (two times yet) the result of the Random function does not change any more,... for the next week or even more, so this can not be a side effect of the re-seeding, unless the time itself is "saturated"  :).

Best regards

Matthias

[dug9000]

It's possible that there is a bug related to seeding based on time. The value of the clock might be overflowing the max value for the seed, resulting in effectively getting the same seed each time. I'll create a bug report for this issue. If you have any more details about how to reproduce it, please let us know.

But regardless, it's best not to constantly re-seed the number generator. You will get a much better distribution of pseudo-random values that way and avoid the issues with the clock granularity.

-Doug

[dug9000]

Just want to add, assuming the issue with re-seeding based on the clock is caused by the clock value not effecting the seed (perhaps due to some overflow or truncation issue with the clock value), by not ever re-seeding you should be able to avoid this issue. If you see otherwise though, please let us know.

Hope this helps,

-Doug

[0xJed]

For anybody interested, TestStand was reseeding the Random() function using the standard C clock() function.  Per the documentation, https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/clock?view=vs-2015, once clock() rolls over its 32-bit counter, it always returns -1.  It does not just rollover to zero and keep going.  This means that if a process stays up long enough, TestStand will reseed using -1 any time you pass 0.0 for the seed, explaining the strange change in behavior after long tests.

We are changing the code to use GetTickCount64() instead of clock().  The fix did not make it into TestStand 2019.  It should be included in the next service pack or major release, whichever comes first.  There are a couple of examples that call srand(clock()) as well.  We are changing the example built in Visual Studio to call GetTickCount64().  GetTickCount64() is not available in CVI, so we are change the example built with CVI to seed with time().