LabVIEW Randomization

[B_Strange]

I was messing around with the Random Number function today and noticed that it seems to have abnormal distribution showing more "random" numbers generated toward the middle of the minimum and maximum of the range. What I expected to find was a fairly equal number of numbers spread among the four options (0,1,2,3). Instead, it appears that the extremities (0 & 3) appear about half as often as those closer to the middle (1 & 2).

Is this an artifact of the randomizer that I should expect to compensate for or am I doing something wrong?

[Darin.K]

You need to round up or down to an integer.  When rounding to nearest as you do now only 0<=x<=0.5 will round to 0 while 0.5<x<1.5 will round to 1.   That is why you see roughly twice as many counts for 1 versus 0.

[altenbach]

---

@B_Strange wrote:

Is this an artifact of the randomizer that I should expect to compensate for or am I doing something wrong?

---

As Darin said, if you round to the nearest integers, the edge ranges only have half the width (and thus probability) as the inner ranges.

Here is a comparison of the right and wrong (your) way to generate equally distributed random integers in a certain range.

 

 

In terms of programming, your methods to count the ranges is extremely inefficient, conditionally building four different arrays of unknown size, even though you are only interested in the size at the end. A better way is to just increment elements of a fixed size array.

[Norbert_B]

Cleaning up incorrect rounding as altenbachs screenshots show is the first step.

The second is to accept that 1000 iterations maybe represent a trend, but statistically speaking, is an insignificant amount of test iterations. For such small tests, i would recommend to iterate for more than 1M times (at least) in order to get representative data.

Norbert

[RavensFan]

---

@Darin.K wrote:

You need to round up or down to an integer.  When rounding to nearest as you do now only 0<=x<=0.5 will round to 0 while 0.5<x<1.5 will round to 1.   That is why you see roughly twice as many counts for 1 versus 0.

---

The correct rounding function is to round down.  The reason is the range returned is 0 to 0.99999.......  If you were looking for  a value from 0 to 9.  Rounding down gets you that.  If you rounded up, you'd generally get 1 to 10, but there is a very small possibility you could get a 0 which means you could wind up with 11 different numbers from 0 to 10.

If you want a number from 1 to 6 (like if you were rolling a die),  you'd multiply by 6, round down, and then add 1.

[B_Strange]

Thanks for the info guys. All good points. Excuse me while I go check some old code...

[Darin.K]

---

@RavensFan wrote:

---

... but there is a very small possibility you could get a 0 which means you could wind up with 11 different numbers from 0 to 10.

---

It would be fun to quantify what "very small" means in this context, usually I would compare the odds to something like me winning the Lotto (without playing) or involving cosmic rays striking my PC and generating bit errors.  In this case, however, given the method LV uses to "roll the dice" there is actually no chance of getting 0 so either rounding is fine. 

[altenbach]

---

@Darin.K wrote:

In this case, however, given the method LV uses to "roll the dice" there is actually no chance of getting 0 so either rounding is fine. 

---

Quote from the help on "Random Number (0-1) Function":

QUOTE: "Produces a double-precision, floating-point number between 0 and 1. The number generated is greater than or equal to 0, but less than 1. The distribution is uniform."

If this is incorrect and zero is not included, the help should be corrected.

OTOH, other sources say that the endpoints are not included! 😄

QUOTE: The LabVIEW Random Number (0 - 1) function produces numbers seeded by the system clock, rectangularly (evenly) distributed between 0 and 1, excluding the end points.

So, who to believe? In the past I was always going by Raven's advice, which is more correct according to the help. Next time we have to program that gambling machine for the casino, we better make sure that the math is completely bulletproof. 😄 So are you saying that the help is wrong?

[RavensFan]

I think that "other source" is wrong.

My experience with random numbers goes back 30 years and programming in Basic.  I was taught at a young age to always round down, and 0 is included, 1 is not included.  I have no reason to believe LabVIEW or any other programming language would have deviated from that.

If you think about it, a U8 number represents 2^8 or 256 values.  0 is included,  256 is not.  The top end is 1 bit below that or 255.  Now a random number generates a double, which is an 8-byte float.  That is 2^64 different bit combinations or about 18.4 e18.  I don't think it generates all of the possible bit combinations.  Some I believe are invalid.  Some are defintely NaN, +Inf, - Inf.  But I don't see why the generator would discard a perfectly valid value such as all 0's.

I would never say zero is impossible.  It is very unlikely, and if that one article is correct on at least the number of possible numbers produced, the probability of a hard zero is 1 in 6.95 trillion.  Which is less than winning the lotto, but still not zero.

[Darin.K]

---

@altenbach wrote:

---

@Darin.K wrote:

In this case, however, given the method LV uses to "roll the dice" there is actually no chance of getting 0 so either rounding is fine. 

---

Quote from the help on "Random Number (0-1) Function":

QUOTE: "Produces a double-precision, floating-point number between 0 and 1. The number generated is greater than or equal to 0, but less than 1. The distribution is uniform."

If this is incorrect and zero is not included, the help should be corrected.

OTOH, other sources say that the endpoints are not included! 😄

QUOTE: The LabVIEW Random Number (0 - 1) function produces numbers seeded by the system clock, rectangularly (evenly) distributed between 0 and 1, excluding the end points.

So, who to believe? In the past I was always going by Raven's advice, which is more correct according to the help. Next time we have to program that gambling machine for the casino, we better make sure that the math is completely bulletproof. 😄 So are you saying that the help is wrong?

---

What I can say is that on my systems I am able to take 2-4 values from the dice, lock onto the pattern of the PRNG and predict all future values.  Ideally it would take 1 value, but there can bit some bit errors when inverting the integer to DBL conversions so it sometimes takes an extra value or two.  This allows me to surmise that I understand the algorithm being used, and that algorithm does not include 0.  0 is a fixed point, which means if it returns 0, the next value is also 0 ad infinitum.

The big point I would make is that if you care whether it is [0,1) or (0,1) or (0,1] or whatever, do not use the dice.  If you have the slightest care about what the period of the PRNG is, what the distribution of bits is, then do not use the dice.   OTOH if you are creating that gambling game then by all means make 0 trigger the progressive jackpot. 

90% of the time I use the dice to create DBLs I flatten to string to create unique names, that is about the extent of it.