We could discuss a plethora of "what ifs ...", but I stand by the
position that directly identifying each free cell is the only sensible
approach. However, if you want to write your solver so that it uses "f"s
in its notation, that's okay with me. Just don't expect much interest
from others if you want to share/discuss a solution.
I use to have special coding in my move_sngl() routine that checked for
many redundant move scenarios; i.e. "1f f1" and others that are more
complicated. I've since removed this coding because I discovered that my
logic for tracking move states also compensates for redundant moves.
A major milestone in developing an effective FreeCell solver is to
overcome redundant/wasteful moves ... and it's not trivial!
Right now, you're dealing with a single card flip-flopping between a
free cell and a single column. Before long, you'll be addressing the
issue where one or more cards will cycle between multiple columns and
multiple free cells. That's real fun to overcome! Running out of memory
becomes the next major issue as you maintain previous move states to
overcome redundant/wasteful moves and to not examine a path equivalent
to one you've already visited and discarded.
It's true that you can write a solver that doesn't maintain previous
move states, but the execution time goes through the ceiling unless you
can develop a very, very, very sophisticated move algorithm. Otherwise,
you end up with long and meaningless move sequences. If you're only
interested in whether or not a particular deal can be solved, then you
may be willing to sacrifice long solution sequences for the overhead of
maintaining move states.
HELSER ERIC JOSEPH wrote:
> (Note: for some odd reason, my email program is not copying replied
> material into the message...)
>
> One way of getting around that 'f' disaster is that the program does
> not allow the move 'fh'. If a card that you need to manually send home
> (i.e. before the automatic "sweep" gets to it) ends up in a freecell,
> it could have been sent from the tableau instead of to the freecell
> and then to home. During normal play, is it possible to:
>
> 1. Move a card "X" to a freecell that can't be sent home,
> 2. Then move enough cards home so that card X can legally be sent home and
> 3. Have no other legal moves to make?
>
> I'm getting this feeling it is... I can easily modify the program to
> allow this if necessary.
>
> In your example (a=8H b=8D col.6=9C), the program evaluates from a to
> d, so it would move the 8H. It continues from a to b to c to d until
> it finds a legal move. Is there a time when you absolutely MUST take
> the 8D instead?
>
> Here's my "disaster" so far of MS deal #1:
>
> f2*: since a2 is not legal, b2 is the move the computer makes.
>
> 1f 1f 1f 8f 61 87 57 52 61 82
> f2* 1f 81 f5 1f f1 1f 35 f1... (this continues for a while)
>
> After move 12 (1f), the program for some reason assumes it's safe to
> move the 3C to home. I thought I fixed that. Moves 15 and 16 and 17
> and 19 have absolutely no purpose, and I'm trying to squeeze them out.
> Tell it to just delete those two moves if the circumstances are right.
> (the final card is in a run, and it's being moved from A to B to A again)
>
> Right now it makes a whole lot of "1f f1" crap, but I'll get that
> taken care of...
Received on Tue Nov 18 2003 - 16:09:59 IST