Rnd doesn't seem truly random when debugging

[cfox2001]

All,

I am working on a project that uses a lot of randomization, but when I run the app in debug mode, the returns I am getting are not truly random (statistically proven by observation and recording/comparing results.)

Is this just a quirk of the use of pointers in the IDE or am I missing something essential in my implementation of Randomize() then rnd()?

TIA,
CFox

 

[JohnH]

Have you tried the Random class in VB.Net?

 

[vis781]

First of all computers could never be truely random, it's just not possible. Second try using the random object supplied with the framework as opposed to the rnd function which is legacy code.

Dim MyRandom as new Random

 

[jmcilhinney]

As has been said don't use Randomize and Rnd but rather use a Random object.

Neither of these methods will produce a genuine random sequence of numbers. They produce what's called a psuedo-random sequence, which is more than adequate for most situations.

To answer your question, yes you are missing something. You're missing the fact that the MSDN help topic for the Randomize function specifically addresses this issue:

Because the Random statement and the Rnd function start with a seed value and generate numbers that fall within a finite range, the results may be predictable by someone who knows the algorithm used to generate them. Consequently, the Random statement and the Rnd function should not be used to generate random numbers for use in cryptography. For more information, see RandomNumberGenerator.

ALWAYS read the documentation first if you have a question. As that quote suggests, if you genuinely need a sequence of numbers with cryptographically strong randomness then the Framework provides a class for that purpose. The chances of your actually needing that level of randomness is fairly small, but there are applications where it's required.

 

[cfox2001]

Thanks, Guys

All,

Thanks for the responses. As far as Randomize and rnd() not being perfectly random, was fully aware of that, but when choosing integers from 1 to 16 and 11 comes up 5 times out of 60 (8.3%) when 16! is just a huge number is a little ridiculous, don't you think? Read the docs before posting; nothing indicated this large of disparity. Anyway, will use a random object, instead. I was just thinking that within debug, the IDE allocated pointers in memory that skewed the legacy functions, and that they would work properly once compiled and run outside the IDE....

Thanks again,
CFox

 

[jmcilhinney]

You've just posted that you got 11 returned 5 times out of 60 when generating random numbers from 1 to 16, then you mention factorial 16. Are you sure that you actually used 16! as your upper limit and not just 16, because that result looks about right for 16 possible values.

 

[cfox2001]

j,

The probability of 11 coming back randomly from 16 items (1 thru 16) 5 times out of 60 is 1/16 * 1/16 * 1/16 * 1/16 * 1/16. * (15/16^55), which is an outstandingly small number. I used 16! to simplify things. By the way, the intellisense doc for Random.Next(nLowerBound, nUpperBound) states that nUpperBound is the upperbound. Seems logical, but if you use Random(1, 3), three will never be returned, so to return a 3, you would need to use Random(1,4). Can you send this to MS?

Thanks,
CFoxh

 

[jmcilhinney]

You are using a completely flawed and irrelevant calculation. If you have 16 possible numbers then in a large random sample each number should be returned 1/16 of the time. That's 6.25%. You said that you got 11 returned 8.3% of the time. In a small sample like 60 that's fairly close to 6.25 so the result you get is entirely appropriate.

As for the bit about the upper bound for the Random.Next method, perhaps you should read the documentation for method bfore assuming that it's wrong.

Parameters

minValue The inclusive lower bound of the random number returned.
maxValue The exclusive upper bound of the random number returned. maxValue must be greater than or equal to minValue.

Further to that, the calculation you are performing is actually determining the likelihood of getting 11 returned 5 times in a row when randomly selecting a number in the range 1 to 16.

Further to the quote from MSDN:

Return Value

A 32-bit signed integer greater than or equal to minValue and less than maxValue; that is, the range of return values includes minValue but not maxValue. If minValue equals maxValue, minValue is returned.