Hi Danny,
trying to understand your logic I ran into what appears to be a bug:
On Thu, 29 Nov 2012 09:47:49 -0000
"dannyjones183" <dannyjones183_at_yahoo.com> wrote:
>
> --- 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 ) );
Are you sure that it should be RANK( 6C ) == 2 (with a constant of 2.)? 6C can
never have such a rank so the test will almost always fail. Of can you only
play cards with a rank of 2 this way?
Regards,
Shlomi Fish.
>
> 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.
>
>
>
--
-----------------------------------------------------------------
Shlomi Fish http://www.shlomifish.org/
The Case for File Swapping - http://shlom.in/file-swap
Chuck Norris wrote a complete Perl 6 implementation in a day, but then
destroyed all evidence with his bare hands, so no‐one will know his secrets.
Please reply to list if it's a mailing list post - http://shlom.in/reply .
Received on Mon Dec 10 2012 - 04:07:10 IST