-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

At 08:34 AM 14/08/2002 +0300, you wrote:
>I would suggest:

Interestingly enough, I came up with a very similar idea a few hours prior
to seeing your post.  My friend and I are looking at a way of determining
the quality of the generator.

I'll highlight the differences

>How to get randomly-biased dice number.
>
>1. Associate six 8-bit registers with six dice numbers.
>2. Init them with 128 values.

init them with 42,42,43,43,43,43 (yes, I know that this affects the first
few rolls, but that falls off soon)

>3. On each loop subtract 5 from  that register which
>    number was hit until it reached 0, of course.
>    And add 1 to other registers until they reached 255.

Using my init values, if you subtract 6 from the selected register and add
one to all others, it will work fine, though there needs to be a test for
falling below 0.
so,
On each loop, if (the selected register minus 5) is greater than or equal
to 0, subtract 6 from the selected register, then add 1 to all registers.


>4. Get 16-bit Sum of the registers.

Here's the advantage with mine:  The sum is always 256

>5. Get random value from 0 to the Sum.("White noise"-Jinx
>    is a Guru, "Black noise"-Roman is a Master ;-) :o)

Or the keypress duration of the triggering mechanism fed through a high
speed counter, and used as the seed for a random number generator algorithm.

Only, generate a number from 0 to the sum-1

>6. Summarize register values until this sum reached
>    previous "The Sum". Last register's number involved
>    with this summarizing is the "randomly-biased dice
>    number".

This becomes unnecessary with my algorithm.

>7. Go to "3."

With the effort to evaluate the performance of the uniform random number
generator, we came up with a thought about the principles behind this
generator: there are two extremes for uniform randomness:
1. For a 6-sided die, every number must come up within 6 rolls
2. The distribution of rolls converges to uniformity as the number of rolls
approaches infinity.

The number of rolls required for a uniform distribution can be expressed as
a number dependant on a factor between 0 and 1.  Call this number x, and
the number of required rolls i.  The number of different output
possibilities shall be called n.  Thus:

i = n*1/x

but n=1 is meaningless.  As x approaces 0, n becomes insignificant.  As x
approaches 1, n becomes the dominant variable.

The two extremes are not really useful, but there is a value of x somewhere
in between that should be effective.

I think that our two algorithms are close to this ideal.

Sounds like we basically had the same idea.

>Brendan Moran wrote:
> > Has anyone considered making normalized dice?
> >
> > The problem with truely random dice is that it can make certain
> > games
> > boring.  For instance:  playing Risk, some of my friends and I have
> > discovered that we will occasionally get on streaks of really bad
> > rolling, where we should have little or no resistance to our force,
> > yet our 30 some armies get devastated by no more than 7 enemy
> > armies.
> >
> > So, one of my friends, who is a computer scientist came up with the
> > idea to make dice that biased, not completely altered, but biased
> > the
> > roll such that there was not equal probability of hitting any number
> > after the first roll.  Instead there was a weighting towards numbers
> > which had been rolled less often.

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

iQA/AwUBPVodNwVk8xtQuK+BEQKkkwCg3z/OT+Bu8PA62LVmEc16+PdgoDkAn23j
JaTclv/J2BJxa+1nE2QcbhBI
=PplQ
-----END PGP SIGNATURE-----

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu