Loading ...
Sorry, an error occurred while loading the content.

Re: Usable Solution vs. Any Solution

Expand Messages
  • Shlomi Fish
    Hi Danny, On Sun, 18 Nov 2012 16:41:01 -0000 ... I m not sure I get to the bottom of the table you ve entered, especially given that I m not fluent in reading
    Message 1 of 28 , Nov 26, 2012
    View Source
    • 0 Attachment
      Hi Danny,

      On Sun, 18 Nov 2012 16:41:01 -0000
      "dannyjones183" <dannyjones183@...> wrote:

      > (replacing all previous reply attempts. Aaaagh!!!)
      >
      > How I see the moves performed:
      >
      > #00006240 Attempt: 1 NumFcs=4 (ShlomiFish) 173 moves
      >

      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.

      Regards,

      Shlomi Fish

      --
      -----------------------------------------------------------------
      Shlomi Fish http://www.shlomifish.org/
      What does "Zionism" mean? - http://shlom.in/def-zionism

      Chuck Norris can read Perl code that was RSA encrypted.

      Please reply to list if it's a mailing list post - http://shlom.in/reply .
    • Gary Campbell
      I think “standard” notation is pretty well defined for both types of Automoves. Buggy interpretations of the automoves can be fixed. My Solver implements
      Message 2 of 28 , Nov 26, 2012
      View Source
      • 0 Attachment
        I think “standard” notation is pretty well defined for both types of Automoves.
         
        Buggy interpretations of the automoves can be fixed.  My Solver implements
        both types of automove and they are well defined threin.  My partner who
        developed the FFA Freecell Player also had no trouble with the Horne Automove.
        The proper automove is the Raymond.  The most common is the Horne.  I don’t
        see a problem implementing either or both, or calling them “standard.”  But,
        that’s just my opinion...
         
        -Gary Campbell
         
        Sent: Monday, November 26, 2012 4:38 AM
        Subject: Re: Usable Solution vs. Any Solution
         
         

        Hi Danny,

        On Sun, 18 Nov 2012 16:41:01 -0000
        "dannyjones183" <mailto:dannyjones183%40yahoo.com> wrote:

        > (replacing all previous reply attempts. Aaaagh!!!)
        >
        > How I see the moves performed:
        >
        > #00006240 Attempt: 1
        NumFcs=4 (ShlomiFish) 173 moves
        >

        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.

        Regards,

        Shlomi Fish

        --
        ----------------------------------------------------------
        Shlomi Fish http://www.shlomifish.org/
        What does "Zionism" mean? - http://shlom.in/def-zionism

        Chuck Norris can read Perl code that was RSA encrypted.

        Please reply to list if it's a mailing list post - http://shlom.in/reply .

      • dannyjones183
        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
        Message 3 of 28 , Nov 27, 2012
        View Source
        • 0 Attachment
          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@yahoogroups.com, Shlomi Fish <shlomif@...> 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.
          >

        • Gary Campbell
          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
          Message 4 of 28 , Nov 28, 2012
          View Source
          • 0 Attachment
            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
             
            Sent: Tuesday, November 27, 2012 4:01 PM
            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@yahoogroups.com, Shlomi Fish <shlomif@...> 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.
            >

          • Shlomi Fish
            Hi Gary, On Wed, 28 Nov 2012 08:30:20 -0800 ... Freecell Solver has an option to display the cards inside each Freecell stack properly aligned inside columns
            Message 5 of 28 , Nov 29, 2012
            View Source
            • 0 Attachment
              Hi Gary,

              On Wed, 28 Nov 2012 08:30:20 -0800
              "Gary Campbell" <gary@...> 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 .
            • Gary Campbell
              From: Shlomi Fish Sent: Thursday, November 29, 2012 4:02 AM To: fc-solve-discuss@yahoogroups.com Cc: gary@numin8r.us Subject: Re: Usable Solution vs. Any
              Message 6 of 28 , Nov 29, 2012
              View Source
              • 0 Attachment
                Sent: Thursday, November 29, 2012 4:02 AM
                Subject: Re: Usable Solution vs. Any Solution
                 
                  Hi Gary,
                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.
                -----------------------
                RESPONSE:  Your example above would be more understandable if along
                with the layout, there were some indication of the Game # and the moves
                that got to that position.
                 
                My philosophy has always been that a little extra effort should be made by
                the software engineer to accommodate the user.  That’s why I advocate
                columns rather than rows.
                ------------------------
                >
                > 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?
                -----------------------
                RESPONSE: 
                The extra columns (I thought my explanation made it clear, but I guess not)
                are for the top cards of the home cells (first row) and the cards in the freecells
                (second row).  These two sets of 4 cards are appended to the first to rows of
                cards in the 8 stacks.  A better notation might be like yours, to put them onto
                an initial line of their own.
                 
                The curly braces (see original text, just below) enclose parameters
                to FFA to allow it to reset some needed internal variables.  They are not part of
                the notation, and do not need to be included for my Solver to parse the layout.
                 
                The [27] is simply one of the moves of the solution.  It is the next move.  The
                move that continues from the given layout.
                ---------------------
                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.
                -------------------------
                RESPONSE:  Everything requires an explanation to parse.  Are the faults
                it suffers from related to ease of parsing?  If not, perhaps you could use
                the example and indicate its faults explicitly.
                 
                --------------------------
                Regards,

                Shlomi Fish

              • Shlomi Fish
                Hi Gary, On Thu, 29 Nov 2012 10:14:38 -0800 ... As noted in the pipeline the game number is 24, and I omitted the rest of the solution, to reduce the length of
                Message 7 of 28 , Nov 29, 2012
                View Source
                • 0 Attachment
                  Hi Gary,

                  On Thu, 29 Nov 2012 10:14:38 -0800
                  "Gary Campbell" <gary@...> wrote:

                  > From: Shlomi Fish
                  > Sent: Thursday, November 29, 2012 4:02 AM
                  > To: fc-solve-discuss@yahoogroups.com
                  > Cc: gary@...
                  > Subject: Re: Usable Solution vs. Any Solution
                  >
                  > Hi Gary,
                  >
                  > 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.
                  > -----------------------
                  > RESPONSE: Your example above would be more understandable if along
                  > with the layout, there were some indication of the Game # and the moves
                  > that got to that position.

                  As noted in the pipeline the game number is 24, and I omitted the rest of the
                  solution, to reduce the length of the message, which is expected to remain the
                  same for the version of fc-solve.

                  Otherwise, I should note that:

                  1. fc-solve accepts any arbitrary layout as input, including those not in the
                  Microsoft Freecell deals, and those in mid-play.

                  2. It does not have a built-in way to generate the MS Freecell deals on its own
                  (some of the freecell-solver-* range solvers do, however).

                  3. It always displays the initial board as the first board in the solution (at
                  least if it's not move-only).

                  4. Displaying that will be against the UNIX Philosophy (see
                  http://www.catb.org/esr/writings/taoup/ ) which specifies that "a program
                  should do one thing and do it well". It won't be hard to create a program that
                  will combine all the information in the deal number and the parseable solution
                  in a good way, but what do you do if you don't know the deal number or it
                  isn't valid (like if it's a PySol deal , a PySolFC deal or something else
                  entirely?) ? Oops...

                  > My philosophy has always been that a little extra effort should be made by
                  > the software engineer to accommodate the user. That’s why I advocate
                  > columns rather than rows.

                  Well, I believe in that too, but you're essentially describing the contrast
                  between the UNIX culture and the Windows culture:

                  http://www.joelonsoftware.com/articles/Biculturalism.html

                  That put aside, as an experienced user of the UNIX command-line, I found your
                  solver to be quite counter intuitive and user hostile. I could not even figure
                  it out from the documentation without your help (it just told me to use the
                  GUI, which I wanted to avoid).

                  In any case, regarding the "putting stacks in columns" representation - this is
                  easy to generate using a short Perl / Python / etc. program based on a
                  representation that is easy to parse.

                  > ------------------------
                  > >
                  > > 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?
                  > -----------------------
                  > RESPONSE:
                  > The extra columns (I thought my explanation made it clear, but I guess not)
                  > are for the top cards of the home cells (first row) and the cards in the
                  > freecells (second row). These two sets of 4 cards are appended to the first
                  > to rows of cards in the 8 stacks. A better notation might be like yours, to
                  > put them onto an initial line of their own.

                  True.

                  Well, I have not read the entire explanation. Mea Culpa. Another Joel on
                  Software link of relevance is:

                  http://www.joelonsoftware.com/uibook/chapters/fog0000000062.html

                  Namely:

                  <<<<<
                  When you design user interfaces, it's a good idea to keep two principles in
                  mind:

                  1. Users don't have the manual, and if they did, they wouldn't read it.

                  2. In fact, users can't read anything, and if they could, they wouldn't want
                  to.
                  >>>>>

                  >
                  > The curly braces (see original text, just below) enclose parameters
                  > to FFA to allow it to reset some needed internal variables. They are not
                  > part of the notation, and do not need to be included for my Solver to parse
                  > the layout.

                  I see.

                  >
                  > The [27] is simply one of the moves of the solution. It is the next move.
                  > The move that continues from the given layout.

                  OK.

                  > ---------------------
                  > 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.
                  > -------------------------
                  > RESPONSE: Everything requires an explanation to parse. Are the faults
                  > it suffers from related to ease of parsing? If not, perhaps you could use
                  > the example and indicate its faults explicitly.

                  Read my original reply. Some of the faults involve implicit automoves, and
                  "supermoves"/column-moves without an indication of the number of cards.

                  Regards,

                  Shlomi Fish

                  --
                  -----------------------------------------------------------------
                  Shlomi Fish http://www.shlomifish.org/
                  UNIX Fortune Cookies - http://www.shlomifish.org/humour/fortunes/

                  mplayer 0.9.999.2010.03.11-rc5-adc83b19e793491b1c6ea0fd8b46cd9f32e592fc is
                  now available for download.
                  — Shlomi Fish and d3x.

                  Please reply to list if it's a mailing list post - http://shlom.in/reply .
                • Gary Campbell
                  Since this came through in HTML, I’ll use red for my comments. -Gary ... As noted in the pipeline the game number is 24, and I omitted the rest of the
                  Message 8 of 28 , Nov 29, 2012
                  View Source
                  • 0 Attachment
                    Since this came through in HTML, I’ll use red for my comments.
                     
                    -Gary
                     
                    > From: Shlomi Fish
                    > Sent: Thursday, November 29, 2012 4:02 AM
                    > To:
                    mailto:fc-solve-discuss%40yahoogroups.com
                    > Cc: mailto:gary%40numin8r.us
                    > Subject: Re: Usable Solution vs. Any Solution
                    >
                    > Hi
                    Gary,
                    >
                    > 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:
                    >
                    >
                    href="http://en.wikipedia.org/wiki/Regular_expression">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.
                    >
                    -----------------------
                    > RESPONSE: Your example above would be more
                    understandable if along
                    > with the layout, there were some indication of
                    the Game # and the moves
                    > that got to that position.

                    As noted in the pipeline the game number is 24, and I omitted the rest of the
                    solution, to reduce the length of the message, which is expected to remain the
                    same for the version of fc-solve.
                    I tried #24, but I must have been fooled by the fact that your layout is missing
                    column 4, originally headed by the 5D.  I guess you squeeze out any empty
                    columns, but I wasn’t ready for that.  Mine leaves empty columns and freecells
                    blank to avoid confusion.

                    Otherwise, I should note that:

                    1. fc-solve accepts any arbitrary layout as input, including those not in the
                    Microsoft Freecell deals, and those in mid-play.
                    Yes, of course, so does FFA and my Solver.

                    2. It does not have a built-in way to generate the MS Freecell deals on its own
                    (some of the freecell-solver-* range solvers do, however).
                    Including FFA and my Solver.

                    3. It always displays the initial board as the first board in the solution (at
                    least if it's not move-only).
                    FFA and my Solver can input or display any position (+a move in brackets)
                    and either step forward or backward from that position.

                    4. Displaying that will be against the UNIX Philosophy (see
                    http://www.catb.org/esr/writings/taoup/ ) which specifies that "a program
                    should do one thing and do it well". It won't be hard to create a program that
                    I’m not sure what you are referring to here, but I don’t see a Freecell Solver as
                    being like a Unix utility.  It’s more like a word processor, it has to do a lot of
                    things and integrate them well.
                    will combine all the information in the deal number and the parseable solution
                    in a good way, but what do you do if you don't know the deal number or it
                    isn't valid (like if it's a PySol deal , a PySolFC deal or something else
                    entirely?) ? Oops...  If there’s no deal number, you use a layout to begin with.

                    > My philosophy has always been that a little extra
                    effort should be made by
                    > the software engineer to accommodate the user.
                    That’s why I advocate
                    > columns rather than rows.

                    Well, I believe in that too, but you're essentially describing the contrast
                    between the UNIX culture and the Windows culture:  I think I’m referring
                    to the Freecell culture, which I don’t think should be married to either of
                    the computers (although it does seem the more natural platform is Windows,
                    since that’s where it grew up).

                    http://www.joelonsoftware.com/articles/Biculturalism.html

                    That put aside, as an experienced user of the UNIX command-line, I found your
                    solver to be quite counter intuitive and user hostile. I could not even figure
                    it out from the documentation without your help (it just told me to use the
                    GUI, which I wanted to avoid).  Sorry about that.  Others have had a lot more
                    success, and without specifics, I’m not sure where your problem is coming from.

                    In any case, regarding the "putting stacks in columns" representation - this is
                    easy to generate using a short Perl / Python / etc. program based on a
                    representation that is easy to parse.

                    > ------------------------
                    > >
                    > > 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?
                    > -----------------------
                    >
                    RESPONSE:
                    > The extra columns (I thought my explanation made it clear,
                    but I guess not)
                    > are for the top cards of the home cells (first row) and
                    the cards in the
                    > freecells (second row). These two sets of 4 cards are
                    appended to the first
                    > to rows of cards in the 8 stacks. A better
                    notation might be like yours, to
                    > put them onto an initial line of their
                    own.

                    True.

                    Well, I have not read the entire explanation. Mea Culpa. Another Joel on
                    Software link of relevance is:

                    http://www.joelonsoftware.com/uibook/chapters/fog0000000062.html

                    Namely:

                    <<<<<
                    When you design user interfaces, it's a good idea to keep two principles in
                    mind:

                    1. Users don't have the manual, and if they did, they wouldn't read it.

                    2. In fact, users can't read anything, and if they could, they wouldn't want
                    to.
                    >>>>>
                    FFA is my user interface, and since it’s the GUI, you won’t use it.
                    However, a software engineer always has to read the API manual, and
                    my interface was designed for communication with something like FFA.
                    It is also easy to invoke manually from a DOS window, as I designed it.
                    Since I’ve used quite a few command line interfaces, and don’t think
                    Unix is very user friendly compared to the wider world, I don’t think it’s
                    the best thing to base a standard on.

                    >
                    > The curly braces (see original text, just below)
                    enclose parameters
                    > to FFA to allow it to reset some needed internal
                    variables. They are not
                    > part of the notation, and do not need to be
                    included for my Solver to parse
                    > the layout.

                    I see.

                    >
                    > The [27] is simply one of the moves of the solution. It is the next
                    move.
                    > The move that continues from the given
                    layout.

                    OK.

                    > ---------------------
                    > 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.
                    > -------------------------
                    > RESPONSE: Everything
                    requires an explanation to parse. Are the faults
                    > it suffers from related
                    to ease of parsing? If not, perhaps you could use
                    > the example and
                    indicate its faults explicitly.

                    Read my original reply. Some of the faults involve implicit automoves, and
                    "supermoves"/column-moves without an indication of the number of cards.
                    Read the other thread (Danny J & Michael K).  I think with only one acceptable
                    definition of a Super Move and only two types of Automoves, you can probably
                    adjust.  Clearly, move notation needs to know which type of Automove is used.
                     
                    Any Supermove targeting an occupied column is unambiguous if it doesn’t
                    exceed the legal move length.  If it targets an empty column, it has two forms:
                    Move a single card, or move the maximum legal number of cards.  The
                    version involving a single card is only necessary when all the free cells are
                    full and there are two or more columns.  Such instances are extremely rare,
                    but the zero-freecell version of game #1003256 does require this to solve it.
                    I don’t think any of the 4-freecell games in the 1st 100 million do, however.
                     

                    Regards,

                    Shlomi Fish

                    --
                    ----------------------------------------------------------
                    Shlomi Fish http://www.shlomifish.org/
                    UNIX Fortune Cookies - http://www.shlomifish.org/humour/fortunes/

                    mplayer 0.9.999.2010.03.11-rc5-adc83b19e793491b1c6ea0fd8b46cd9f32e592fc is
                    now available for download.
                    — Shlomi Fish and d3x.

                    Please reply to list if it's a mailing list post - http://shlom.in/reply .
                  • dannyjones183
                    Well, things sure have changed since I started this thread on constructive suggestions to help Shlomi Fish get shorter/useful solutions from his solver. 1)
                    Message 9 of 28 , Nov 29, 2012
                    View Source
                    • 0 Attachment
                      Well, things sure have changed since I started this thread on constructive suggestions to help Shlomi Fish get shorter/useful solutions from his solver.

                      1) Originally, all I needed was the Freecell deal number and a list of non-auto moves for its solution. We agreed on deal #6240 and he supplied a solution. I discovered that two of his moves were Horne automoves, but was able to proceed without them and I made a couple of suggestions on how he might get a shorter/useful solution through a couple of simple constraints in his Pass_1 logic. Those suggestions were lost in the cyber vapor when the topic was side-tracked to discussing various automove options, their properties, and how to identify/generate them.

                      2) The discussion of automove options then evolved into a discussion on the "standard notation" for moves ... and the lack of any standard for describing the card table. Everyone presented their layout formats and opinions. Shlomi Fish presented an interchange format for any generic solitaire card game.

                      3) The move count is only for "bragging rights" and contributes nothing to the solution of a puzzle. Use whatever value makes you happy.

                      4) Now, I'm left sorting through all of the comments and suggestions presented recently. I've shelved any idea of presenting further suggestions on shorter/useful solutions.

                      Regards, Danny A. Jones


                      FWIW: Here's the input that I used with my Convert program for (1) above. I appended a period (.) to the standard notation for the single card moves, and I appended an underscore (_) to the standard notation for the multi-card moves.

                      #00006240 Attempt: 1 NumFcs=4 (ShlomiFish) 173 moves
                      4a. 4b. 1c. 14. 45. 8d. 83. 2h. 63. a8.
                      54. 13. 6a. c6. 45. 61_ 85_ 58. 54_ 6c.
                      61. 84. a6. 8a. 1h. d8. 68. 6d. 45_ b6.
                      2b. 26. 42. 64. 24. 26. d2. 27_ 46. 56_
                      87. 8d. c8. 18. 12_ 1c. 17. 54. 82. 51.
                      b5. 64_ 8b. d8. 78_ 75_ 85_ 8d. b8. 7b.
                      78. 7h. 71. b7. 46_ 81_ d8. 58_ 48_ 43.
                      57_ 5b. 5d.
                                  6h. 2h. 6h. 2h. 6h.
                      56. 45. c4. 34_ 6c. 16. 1h. 12. 1h. 15.
                      43_ d1. b1. 53. 8d. 8h. 71_ 54_ a5. 17_
                      1b. 1a. d1. 23_ 2d. b2. 1b. d1. 72_ 6d.
                      a6. 27_ 26. c2. 34_ 6a. 6c. a6. 2a. c2.
                      8c. 8h. 3h. 87. 8h. c8. 31_ 5c. 62. b5.
                      a6. 13_ 72_ 7b. 31_ 8a. b7. c8. 13_ 1b.
                      27_ a1. 5c. 72_ d5. 6a. 43_ b6. 5d. 46_
                      c5. 36_ d4. 1b. 3c. 3h. 7h. 27_ b1. 4d.
                      72_ 3b. 3h. c4. 1c. 31. 3h. c3. 4c. b1.
                      6b. 6h. c4. 32_ 3c.


                      FWIW: Here's the annotated output from my Convert program. Only the initial layout and the layouts around move 73 are included. I use double-asterisk (**) to signify an empty cell. Because the tableau is presented in row-wise format, a blank line signifies the end of the tableau information. Note: I don't currently identify WKR automoves. (Primarily, my Convert program has evolved into a diagnostic aide.)

                      #00006240 Attempt: 1 NumFcs=4 (ShlomiFish) 173 moves

                      ============================== Depth  3
                      ** ** ** ** *C *D *S *H        freecells & foundation
                                                     row-wise:
                      8S QS 9C 9H TS TH KS AD
                      8D 7H AS 2C 2S 3D 6S 3S
                      JH JC JS 9D AC 5H 4H 3C
                      6C 6D 8H 7S KC 5D 4S 2H
                      TC 6H 8C 5C 7D 9S QD QC
                      4D QH KH 7C 5S JD AH TD
                      4C 3H KD 2D ** ** ** **

                       7  7  7  7  6  6  6  6  count
                       1  1  1  1  1  1  1  1  chain

                      Efree = 4; Ecolm = 0, MoveCount = 0


                      (a):  move sequence number
                      (b):  move in daj-extended standard notation
                      (c):  highest-valued card being moved, a multi-card move has a (+)
                      (d):  target card, ec = empty column, fc = freecell

                      (a)   (b)   (c)  (d)
                      ---   ---   ---  ---   sort: (a)

                        1   4a.   2D   fc
                      ___   7h.   AH   *H   Horne automove
                        2   4b.   7C   fc
                        3   1c.   4C   fc
                        4   14.   4D   5C
                        5   45.   4D   5S
                        6   8d.   TD   fc
                        7   83.   QC   KD
                      ___   8h.   2H   AH   Horne automove
                        8   2h.   3H   2H
                        9   63.   JD   QC
                       10   a8.   2D   3C
                       11   54.   4D   5C
                       12   13.   TC   JD
                       13   6a.   9S   fc
                       14   c6.   4C   5D
                       15   45.   4D   5S
                       16   61_   5D+  6C
                       17   85_   3C+  4D
                       18   58.   2D   3S
                       19   54_   4D+  5C
                       20   6c.   5H   fc
                       21   61.   3D   4C
                       22   84.   2D   3C
                       23   a6.   9S   TH
                       24   8a.   3S   fc
                      ___   8h.   AD   *D   Horne automove
                      ___   4h.   2D   AD   Horne automove
                       25   1h.   3D   2D
                       26   d8.   TD   ec
                       27   68.   9S   TD
                       28   6d.   TH   fc
                       29   45_   4D+  5S
                       30   b6.   7C   ec
                       31   2b.   QH   fc
                       32   26.   6H   7C
                       33   42.   5C   6D
                       34   64.   6H   7S
                       35   24.   5C   6H
                       36   26.   6D   7C
                       37   d2.   TH   JC
                       38   27_   JC+  QD
                       39   46.   5C   6D
                       40   56_   4D+  5C
                       41   87.   9S   TH
                       42   8d.   TD   fc
                       43   c8.   5H   ec
                       44   18.   4C   5H
                       45   12_   6C+  7H
                       46   1c.   JH   fc
                       47   17.   8D   9S
                       48   54.   5S   6H
                       49   82.   4C   5D
                       50   51.   7D   8S
                       51   b5.   QH   KC
                       52   64_   4D+  5S
                       53   8b.   5H   fc
                       54   d8.   TD   ec
                       55   78_   9S+  TD
                       56   75_   JC+  QH
                       57   85_   9S+  TH
                       58   8d.   TD   fc
                       59   b8.   5H   ec
                       60   7b.   QD   fc
                       61   78.   4S   5H
                       62   7h.   4H   3H
                       63   71.   6S   7D
                       64   b7.   QD   KS
                       65   46_   4D+  5C
                       66   81_   5H+  6S
                       67   d8.   TD   ec
                       68   58_   9S+  TD
                       69   48_   7S+  8D
                       70   43.   9D   TC
                       71   57_   JC+  QD
                       72   5b.   QH   fc

                      ============================== Depth  3
                      3S QH JH ** *C 3D *S 4H        freecells & foundation
                                                     row-wise:
                      8S QS 9C 9H TS 7C KS TD
                      7D 7H AS 2C 2S 6D QD 9S
                      6S 6C JS ** AC 5C JC 8D
                      5H 5D 8H ** KC 4D TH 7S
                      4S 4C 8C ** ** 3C ** 6H
                      ** ** KH ** ** ** ** 5S
                      ** ** KD ** ** ** ** **
                      ** ** QC ** ** ** ** **
                      ** ** JD ** ** ** ** **
                      ** ** TC ** ** ** ** **
                      ** ** 9D ** ** ** ** **

                       5  5 11  2  4  5  4  6  count
                       5  4  5  1  1  5  4  6  chain

                      Efree = 1; Ecolm = 0, MoveCount = 72

                       73   5d.   KC   fc
                      ___   5h.   AC   *C   Horne automove
                      ___   4h.   2C   AC   Horne automove
                      ___   6h.   3C   2C   Horne automove
                      ___   2h.   4C   3C   Horne automove

                      ============================== Depth  3
                      3S QH JH KC 4C 3D *S 4H        freecells & foundation
                                                     row-wise:
                      8S QS 9C 9H TS 7C KS TD
                      7D 7H AS ** 2S 6D QD 9S
                      6S 6C JS ** ** 5C JC 8D
                      5H 5D 8H ** ** 4D TH 7S
                      4S ** 8C ** ** ** ** 6H
                      ** ** KH ** ** ** ** 5S
                      ** ** KD ** ** ** ** **
                      ** ** QC ** ** ** ** **
                      ** ** JD ** ** ** ** **
                      ** ** TC ** ** ** ** **
                      ** ** 9D ** ** ** ** **

                       5  4 11  1  2  4  4  6  count
                       5  3  5  1  1  4  4  6  chain

                      Efree = 0; Ecolm = 0, MoveCount = 73

                       74   6h.   4D   3D
                      ___   6h.   5C   4C   Horne automove
                       75   2h.   5D   4D
                       76   6h.   6D   5D
                       77   2h.   6C   5C
                       78   6h.   7C   6C
                       79   56.   2S   ec
                       80   45.   9H   TS
                       81   c4.   JH   ec
                       82   34_   TC+  JH
                       83   6c.   2S   fc
                       84   16.   4S   ec
                       85   1h.   5H   4H
                       86   12.   6S   7H
                       87   1h.   7D   6D
                       88   15.   8S   9H
                       89   43_   TC+  JD
                       90   d1.   KC   ec
                       91   b1.   QH   KC
                       92   53.   8S   9D
                       93   8d.   5S   fc
                       94   8h.   6H   5H
                       95   71_   JC+  QH
                       96   54_   TS+  JH
                       97   a5.   3S   ec
                       98   17_   JC+  QD
                       99   1b.   QH   fc
                      100   1a.   KC   fc
                      101   d1.   5S   ec
                      102   23_   7H+  8S
                      103   2d.   QS   fc
                      104   b2.   QH   ec
                      105   1b.   5S   fc
                      106   d1.   QS   ec
                      107   72_   JC+  QH
                      108   6d.   4S   fc
                      109   a6.   KC   ec
                      110   27_   JC+  QD
                      111   26.   QH   KC
                      112   c2.   2S   ec
                      113   34_   8S+  9H
                      114   6a.   QH   fc
                      115   6c.   KC   fc
                      116   a6.   QH   ec
                      117   2a.   2S   fc
                      118   c2.   KC   ec
                      119   8c.   7S   fc
                      120   8h.   8D   7D
                      121   3h.   9D   8D
                      122   87.   9S   TH
                      123   8h.   TD   9D
                      124   c8.   7S   ec
                      125   31_   JD+  QS
                      126   5c.   3S   fc
                      127   62.   QH   KC
                      128   b5.   5S   ec
                      129   a6.   2S   ec
                      130   13_   JD+  QC
                      131   72_   JC+  QH
                      132   7b.   QD   fc
                      133   31_   JD+  QS
                      134   8a.   7S   fc
                      135   b7.   QD   KS
                      136   c8.   3S   ec
                      137   13_   JD+  QC
                      138   1b.   QS   fc
                      139   27_   JC+  QD
                      140   a1.   7S   ec
                      141   5c.   5S   fc
                      142   72_   JC+  QH
                      143   d5.   4S   ec
                      144   6a.   2S   fc
                      145   43_   9H+  TC
                      146   b6.   QS   ec
                      147   5d.   4S   fc
                      148   46_   JH+  QS
                      149   c5.   5S   ec
                      150   36_   9H+  TS
                      151   d4.   4S   ec
                      152   1b.   7S   fc
                      153   3c.   TC   fc
                      154   3h.   JD   TD
                      155   7h.   QD   JD
                      156   27_   QH+  KS
                      157   b1.   7S   ec
                      158   4d.   4S   fc
                      159   72_   QH+  KC
                      160   3b.   QC   fc
                      161   3h.   KD   QD
                      162   c4.   TC   ec
                      163   1c.   7S   fc
                      164   31.   KH   ec
                      165   3h.   8C   7C
                      166   c3.   7S   8H
                      167   4c.   TC   fc
                      168   b1.   QC   KH
                      169   6b.   6S   fc
                      170   6h.   7H   6H
                      171   c4.   TC   ec
                      172   32_   8H+  9S
                      173   3c.   JS   fc
                      ___   3h.   AS   *S   Horne automove
                      ___   ah.   2S   AS   Horne automove
                      ___   8h.   3S   2S   Horne automove
                      ___   dh.   4S   3S   Horne automove
                      ___   5h.   5S   4S   Horne automove
                      ___   bh.   6S   5S   Horne automove
                      ___   2h.   7S   6S   Horne automove
                      ___   6h.   8S   7S   Horne automove
                      ___   2h.   8H   7H   Horne automove
                      ___   3h.   9C   8C   Horne automove
                      ___   6h.   9H   8H   Horne automove
                      ___   2h.   9S   8S   Horne automove
                      ___   4h.   TC   9C   Horne automove
                      ___   6h.   TS   9S   Horne automove
                      ___   2h.   TH   9H   Horne automove
                      ___   6h.   JH   TH   Horne automove
                      ___   ch.   JS   TS   Horne automove
                      ___   2h.   JC   TC   Horne automove
                      ___   6h.   QS   JS   Horne automove
                      ___   1h.   QC   JC   Horne automove
                      ___   2h.   QH   JH   Horne automove
                      ___   7h.   KS   QS   Horne automove
                      ___   1h.   KH   QH   Horne automove
                      ___   2h.   KC   QC   Horne automove
                      ~~~~~


                    • Shlomi Fish
                      Hi Gary, On Thu, 29 Nov 2012 13:57:50 -0800 ... Please: 1. Avoid sending HTML-only E-mail to this list. 2. Make sure your E-mails are properly formatted in
                      Message 10 of 28 , Nov 30, 2012
                      View Source
                      • 0 Attachment
                        Hi Gary,

                        On Thu, 29 Nov 2012 13:57:50 -0800
                        "Gary Campbell" <gary@...> wrote:

                        > Since this came through in HTML, I’ll use red for my comments.
                        > -Gary

                        Please:

                        1. Avoid sending HTML-only E-mail to this list.

                        2. Make sure your E-mails are properly formatted in plain-text version (while
                        using bottom posting instead of top-posting and properly quoting previous
                        discussions using "> ". See:

                        http://en.wikipedia.org/wiki/Posting_style

                        That goes for Danny, too.

                        HTML E-mail has several major problems. See:

                        * http://mail.perl.org.il/pipermail/perl/2010-May/010995.html

                        The HTML handling of my Mail User Agent ( http://www.claws-mail.org/ ) only
                        displays a small subset of the HTML formatting, at least by default, possibly
                        due to security reasons (see
                        http://developers.slashdot.org/story/10/09/17/1740247/security-a-concern-as-html5-advances
                        ), so I find many HTML messages to be unreadable.

                        If possible, please resend your message as text, without red text or other
                        funny stuff.

                        Regards,

                        Shlomi Fish

                        --
                        -----------------------------------------------------------------
                        Shlomi Fish http://www.shlomifish.org/
                        "Humanity" - Parody of Modern Life - http://shlom.in/humanity

                        A wiseman can learn from a fool much more than a fool can ever learn from a
                        wiseman. — http://en.wikiquote.org/wiki/Cato_the_Elder

                        Please reply to list if it's a mailing list post - http://shlom.in/reply .
                      • Shlomi Fish
                        Hi Danny, On Thu, 29 Nov 2012 23:52:42 -0000 ... Just for the record, here is the solution that ./freecell-solver-fc-pro-range-solve currently generates (again
                        Message 11 of 28 , Nov 30, 2012
                        View Source
                        • 0 Attachment
                          Hi Danny,

                          On Thu, 29 Nov 2012 23:52:42 -0000
                          "dannyjones183" <dannyjones183@...> wrote:

                          > Well, things sure have changed since I started this thread on
                          > constructive suggestions to help Shlomi Fish get shorter/useful
                          > solutions from his solver.
                          >
                          > 1) Originally, all I needed was the Freecell deal number and a list of
                          > non-auto moves for its solution. We agreed on deal #6240 and he supplied
                          > a solution. I discovered that two of his moves were Horne automoves, but
                          > was able to proceed without them and I made a couple of suggestions on
                          > how he might get a shorter/useful solution through a couple of simple
                          > constraints in his Pass_1 logic. Those suggestions were lost in the
                          > cyber vapor when the topic was side-tracked to discussing various
                          > automove options, their properties, and how to identify/generate them.
                          >

                          Just for the record, here is the solution
                          that ./freecell-solver-fc-pro-range-solve currently generates (again with my
                          own heuristic of automoves):

                          <<<<<<<<<<<<<<<
                          shlomif[fcs]:$trunk/fc-solve/source/B$ ./freecell-solver-fc-pro-range-solve
                          6240 6240 1 --read-from-file
                          4,/home/shlomif/progs/freecell/git/fc-solve/fc-solve/source/Presets/testing-presets/mfi-with-2-more-scans.sh -fif 10 --flares-choice fcpro --cache-limit 100000
                          Started at 1354272030.489860
                          [[Num Iters]]=1439064
                          [[Num FCS Moves]]=96
                          [[Num FCPro Moves]]=56
                          [[Start]]
                          8a 8b 2h 8c 8d b3 63 1b 18 13
                          85 d5 6d 68 61 6h b1 5b 5h 8h
                          28 24 2h 54 5h 62 d2 85 36v4 3d
                          38 32 35 a5 35 57 53v2 42 4a 4b
                          45 1c 1h 1a 1h 5h 45 74 7h 85
                          68 6h a6 7a 7h 23
                          [[End]]
                          Reached Board No. 6240 at 1354272039.679491 (total_num_iters=1439064)
                          >>>>>>>>>>>>>>>

                          Note that it takes a while to generate (which may be mitigated, at the expense
                          of a possibly longer solution, if I specify a lower -fif parameter). I tested
                          it now and -fif 5 seems to generate an identical solution. -fif 3 on the other
                          hand generates a longer one:

                          <<<<<<<<<<
                          shlomif[fcs]:$trunk/fc-solve/source/B$ ./freecell-solver-fc-pro-range-solve
                          6240 6240 1 --read-from-file 4,/home/shlomif/progs/freecell/git/fc-solve/fc-solve/source/Presets/testing-presets/mfi-with-2-more-scans.sh -fif 3 --flares-choice fcpro --cache-limit 100000
                          Started at 1354272234.024434
                          [[Num Iters]]=603627
                          [[Num FCS Moves]]=108
                          [[Num FCPro Moves]]=68
                          [[Start]]
                          5a 5b 5c 8d 83 52 56 c5 2c 2h
                          48 25 24 a4 63 2a 25 d5 65 7d
                          76 7h 72 d7 62 6h 4d 4h 62 c2
                          6c 16 a4 81 8a 26 b8 d4 28 2h
                          7b 68 32 6d b7 36v2 26 2b 32 b2
                          3b 3h 37 1a 1h 8h 4h 8h 4h 8h
                          48 c7 4c 4h 41 1a 1d 12
                          [[End]]
                          Reached Board No. 6240 at 1354272237.394971 (total_num_iters=603627)
                          >>>>>>>>>>

                          Naturally, I am still interested to see if I can generate shorter solutions
                          without increasing the run-time too much. This may be doable to a large extent,
                          but I guess eventually, I cannot have my cake and eat it too.

                          Regards,

                          -- Shlomi Fish

                          --
                          -----------------------------------------------------------------
                          Shlomi Fish http://www.shlomifish.org/
                          "Humanity" - Parody of Modern Life - http://shlom.in/humanity

                          Knuth is not God! God has already released TeX version 4.0.

                          Please reply to list if it's a mailing list post - http://shlom.in/reply .
                        • Gary Campbell
                          Getting back to shorter solutions..... From: Shlomi Fish Sent: Friday, November 30, 2012 2:46 AM To: fc-solve-discuss@yahoogroups.com Cc:
                          Message 12 of 28 , Nov 30, 2012
                          View Source
                          • 0 Attachment
                            Getting back to shorter solutions.....

                            From: Shlomi Fish
                            Sent: Friday, November 30, 2012 2:46 AM
                            To: fc-solve-discuss@yahoogroups.com
                            Cc: dannyjones183@...
                            Subject: Re: Usable Solution vs. Any Solution


                            Just for the record, here is the solution
                            that ./freecell-solver-fc-pro-range-solve currently generates (again with my
                            own heuristic of automoves):

                            <<<<<<<<<<<<<<<
                            shlomif[fcs]:$trunk/fc-solve/source/B$ ./freecell-solver-fc-pro-range-solve
                            6240 6240 1 --read-from-file
                            4,/home/shlomif/progs/freecell/git/fc-solve/fc-solve/source/Presets/testing-presets/mfi-with-2-more-scans.sh
                            -fif 10 --flares-choice fcpro --cache-limit 100000
                            Started at 1354272030.489860
                            [[Num Iters]]=1439064
                            [[Num FCS Moves]]=96
                            [[Num FCPro Moves]]=56
                            [[Start]]
                            8a 8b 2h 8c 8d b3 63 1b 18 13
                            85 d5 6d 68 61 6h b1 5b 5h 8h
                            28 24 2h 54 5h 62 d2 85 36v4 3d
                            38 32 35 a5 35 57 53v2 42 4a 4b
                            45 1c 1h 1a 1h 5h 45 74 7h 85
                            68 6h a6 7a 7h 23
                            [[End]]
                            Reached Board No. 6240 at 1354272039.679491 (total_num_iters=1439064)
                            >>>>>>>>>>>>>>>

                            RESPONSE:
                            One of the most powerful components of a solver is how well it sorts moves.
                            Pruning is very important, but of the two strategies, sorting is the key.
                            For example, my current version also solves #6240 in 56 steps (but with a
                            very different solution). It took 928 iterations (moves investigated) with
                            109 backups. On the average, it solves games in under 50 steps, and about
                            40% of them with no backup at all. I believe this is due to choosing a good
                            move at each step.

                            One of the things I noted in Shlomi's solution was that card->home moves
                            were given too high a priority (my current solver suffers from this as well,
                            but maybe to a lesser extent). I can reduce my solution to 51 steps, and
                            Shlomi's to 47 steps by avoiding unnecessary card->home moves using
                            the heuristic mentioned below.

                            I've found that giving a high priority to moves that attempt to expose a
                            WKR automove is a good heuristic for shorter solutions. I noted that the
                            two non-Horne automoves in Shlomi's solution were WKR.

                            -Gary Campbell
                          • dannyjones183
                            Hmmm. First off, I believe that Gary was reporting that he was on the receiving end of an HTML formatted message from you. Second, I don t ever recall sending
                            Message 13 of 28 , Nov 30, 2012
                            View Source
                            • 0 Attachment
                              Hmmm.

                              First off, I believe that Gary was reporting that he was on the receiving end of an HTML formatted message from you.

                              Second, I don't ever recall sending E-mail to you ... and I don't use HTML, period.

                              Time to start investigating your own home ... so to speak.

                              --- In fc-solve-discuss@yahoogroups.com, Shlomi Fish <shlomif@...> wrote:
                              >
                              > Hi Gary,
                              >
                              > On Thu, 29 Nov 2012 13:57:50 -0800
                              > "Gary Campbell" <gary@...> wrote:
                              >
                              > > Since this came through in HTML, I’ll use red for my comments.
                              > > -Gary
                              >
                              > Please:
                              >
                              > 1. Avoid sending HTML-only E-mail to this list.
                              >
                              > 2. Make sure your E-mails are properly formatted in plain-text version
                              >
                              > That goes for Danny, too.
                              >
                            • dannyjones183
                              A solution of 56 direct moves, plus three WKR automoves, seems reasonable to me. As you said, it came at the expense of a longer execution time. That s
                              Message 14 of 28 , Nov 30, 2012
                              View Source
                              • 0 Attachment
                                A solution of 56 direct moves, plus three WKR automoves, seems reasonable to me. As you said, it came at the expense of a longer execution time. That's acceptable if you are finding solutions for just a few deals.

                                In a previous message, I mentioned two constraints that could be applied to your Pass_1 logic with (hopefully) little effort. They should help reduce the execution time and move counts no matter which other run-time options you employ. In particular, they should help your range processing of 1,000,000 deals.

                                I have a few more suggestions, but they may be more difficult to implement. First, I'd like to know if my original suggestions seem to help.

                                Regards, Danny


                                --- In fc-solve-discuss@yahoogroups.com, Shlomi Fish <shlomif@...> wrote:
                                >
                                > Just for the record, here is the solution
                                > that ./freecell-solver-fc-pro-range-solve currently generates (again with my
                                > own heuristic of automoves):
                                >
                                > <<<<<<<<<<<<<<<
                                > shlomif[fcs]:$trunk/fc-solve/source/B$ ./freecell-solver-fc-pro-range-solve
                                > 6240 6240 1 --read-from-file
                                > 4,/home/shlomif/progs/freecell/git/fc-solve/fc-solve/source/Presets/testing-presets/mfi-with-2-more-scans.sh -fif 10 --flares-choice fcpro --cache-limit 100000
                                > Started at 1354272030.489860
                                > [[Num Iters]]=1439064
                                > [[Num FCS Moves]]=96
                                > [[Num FCPro Moves]]=56
                                > [[Start]]
                                > 8a 8b 2h 8c 8d b3 63 1b 18 13
                                > 85 d5 6d 68 61 6h b1 5b 5h 8h
                                > 28 24 2h 54 5h 62 d2 85 36v4 3d
                                > 38 32 35 a5 35 57 53v2 42 4a 4b
                                > 45 1c 1h 1a 1h 5h 45 74 7h 85
                                > 68 6h a6 7a 7h 23
                                > [[End]]
                                > Reached Board No. 6240 at 1354272039.679491 (total_num_iters=1439064)
                                > >>>>>>>>>>>>>>>
                                >
                                > Note that it takes a while to generate (which may be mitigated, at the expense
                                > of a possibly longer solution, if I specify a lower -fif parameter). I tested
                                > it now and -fif 5 seems to generate an identical solution. -fif 3 on the other
                                > hand generates a longer one:
                                >
                                >
                                > Naturally, I am still interested to see if I can generate shorter solutions
                                > without increasing the run-time too much. This may be doable to a large extent,
                                > but I guess eventually, I cannot have my cake and eat it too.
                                >
                              • Shlomi Fish
                                Hi Danny, On Sat, 01 Dec 2012 03:40:38 -0000 ... I believe the message had a plaintext part and possibly also an HTML part. Or at least it should have had that
                                Message 15 of 28 , Dec 1, 2012
                                View Source
                                • 0 Attachment
                                  Hi Danny,

                                  On Sat, 01 Dec 2012 03:40:38 -0000
                                  "dannyjones183" <dannyjones183@...> wrote:

                                  > Hmmm.
                                  >
                                  > First off, I believe that Gary was reporting that he was on the receiving end
                                  > of an HTML formatted message from you.

                                  I believe the message had a plaintext part and possibly also an HTML part. Or at
                                  least it should have had that because I only edit those in plaintext. Various
                                  E-mailer user agents (MUAs) have various preferences for doing that, and
                                  Microsoft Outlook was especially notorious for doing things wrong in this
                                  respect.

                                  >
                                  > Second, I don't ever recall sending E-mail to you ... and I don't use HTML,
                                  > period.

                                  Ah, OK. What I meant was that you should quote the messages, and reply interim
                                  in accordance to the wikipedia page I posted:

                                  http://en.wikipedia.org/wiki/Posting_style

                                  >
                                  > Time to start investigating your own home ... so to speak.
                                  >

                                  I think Claws-Mail (my email client) handles it fine, but YahooGroups might
                                  mangle some stuff, and different MUAs may be even more offending.

                                  Regards,

                                  Shlomi Fish

                                  --
                                  -----------------------------------------------------------------
                                  Shlomi Fish http://www.shlomifish.org/
                                  Stop Using MSIE - http://www.shlomifish.org/no-ie/

                                  Learn Perl from “Learning Perl in 24 Minutes Unleashed, in a Nutshell for
                                  Dummies.”
                                  — based on Shlomi Fish and f00li5h on #perl

                                  Please reply to list if it's a mailing list post - http://shlom.in/reply .
                                Your message has been successfully submitted and would be delivered to recipients shortly.