LabVIEW
Bug in 'Random Number (Range) U64' - Values can Exceed Upper Bound
Solved!
Hello,
I noticed that there's a bug in Random Number (Range) U64. When the difference between the Upper and Lower Bound exceeds 4294967295 (2^32 - 1), it's possible for the generated value to exceed the upper bound.
The VI splits the difference into two U32s, generates two random U32s, and then joins them back to make a U64. The bug comes from the upper bound of the random lo(x) being hardcoded to (2^32 - 1).
When it splits the U64, it uses the hi() terminal to randomly determine the hi() value of the random number it creates. However, if the random value for hi() equals the actual value for hi(), it's possible for the randomly generated number to exceed the bounds.
To easily demonstrate the bug, enter an upper limit of 4294967296 (2^32). Run it a few times and you'll quickly see it exceeding the upper bound half the time it runs.
Whenever the random hi(x) word equals 1, the value it outputs already equals 2^32 = 4294967296. If the random lo(x) equals anything other than 0, it will exceed the upper bound of 2^32. Specifying an upper bound of 2^32 actually gives an upper bound of (2^33 - 1).
4294967296 is split into:
hi(x) = 1
lo(x) = 0
If you were to create a new value using
hi(x) = 1
lo(x) = ____
A lo(x) of anything other than 0 will exceed the original value.
The random lo(x) long needs to take the random hi(x) value into consideration. When the random hi(x) value equals the hi(x) value of the difference, the random lo(x) value should be limited to the lo(x) of the difference.
That is, something along the lines of:
Actually, simply limiting the upper-bound of random lo(x) isn't enough.
Running with an upper-bound of 2^32 means that half the time, the random hi(x) equals 1. So half the time the value that gets returned is 2^32.
So the comment in 'Random Number (Range)' says it splits things into 32-bit integers because at the high ranges of U64, DBLs start to lose precision and some numbers might get skipped.
DBLs are listed as having a precision of 15 digits, and U64s can go up to 20 digits.
An idea instead of splitting the U64 into two U32s... if the value exceeds 2^32, subtract a big value from it (in the screenshot I chose 2^31). Multiply the range and this subtraction by the same random number, convert both to U64, then add them together. The small number should maintain random precision on the low-value digits, and it can no longer exceed the value / upper bound.
I think this would let numbers keep their low-decimal precision while also removing the bug where U64s can exceed the limit.
@ng1902 wrote:
Hello,
I noticed that there's a bug in Random Number (Range) U64. ... it's possible for the generated value to exceed the upper bound.
It is unclear if you think you discovered the bug, or that you discovered the LV known issues page 😉
@Frozen wrote:
@ng1902 wrote:
Hello,
I noticed that there's a bug in Random Number (Range) U64. ... it's possible for the generated value to exceed the upper bound.
It is unclear if you think you discovered the bug, or that you discovered the LV known issues page 😉
You have to admire the detective work. 🙂
