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
>
>
>
>
