Truly Random Numbers

[Dannerino]

Using: Access 2003 SP3. I'm trying to generate random numbers to mimic the
truly random nature of rolling dice. My code is...

***************************************
Randomize

For intCounter = 1 to 5 'For each of the five dice being rolled
intDiceValue(intcounter) = ((6 * Rnd) + 1)
Next intCounter

*******************************************

I then have a simple INSERT INTO sql statement that inserts the results of
each roll into a table, specifically to track the frequency that each number
is rolled.

I realize that the count of each number, one thru six, is not going to be
exactly even with the rest. But my results seem very skewed, so I'm
wondering if my code has a flaw. I've rolled the number three a good 4.5
times as often as rolling a one. Rolling a 4, 5 or 6 happens with about the
same frequency. And rolling a 2 is almost as rare as a 1.


As I understand it, running the Randomize function before looping through
and generating 5 random numbers means the seed is generated based on the
system clock. Any ideas?

 

[Dannerino]

I have noticed that certain rolls return exactly the same results as the roll
prior, sometimes more than once. The odds of rolling the same 5 dice two
rolls in a row are a little slim. But 3 and 4 times in a row?

It must be something in my code. My application will sometimes go from a
roll of all 5 dice right to another roll of all 5. Sometimes a roll of 5
dice is followed by a roll of only 4 or less. The 5 followed by 5 is the
situation in which the roll is exactly as the prior roll.

 

[Dale Fye]

Personally, I'd use

intDiceValue(intCounter) = int(6 * rnd) + 1

but there really shouldn't be much difference between this and what you had.

I've run that for 50000 roles of the die, and got the following results:

Value Freq
1 8396
2 8233
3 8334
4 8338
5 8335
6 8364

While I have not run a ChiSquared test against these values to test whether
they are truly uniform, they look pretty good to me (when compared to an
expected value of 8333.33), although there is some inconsistent in 1 and 2.

The fact that you have repeat numbers occuring is not that unusual when you
figure that 1 out of every six times you roll a die, you would expect it to
be the same value as the previous roll, and since these are independant of
one another, the chance of getting another roll of the same value is still 1
in 6. So the chance of getting three consecutive die with the same value
should be 1/36.

With the dataset I generated above, I got 1385 instances where three
consecutive numbers matched, which was only 3.8 off the expected value of
1388.8 (49998/ 36). There were 237 instances of 4 consecutive numbers which
matched, compared to the expected value of 231.

--
HTH
Dale

email address is invalid
Please reply to newsgroup only.

 

[John Spencer]

Are you using RANDOMIZE function anywhere in your code? If not, it is
very possible that you are going to get the same sequence of random numbers.

From help
If Randomize is not used, the Rnd function (with no arguments) uses the
same number as a seed the first time it is called, and thereafter uses
the last generated number as a seed value.

'====================================================
John Spencer
Access MVP 2002-2005, 2007-2009
The Hilltop Institute
University of Maryland Baltimore County
'====================================================

 

[david]

Note,

intDiceValue(intcounter) = ((6 * Rnd) + 1)

will only give half as many 1's as it does 2's,
and will put 7's into your table.

Rnd is a number between 0 and 1
6*RND is a number between 0 and 6
((6*RND)+1) is a number between 1 and 7

intDiceValue(intcounter) is 1 if ((6*RND)+1) is between 1 and 1.5
intDiceValue(intcounter) is 2 if ((6*RND)+1) is between 1.5 and 2.5

intDiceValue(intcounter) is 7 if ((6*RND)+1) is between 6.5 and 7



When you add the result of die roll, you no longer have a
flat distribution, it approaches a 'normal' distribution.

Getting 6 on a double roll is much more likely than getting
2 or 12. Your numbers make me wonder if you have made
a mistake with your algorithm, but 5 rolls isn't enough to
draw a conclusion from.


(david)

 

[John Spencer]

Int TRUNCATES it does not round. Int(1.99) --> 1
CInt rounds as you have described. CInt(1.99) --> 2

'====================================================
John Spencer
Access MVP 2002-2005, 2007-2009
The Hilltop Institute
University of Maryland Baltimore County
'====================================================

 

[John Spencer]

David,

Whoops, I forgot to mention that helps says:

The Rnd function returns a value less than 1 but greater than or equal
to zero.

So given that plus the facts previously posted about INT, your analysis
is faulty.



'====================================================
John Spencer
Access MVP 2002-2005, 2007-2009
The Hilltop Institute
University of Maryland Baltimore County
'====================================================

 

[david]

?? I didn't get that when I tried it:

Public Function asdf()
dim i as integer
Dim rs As DAO.Recordset
Set rs = CodeDb.OpenRecordset("table6")
rs.AddNew
rs!idxRegister = 12
rs!nValue = 6.6
i = 6.6
MsgBox i
rs.Update

End Function


Also, I think you should check the arithmetic again?

(david)

 

[John Spencer]

Didn't get what? If you mean you get 7 when you set I to 6.6 that is
expected. You are not using the INT function - which truncates. You
are assigning a value to an integer variable and when you do so, the
variable (or an integer field) will round the number if it is not an
integer.



'====================================================
John Spencer
Access MVP 2002-2005, 2007-2009
The Hilltop Institute
University of Maryland Baltimore County
'====================================================

 

[david]

John Spencer, I was replying to a message from Dannerino.

When I wrote my reply to Dannerino, I hadn't even seen
your suggestion to use the INT function. Since I was replying
to Dannerino, I would have replied to his code even if I had
seen your code.

I am afraid that you might be misleading Dannerino by confusing
Dannerino's code with your code. In this context, your code
is irrelevant. Dannerino's sample code was unbalanced and
returned numbers in the range 1-7.

I think that if you want to talk about your own code in my
critique of his code, you should make it clear that you are
changing the subject.

I agree that in the general scheme of things, it doesn't matter
which exact message you reply to. But when you are changing
the subject, I think you need to be a little more careful.

I'm sure that this was an accident, like your arithmetic error, it
probably just indicates that you were tired, but you compound
the error by replying without admitting your mistake.

(david)

 

[Dale Fye]

Who are you???

I thought John's explaination made a lot of sense. But since we have not
heard back from the OP since my original post 3 days ago, he has probably
already figured this out, or forgotten about it.

BTW, in you original post you indicate that the distribution with the code
the way he has it will look more "normal" than "flat". If you actually knew
anything about statistics, you would refer to a "flat" distribution as
"uniform".

--
Dale

email address is invalid
Please reply to newsgroup only.