# Manipulating random decimals

I've been slowly working my way into the world of AI and its representations of random. Well as you can guess this occurs from a call to random() resulting in a value between $[0, 1]$ to create a desired random effect/action.

What confuses me is that once we get a random number back, lets say $0.10831288644112647$ people tend to use it for one random action (flip a coin) but I was thinking why can't we keep using this number to dictate more actions? Maybe even flip a lot of coins??

Let's not just use the value we get back but the decimal place values too. Currently I'd expect that each value has a $1$ in $10$ chance to be a $[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]$ and thus we could flip a coin for each value?

Just speculating but wouldn't we now be able to flip $18$ coins still maintaining its random result?

Continuing off this idea could we take the result from one decimal place with another? ex

if randomResult[0] && randomResult[1] == 3 then flip coin 19

Edit: The first value would not be $[0,\dots,9]$!

-
Chop off the first digit (it can only be $0$ or $1$), and then use the other digits. Heads if the digit is less than $5$, tails otherwise. Yes, you could theoretically use all the decimal points (but I'm not sure if floating point may actually mess this up, I'll check). One advantage of only using one when you need it is that it is easier than maintaining a list to go through, and more clear what you are doing. –  George V. Williams Jul 18 '13 at 17:19
@GeorgeV.Williams Yea I just reread my question fixed the first digit, thnx. I'm not completely sure this would be random... Good point about the usability –  Nate-Wilkins Jul 18 '13 at 17:20

Mathematically, yes. We could generate $10$-digit random numbers and use each digit to determine one flip.

Unfortunately, this concept doesn't quite work. Consider generating $17$-digit random numbers (without trimming zeros, that is, $1.23030000$ not $1.2303$). Then we get the following results 100000 runs:

N | Freq.
__|_______
0 | 225425
1 | 160930
2 | 163908
3 | 164527
4 | 165253
5 | 165161
6 | 165476
7 | 164510
8 | 163528
9 | 161282


This is probably because not all numbers are $17$ digits long, so the padding which is added significantly biases towards zeros. We cannot ignore or trim the padding because then it is biased away towards zeros.

However, if we instead generated integers between $[0, 2^{n})$, we could use this to do coinflips (heads if the $n$th bit is $1$, or zero otherwise). It is the intricacies of floating point arithmetic which makes this method of random decimals unviable.

-
Why are we unable to trim the padded 0's off to a fixed size? If we can't remove the zeros then ignore them? –  Nate-Wilkins Jul 18 '13 at 17:43
@Nate, you will always have problems with numbers such as $0.1$ or $0.25$, any fixed size you choose will be arbitrary at best. –  George V. Williams Jul 18 '13 at 17:45
So essentially if I was to count the amount of zeros that occur in a number the padding would make the random biased, but if each digit was used instead (with a fixed amount of digits) the randomness of each digit is 1 in 10 correct? –  Nate-Wilkins Jul 18 '13 at 17:57

In theory, you are correct. If the number is truly a random real in $(0,1)$, you can use one call and get all the random numbers you need. In practice, there are only a finite number of random numbers that can be generated (certainly no more than $2^{53}$ in usual floating point, or $2^{64}$ if you generate integers) and the low order bits tend to be much less random than the high order bits. There may also be correlations between the various bit locations. Better to use a separate call for each number you need. There is a discussion of this in chapter 7 of Numerical Recipes and many monographs as well.

-
In practice I wouldn't use that many bits but that's a good thing to keep in mind, thanks! –  Nate-Wilkins Jul 18 '13 at 17:59