Saturday, April 7, 2007

HSS: Move Validity

More code for the Spider Solitaire game in Haskell, download link at the right as usual.

I haven't made a whole lot of progress, but I'm slowly churning through the functionality that was implemented in the Common Lisp version.

Included with the current version is the calculation of 'card clusters' as I call them. Here's the important bits of that:

-- card clusters
-- A cluster is a set of cards which may be moved at once. Like an 3, 2, 1
-- of clubs, for example.
-- In a column of the tableau, clusters are marked from 0 at the bottom
-- on up. So it is only valid to move cluster 0. But we keep track of the
-- other clusters in the column for strategic purposes.

compute_cluster :: [Card] -> [Int]
compute_cluster [] = []
compute_cluster xs = reverse $ rv_cards (reverse xs) 0
rv_cards [] _ = []
rv_cards [x] y = [y]
rv_cards (x1:x2:xs) y = y : (rv_cards (x2:xs) new_y)
new_y = if (plays_on_match x1 x2)
then y
else y + 1

-- True if c1 plays on c2, False otherwise
plays_on_match Card -> Card -> Bool
plays_on_match c1 c2 =
case (plays_on c1) of
Just x -> x == (c_value c2) && (c_suit c1) == (c_suit c2)
Nothing -> False

I've a bit of a dilemma as far as where to store data. In the CL version, what cluster a particular card was in card data structure itself. I'm debating if this is a good idea or not.

So say we've just made a move, so we're creating a new instance of the Spider_Game data structure, which will have the modified column(s). Do we compute the new columns, and then create a new version of them with the clusters properly filled in? Seems a bit inefficient.

And why exactly am I worried about efficiency at this point? Isn't premature optimization one of the great sins of a programmer?

Side note, I realize there are issues with the layout of the site, and it doesn't work so hot when your pre-formatted text is 80 columns wide, and the blog itself only wants me to post 60-column wide text. I'll need to fix that.

Edit: Trying out this really simple template, which allows wider columns for the blog post itself.

No comments: