Hi Gary,
On Wed, 28 Nov 2012 08:30:20 -0800
"Gary Campbell" <gary_at_numin8r.us> wrote:
> Hello Danny & Shlomi,
>
> I feel like weighing in on this subject just a bit. I see 3 areas (each with
> 2 components) under discussion: 1. The definition of a Supermove (targeting
> an occupied column vs. an empty column). 2. Standard Notation (a sequence of
> moves vs. a card layout). 3. The definition of an Automove (Horne vs. WKR).
>
> My solver communicates with the Faslo Frecell Autoplayer using all of the
> above, so it clearly defines one possible “standard.”
>
> The definition of a Supermove has advanced since the first MS Freecell
> player, and I should think that it is standardized by now. Simply stated, a
> proper sequence of cards may be moved from one column to another as long as
> the length of the sequence moved does not exceed a maximum calculated as
> follows: (number of freecells + 1) x 2**(number of empty columns not
> counting the target column).
>
> As for Standard Notation, the following is an example of a layout followed by
> a sequence of moves. I would not argue for every characteristic of this
> example, but I do believe that a uniform font should be used, that the card
> notation is reasonable, and that the cards ought to be in columns rather than
> rows. This example was emitted to the Clipboard by pressing F9 within the
> Faslo Freecell Autoplayer. It can be input to my solver as-is.
Freecell Solver has an option to display the cards inside each Freecell stack
properly aligned inside columns instead of text lines. This is the default
behaviour in order to maintain backwards compatibility. Here is an example
position from «pi-make-microsoft-freecell-board -t 24 | fc-solve -t»:
<<<<<<
3D 8H JH 9H H-5 C-A D-A S-4
--- --- --- ---
-- -- -- -- -- -- -- --
4C KS QC 2D 7H 9D 7S
2C QH 9S KD JS 8S 6C
9C 6H TH KH 7D
8C 5C TC TS 6S
QS TD KC 5D
JD 8D QD
7C JC
6D
5S
4D
3C
>>>>
The reason what I prefer adding the optional (but recommended) -p flag (for
"Parseable" or "Perl" or whatever) is because Freecell stacks that are placed
in lines are much easier to parse, and to search for using other UNIX (or
UNIX-originated) text-processing tools, that make use of regular expressions:
http://en.wikipedia.org/wiki/Regular_expression
Another advantage is that those positions can be input as is to the solver,
which accepts input with stacks represented as lines.
While they may be a little harder for a human to read, I got used to that very
quickly, and I think they outweigh the disadvantages.
>
> 7H 6H 9C TH 6C TC 2H 9D 3D 3C 2S AH
> 6S 5S QS JH KS QC KC QH KD QD
> 7D JC 4H 8C 6D 5D
> 4C JD KH 5H 8D
> 4D TS 4S 5C 7S
> 3S 9H 3H JS
> 8S TD
> 9S
> 8H
> 7C
> GAME #6276 is solved partially as follows: {17 1 1 0 3 4 1252 1253 2 2 0 0 62
> 62 2000 110} 32 35 15 67 47 1a 13 1h 1b 21
> 24 27 24 a2 8h 8a 87[27]14 b1
> 71 72 72 7b 5c 5d 87 32 65 47
> 45 Solved
I don't understand the notation. Why do you have so many Freecell stacks? There
should only be 8. What are the numbers inside the curly braces ({ .... }). What
is the [27] inside the square brackets?
>
> The line between the layout and the solution, of course, is strictly
> arbitrary and should not be considered as any suggestion for a standard. The
> position of the cards in the freecells and home cells is also arbitrary, and
> would be easier to read if more spaces set them off from the columns.
>
> As for the solution, I would argue that the notation is already pretty close
> to a standard. Only the definition of the missing Automoves, and some
> extended notation to indicate the extremely rare moves of a single card to an
> empty column, where the normal move would be the maximum legal number of
> cards, needs to be added (I replace the space before a move with a . to
> indicate this).
Well, it still suffers from several of the faults I noted in my original rant
against the standard notation, and requires an explanation for laymen
(including me) to parse.
Regards,
Shlomi Fish
>
> That brings us to a Standard Definition for Automoves. The Horne Automove is
> one such standard, and I don’t think there is any dispute over it, since it
> is implemented in the original Autoplayer. An Automove is a move that can be
> made in the context of any conceivable layout without the possibility that it
> could prevent a solution. The Horn Automove is a minimal Automove (it fits
> the definition, but does not include some moves that also fit the
> definition). The WKR Automove is a maximal Automove (it also fits the
> definition, but it includes all the moves that fit the definition).
>
> There are also “relaxations” of the WKR Automove that include some rare moves
> that could prevent a solution. It turns out that the Horne Automove is the
> easiest to define (and implement in the code), and that the WKR Automove is
> the hardest, with certain invalid Automoves in between in terms of definition
> and implementation.
>
> I guess that’s all I have to say at this point.
>
> -Gary Campbell
--
-----------------------------------------------------------------
Shlomi Fish http://www.shlomifish.org/
Stop Using MSIE - http://www.shlomifish.org/no-ie/
He says “One and one and one is three”.
Got to be good‐looking ’cause he’s so hard to see.
— The Beatles, “Come Together”
Please reply to list if it's a mailing list post - http://shlom.in/reply .
Received on Thu Nov 29 2012 - 04:02:44 IST