On Mon, 10 Dec 2001 WKRfresno_at_aol.com wrote:
> After universal solution format is adopted...
> > (1) Whether moves to empty columns are (a) single card or (b) multiple card
> I'm DESPERATELY trying to alert all of you that (1)(a,b) is a DISASTROUS
> limitation that MUST NOT be allowed to HANDCUFF us forever.
Another fun variation is "kings only" where you can only play a king to an
empty column. Almost all 4-freecell games are still solvable within this
constraint. A solution format that allowed many different variations
(i.e., a least common denominator) would appear to be desirable.
Codes and such in the solution might be useful, but should also be
decorative, and placed on a comment line. The moves should be
self-explanatory. Column numbers suck. (I guess I'm up to 4 yen now.)
> My own rule is much stronger; I call it "Raymond's Rule" because I
> worked it out, implemented it, and discussed it with others before anyone
> else thought about it. Noone on this forum has yet given any indication that
> he understands why it's important.
Well, I haven't been listening for a while. Would you care to go into
more detail about this?
> My solver has had a fourth goal: find and solve all the 52-card-flourish
> games. Already accomplished.
Cool.
By the way, if I might delve into solver internals here for a moment, do
you use a position store to keep track of already visited positions? If
so, and it would seem to be a requirement to avoid exponential blowup,
what is the smallest number of bytes required to encode a position?
Shlomi uses MD5 over the whole position (guaranteed to have collisions
overall, though I can't prove it'll always, or ever, happen within a given
game), and I use a simple sixbit compression scheme over the whole
position (with the piles sorted). My current implementation has two
features: perfect hash and invertible. Now, for the "have I been here
before" test, only a perfect hash is needed, so it should be possible to
separate these functions, keeping very lightly compressed representations
around on queues of positions waiting to be evaluated, while the hash can
be very compact but not invertible (but still perfect). Can you get away
with just the visible cards, or just the cards that have been moved, or
something else? I haven't had time to study this much.
(A drawback of a position store is that it prevents the cool feature of
having the solver keep going after finding a solution, looking for others.
But there are so many solutions "near" a given one that you have to thin
them somehow.)
Dr. Tom Holroyd
"I am, as I said, inspired by the biological phenomena in which
chemical forces are used in repetitious fashion to produce all
kinds of weird effects (one of which is the author)."
-- Richard Feynman, _There's Plenty of Room at the Bottom_
Received on Mon Dec 10 2001 - 19:40:45 IST