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.
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
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).
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
From: dannyjones183
Sent: Tuesday, November 27, 2012 4:01 PM
To: fc-solve-discuss_at_yahoogroups.com
Subject: Re: Usable Solution vs. Any Solution
Hello Shlomi,
General:
There was a web site associated with FcPro that explained in detail the features of FcPro. It included a comparison against several MS Freecell features. Since the Help packages for these two programs are minimal, this web site came as close as I recall to documenting these two programs. However, that web site is gone ... and Michael Keller's web site is now impossible to navigate for alternative documentation. That leaves no semi-authorative place to get information on MS Freecell and FcPro features/logic.
Automoves:
MS Freecell was written by Jim Horne and it uses an automove algorithm that, to my knowledge, he never documented. FcPro uses Horne's automove algorithm as well. So, (1) and (2) of your automove policies list are identical. I'm fairly sure that Gary Campbell's and my implementation of Horne's automove algorithm are in agreement with these programs. The "active" version of my solver now uses Horne's automove algorithm.
WKRaymond developed a more comprehensive automove algorithm. It is often treated as an extension to Horne's automove algorithm, but I consider Horne's automove algorithm to be a subset of WKR's automove algorithm. In addition, a "grey area" arises when one considers how to implement WKR's automove algotithm in a solver. I suspect that you, Gary Campbell, and I have three different implementations of WKR's automove algotithm in our solvers.
The "inactive" version of my solver uses WKR's automove algotithm in what I call "full automove" mode. This means that the WKR automoves aren't recorded in the solutions output by my solver. Since I use FcPro to visual replay my solutions, I have a Convert program that takes the output from my solver and formats it for input into FcPro. My Convert program must divide the WKR automoves into two groups. The first group matches Horne's automoves, and aren't included in the input file to FcPro. The second group is treated as generated moves and are included in the input file to FcPro. Note: one must be careful when mixing Horne and WKR-only automoves after a move.
Supermoves and Card-to-Empty_Column Moves:
There use to be a difference in how MS Freecell implements multi-card moves and the supermoves of FcPro. I believe that both programs now use supermoves. My solver, irrespective of the automove algorithm used, must conform to the supermoves and card-to-empty_column moves supported by FcPro so I can use it to replay my solutions. You and Gary Campbell have alternate ways to display your solutions, so it's unlikely that either of you have the same constraints as me when generating some moves. This further complicates compliance between our solutions.
Etc:
As it builds the information for input to FcPro, my Convert program displays the condition of the initial table and the table after every generated move. I plan to extend the listing to include specifics on Horne/WKR automoves performed after each move. However, the layout of each table is arranged to emulate the layout displayed in the FcPro player and not the format used to load a general layout.
Bottom Line:
I think that it'll take more effort to arrive at an agreement for information exchange than we'll ever receive benefit from during our discussions. Still, I'm willing to participate if you and Gary Campbell feel that there's sufficient reason to continue.
Regards, Danny A. Jones
--- In fc-solve-discuss_at_yahoogroups.com, Shlomi Fish <shlomif_at_...> wrote:
>
> Hi Danny,
>
> I'm not sure I get to the bottom of the table you've entered, especially given
> that I'm not fluent in reading standard notation. However, I should note that
> this entire thread demonstrates one of the reasons why I dislike the so-called
> "standard notation" - it is hard to implement the automoves in a way that will
> conform to the quirks (and the bugs) of Microsoft Freecell or Freecell Pro.
>
> So far I can think of several automove policies:
>
> 1. The MS Freecell one.
>
> 2. The FreeCell Pro one.
>
> 3. The Raymond prune one.
>
> 4. The buggy one as implemented by the horne play misinterpretation in
> Freecell Solver.
>
> 5. A hypothetical one with no moves whatsoever.
>
> And there may be others. The two other reasons why I dislike standard notation
> are:
>
> 1. It is incredibly easy to misplace the position where one stopped following
> the solution, while in the Freecell Solver "-p -t -sam" solutions, each board is
> fully displayed, allowing for an easy to follow the solution again.
>
> 2. The column to an empty column moves are ambiguous with respect to the number
> of cards being moved. The extended standard notation fixed it in part by
> adding a v parameter (but which is only respected by a standard move).
>
> ----
>
> As a result, I think we need a better standard for notating the
> solutions of Freecell and other solutions. I think the "fc-solve -sam -p -t"
> solutions are pretty good, but we may wish to consider something based on XML
> or JSON (see http://en.wikipedia.org/wiki/JSON ). I realise I sound a little
> like http://xkcd.com/386/ , but I hope you can see my point.
>
Received on Wed Nov 28 2012 - 08:31:10 IST