> A mixed linear congruential generator has both the add and the multiply,
> whereas an additive LCG uses a = 1 (which is what is going on here).
> Similarly, a multiplicative LCG uses b = 0.
>> > The problem with more sophisticated RNGs are that some value in
> > [0..N-1) might be generated twice before having exhausted the entire interval.
> > (Or am I wrong at that point?)
> > This was what Dan tried to avoid.
>> Any RNG will have some finite period p. Assuming the RNG was well setup
> it will iterate through all values 0..p-1 or 1..p-1 exactly once each
> before repeating its period. So, choosing an RNG with a period p
> greater than n (the number of songs), you can simply discard values that
> lie outside of the range 1..n until you land an a value within the
> range. This is only practical if p isn't too much larger than n.
>> The built in RNG in any OS is likely to have a very large period,
> effectively as large as the machine word size. The problem with using
> that for selecting values in 1..n is that *most* of the values will lie
> outside of the range 1..n. Thus, some other mapping is applied to bring
> the values into that range (dividing by RANDMAX/n, or taking the value
> mod n). These mappings then make it very likely that certain values in
> the range 1..n will be visited multiple times before the entire range is
> exhausted, which is the cause of current problems.
>> Chris
Ah :) Thanks for clearing that up. That also explains your selection
between 32 p's.
And as Dan points out, 50 is a small number of songs, and even +13
would propably be random enough.
I still have have one concern, though. The sequence will be identical
each time for the same P and same N, right? This happens in some mp3
players and is pretty annoying since you know which song will be the
next after a couple of rounds on your small collection of ABC music :)
But then again, we could have a small selection of p's for each power
of two, and choose randomly between those.
- Lasse Nisted