--- In fc-solve-discuss_at_yahoogroups.com, "MichaelK" <wgreview_at_...>
wrote:
>
> Here are my observations and opinions on the autoplay controversy:
>
> It is always completely safe to play a card to the homecells
(foundations), I believe, when any possible card that could be played
onto it in a tableau column is either already home or can immediately be
played home. So we can play the six of clubs to its foundation pile if
the five of clubs, three of spades, and both red fours are already
there. This is true because 6C could only hold red fives and the 4S (of
the cards not already home). This is, I hope, a clear and obvious rule,
and was implemented in some of the earliest FreeCell
> programs (it is currently implemented by NetCELL among others).
>
> Are there any such plays which a solver would not want to make? I am
not aware of any, but I haven't ever designed a solver.
>
> Microsoft FreeCell does not fully implement this rule: it requires
that both red fives be home already before it plays the six of clubs.
(It does apply the rule in the case of twos.) MS FC plays the six of
clubs in this case, however, regardless of how many cards are on the
spade foundation. I would argue that this is an extension of the rule
described above, not the other way around. It is safe to play 6C to the
foundations 5C AS 5H 5D under the standard rules, since the six of clubs
in a tableau column cannot hold 4S or 2S (the necessary intervening red
cards being missing). But the play of 6C to 5C AS 5H 5D is *not* always
a safe play in the variant of FreeCell where worrying back (playing
cards from foundations back to tableau columns or freecells) is
permitted. (This variant has been examined for its effect on the
winnability of a few rare deals). In that variant, you might
conceivably need to extract 4S from some remote spot (or perhaps to
unblock a freecell) by playing a red five back from its foundation onto
the 6C, and putting 4S on the red five. So if worrying back is allowed,
the extra plays that MS FC makes beyond the rule I mentioned first are
not automatically safe.
>
> Microsoft FC is not the definitive version of FreeCell, though Wilson
Callan and Adrian Ettlinger considered it so and tried to make FreeCell
Pro (to its detriment) behave exactly like MS FC as far as autoplay and
supermoves were concerned, in order to make playback of recorded
solutions compatible. This was misguided, in my view, because (1) MS FC
has no automatic playback capability anyway, (2) it turned some
supermoves into monstrosities, and (3) Microsoft FreeCell later changed
its supermove rules, so that some recorded solutions no longer play back
correctly in MS FC anyway.
>
> Since it's my intention to eventually replace FreeCell Pro, I think
that FC solver designers (Danny, Shlomi, and Gary in particular) should
work out standards for what autoplays are recorded in solutions (and how
supermoves are recorded) without any reference at all to how Microsoft
FreeCell or FreeCell Pro did things. What works best for your solvers?
I would be happy to make whatever you three can agree on the standard in
both the FAQ and the eventual replacement program, FreeCell Virtuoso.
>
> As far as counting moves (for finding minimal solutions), I'll suggest
something which might simplify the uncertainty there too. I think that
no plays to the foundations should count towards the total -- only plays
to and from the columns and freecells. That way a particular solution
will be designated as having the same number of moves regardless of what
autoplay rule you are using (even AutoPlayAll or AutoPlayNone).
>
> Comments are welcome.
>
Automove logic for Keith's first scenario. Braces contain actual values
assigned.
/* Foundation: 5C 4D 3S 4H */
/* Card in Question: 6C */
int Test_1, Test_2, Test_3, Test_4, val_1[4], val_2[4];
val_1[C] = {6} = RANK( 5C ) + 1;
val_1[D] = {5} = RANK( 4D ) + 1;
val_1[S] = {4} = RANK( 3S ) + 1;
val_1[H] = {5} = RANK( 4H ) + 1;
val_2[C] = val_2[S] = {6} = MIN( val_1[D] , val_1[H] ) + 1;
val_2[D] = val_2[H] = {5} = MIN( val_1[C] , val_1[S] ) + 1;
Test_1 = {T} = ( RANK( 6C ) == val_1[C] );
Test_2 = {F} = ( RANK( 6C ) < val_2[C] );
Test_3 = {T} = ( ( RANK( 6C ) == val_2[C] ) && ( RANK( 6C ) <= (
val_1[S] + 2 ) ) );
Test_4 = {F} = ( Test_3 && ( RANK( 6C ) == 2 ) );
if ( Test_1 && ( Test_2 || Test_4 ) ) /* perform Horne
automove */
else if ( Test_1 && ( Test_2 || Test_3 ) ) /* perform WKRaymond
automove */
In this scenario, the 6C is not moved to the foundation as a Horne
automove, but it is moved to the foundation as a WKRaymond automove.
Automove logic for Keith's second scenario. Braces contain actual values
assigned.
/* Foundation: 5C 5D AS 5H */
/* Card in Question: 6C */
int Test_1, Test_2, Test_3, Test_4, val_1[4], val_2[4];
val_1[C] = {6} = RANK( 5C ) + 1;
val_1[D] = {6} = RANK( 5D ) + 1;
val_1[S] = {2} = RANK( AS ) + 1;
val_1[H] = {6} = RANK( 5H ) + 1;
val_2[C] = val_2[S] = {7} = MIN( val_1[D] , val_1[H] ) + 1;
val_2[D] = val_2[H] = {3} = MIN( val_1[C] , val_1[S] ) + 1;
Test_1 = {T} = ( RANK( 6C ) == val_1[C] );
Test_2 = {T} = ( RANK( 6C ) < val_2[C] );
Test_3 = {F} = ( ( RANK( 6C ) == val_2[C] ) && ( RANK( 6C ) <= (
val_1[S] + 2 ) ) );
Test_4 = {F} = ( Test_3 && ( RANK( 6C ) == 2 ) );
if ( Test_1 && ( Test_2 || Test_4 ) ) /* perform Horne
automove */
else if ( Test_1 && ( Test_2 || Test_3 ) ) /* perform WKRaymond
automove */
In this scenario, the 6C is moved to the foundation as a Horne automove.
Because Test_4 is simply Test_3 with an additional constraint, that's
why I consider the Horne automove algorithm to be a subset of the
WKRaymond automove algorithm.
Received on Thu Nov 29 2012 - 01:47:52 IST