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 Tue Nov 27 2012 - 16:01:36 IST