"Chuck Crayne" <ccrayne@[EMAIL PROTECTED]
> wrote in message
news:20080719200051.508a3701@[EMAIL PROTECTED]
> On Sat, 19 Jul 2008 18:50:56 -0400
> "Rod Pemberton" <do_not_have@[EMAIL PROTECTED]
> wrote:
>
> > Now, the
> > internal representation of the deck of cards used by a computer
> > program isn't random at all but is sequentially ordered:
> > 1,2,3,4, ...,51,52.
>
> In some cases, yes.
I was stating the problem...
> Often the deck is shuffled, and the cards are
> sequentially dealt out to the various hands. In the specific case of
> "gnome-hearts", which is the game engine for which I wrote my AI
> player, The deck does remains in order, but the cards are drawn
> randomly from the deck. At no time does the game engine ever have a
> representation of a random deck order.
>
.... not presenting general a belief about real world implementations.
> > Well, it possibly does
> > so by a conversion function and an specific input to that function.
>
> Such a function is useful for creating the initial (shuffled) state of
> the deck, so that a player may note the number of the hand and replay
> it at some future time. However, if this technique is used, there is no
> need for the game engine to also have a sequentially ordered deck
> representation.
True. That's the input function: unordered set. It doesn't have to be
created except if the function explicitly requires it as the input. The
function may generate it or not need it.
> > This is only useful if functions to do
> > the opposite also exist.
>
> In the context we have been discussing, such a reverse function is not
> necessary, since tracking the specific order of the cards is only of
> use at the time when the cards are dealt.
Depending on the game, the deck is shuffled, dealt, and typically drawn
from
repeatedly throughout the game. I.e., after the deal and after each draw,
you have a smaller deck. This could be represented by an additional value
of the cards remaining in the deck. But, perhaps different deck is created
if another shuffle is involved. I.e., you could have a "new"
representation
and need the reverse.
> Once the cards are moved from
> the deck to a player's hand, it no longer matters in which order they
> were received.
If the game has no further ability to draw, discard, or pickup a discard
pile, then true...
> It is axiomatic that all possible permutations of 52 cards, no matter
> how ordered, can be held in an array with 52 columns and 52! rows.
Out of memory error... and we were striving for a function, but okay.
> To
> convert a row number into an array pointer, one merely multiplies the
> row number by 52 and adds the result to the address of the start of the
> array. In the worst performing case, the reverse function can search
> the rows for a match. Beyond this, everything else is just optimization.
>
> If we use a function generator,
Good.
> then we can do away with the actual
> array, and just create a single row, as needed.
How? Try to generate 1...47,52,51,50,49,48 without an array from some
function. Or, try to generate 1..47,52,51,50,49,48 with an input array of
1...52 from some function.
> In the worst
> performing case, the function generator can do this by simply stepping
> through the algorithm, and throwing away the result until it gets to
> the desired row.
Slow...
> Or, we could represent each of the 52 cards as a single digit in a base
> 52 number system, and each permutation as a 52 digit number in that
> base.
Sigh...
Rod Pemberton
|
