This is why the randomness issue is really only critical for simulation.
It is in simulations where the small biasses of a poor PRNG can accumulate
into larger effects (which I was embarassed to not notice in my research in
the early 90s).
Also, if you go with the shuffle approach, you have to be very certain that
the simulation creates new bag shuffles each time (otherwise the simulation
is cheating by using the exact same ordering that the game will be played
with).
Steven Gordon
On 9/12/07, John Van Pelt <[EMAIL PROTECTED]> wrote:
>
> As a layperson's side note, it would be interesting for all those "isc
> bots cheat," "Maven cheats," "Q cheats," etc., whiners to read this thread.
> Not that it would convince them. But to notice that the programmer's drive
> -- their essential ethic -- is to *maximize* randomness. It's apparently
> hard -- maybe impossible -- to program "perfect" randomness; but the
> challenge is what counts. It's what a bithead thrives on -- "it's supposed
> to be random, so how can I code it ideally?" At no point in the design
> heuristic does even accidental bias creep in -- certainly not of the sort
> people think they detect, like "the bot draws better tiles" or "the bot
> always just happens to have the needed hook when I don't." That would
> require:
> - that the programmer *intend* that as the outcome
> - a LOT LOT LOT LOT more work.
>
> I don't mean to dignify that conversation further, because it's just so
> ridiculous. But the slight bias or non-randomness that might be exhibited
> by a suboptimal tile-drawing routine wouldn't even be detectable on the
> scale of a single game, let alone routinely favor one player over another.
>
> -jvp, preaching to the choir
>
> On 9/12/07, Graham Toal <[EMAIL PROTECTED]> wrote:
> >
> > On 9/12/07, jasonkatzbrown <[EMAIL PROTECTED]> wrote:
> > > I'm surprised you would ask, even out of jest, but tiles are drawn as
> > > pseudo-randomly as they need to be. If you want to further
> > > investigate, all tile drawing goes through this one function that
> > > draws one letter from the bag:
> > >
> > > [bag.cpp]
> > >
> > > Letter Bag::pluck()
> > > {
> > > return erase(DataManager::self()->randomNumber() % m_tiles.size());
> > > }
> >
> > You're probably aware that there is a *slight* bias in that code
> > (consider the degenerate case of a random number generator that
> > returned a value in the range 0..7, and you wanted to pick a die face
> > in the range 0..5 - then the values 6 and 7 would map to 0 and 1,
> > making them twice as likely to turn up. However since the PRNG range
> > is probably 32 bits (or at worst 16) then the extra probability of the
> > end cases is vanishingly small.
> >
> > However, to ensure a fair distribution no matter how bad the PRNG, a
> > better algorithm is to use the card shuffling trick once at startup,
> > and then take the tiles sequentially from the shuffled list. (The
> > shuffling alg is to go down the list one by one, swapping the current
> > element with the last element if a random function in the range 0..1
> > is 0. Then for added safety, create that random function by exoring
> > *all* the bits from your PRNG down to a single bit, in case you have a
> > bad PRNG with a bias at one end or the other.
> >
> > regards
> >
> > Graham
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>
>
