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

Request for Comments: spec for the new solution notation standard

Expand Messages
  • Shlomi Fish
    Hi all, in order to get the issue of creating a new standard notation for Freecell and similar variants of Solitaire, I have started working on a new
    Message 1 of 13 , Nov 29, 2012
    View Source
    • 0 Attachment
      Hi all,

      in order to get the issue of creating a new standard notation for Freecell and
      similar variants of Solitaire, I have started working on a new specification
      here:

      https://bitbucket.org/shlomif/fc-solve/src/92006fcecf568af58ee4259e075dfb74e254db9e/fc-solve/docs/new-universal-solitaire-solutions-standard-format-proposal-v0.1.txt?at=master

      (Short URL : http://is.gd/bR542J ).

      You can find the latest version by playing with the controls and send me
      patches, pull requests, etc. (though the size of the fc-solve repository may
      encourage me to split it into a separate repository hosted separately).

      I am including it here below for your comments:

      Note: this is intended primarily as an interchange format where solutions will
      be converted to and from it.

      Regards,

      Shlomi Fish

      ---------------------

      Abstract
      --------

      This is a proposal for a universal format for encoding solitaire solutions.
      It grew out of a discussion on the fc-solve-discuss mailing list based on
      some people's frustration with the so-called “standard notation” for
      notating Freecell.

      This standard is written in a pseudo-BNF / pseudo-C-struct format, which
      will be encoding agnostic and can later be encoded in XML, JSON or a more
      human-readable format (though conversions to this format will be explicitly
      specified.).

      Format:
      -------

      Rank = {Integer: from 0 to MAX_RANK } (MAX_RANK is normally 13 for French
      playing card, but is specified at the header).

      Suit = One Of{'H','C','D','S' }

      Deck = {Integer: from 0 to NUM_DECKS - 1 }

      Card = {
      bool is_empty;
      bool is_hidden;
      Rank rank;
      Suit suit;
      Deck deck; # Optional
      }

      Column = {
      int len;
      Card cards[0 .. len-1];
      }

      Foundation_Id = { Deck deck, Suit suit }

      Foundations = {
      Map : from Foundation_Id to Rank.
      # For all decks and suits
      }

      Freecells = {
      Array of NUM_FREECELLS cards that can be empty.
      }

      GamePosition = {
      Foundations foundations;
      Freecells freecells;

      Column x NUM_COLUMNS;
      }

      Column_Idx = {Integer: from 0 to NUM_COLUMNS-1 }
      Freecell_Idx = {Integer: from 0 to NUM_FREECELLS-1 }

      Source_Or_Dest_Id = union {
      Column_Idx col;
      OR
      Freecell_Idx freecell;
      OR
      Foundation_Id foundation;
      }

      Move = Struct {
      Source_Or_Dest_Id source;
      Source_Or_Dest_Id dest;
      int num_cards; # Where appropriate;
      Card source_card; # Optional
      Card dest_card; # Optional
      bool implicit; # Whether this move is done implicitly by an automove.
      }

      Move_With_Position = Struct {
      GamePosition pos_before_move;
      Move move;
      }

      Solution = {
      Move_With_Position moves[0 .. NUM_MOVES - 1];
      GamePosition final_position;
      }



      Header = {
      int NUM_DECKS;
      int NUM_MOVES;
      int NUM_COLUMNS;
      int MAX_RANK;
      String variant; # such as "freecell", "bakers_dozen", "bakers_game", etc.
      enum sequences_are_built_by {
      RANK, SUIT, ALTERNATE_COLOR
      }
      enum empty_stacks_filled_by {
      KINGS_ONLY, NONE, ANY_CARD,
      }
      enum sequence_move {
      LIMITED, UNLIMITED
      }
      }

      Total = {
      Header header;
      Solution solution;
      }

      --
      -----------------------------------------------------------------
      Shlomi Fish http://www.shlomifish.org/
      Best Introductory Programming Language - http://shlom.in/intro-lang

      Beliefs are what divide people. Doubt unites them.
      http://en.wikiquote.org/wiki/Peter_Ustinov

      Please reply to list if it's a mailing list post - http://shlom.in/reply .
    • Shlomi Fish
      Hi all, in order to get the issue of creating a new standard notation for Freecell and similar variants of Solitaire, I have started working on a new
      Message 2 of 13 , Dec 7, 2012
      View Source
      • 0 Attachment
        Hi all,

        in order to get the issue of creating a new standard notation for Freecell and
        similar variants of Solitaire, I have started working on a new specification
        here:

        https://bitbucket.org/shlomif/fc-solve/src/4687c00c87ff1bed9f6c84b8ce101c0ce35159d0/fc-solve/docs/new-universal-solitaire-solutions-standard-format-proposal-v0.1.txt?at=master

        (Short URL : http://is.gd/tujNNe ).

        You can find the latest version by playing with the controls and send me
        patches, pull requests, etc. (though the size of the fc-solve repository may
        encourage me to split it into a separate repository hosted separately).

        I am including it here below for your comments.

        Note: this is intended primarily as an interchange format where solutions will
        be converted to and from it, and the authors of various solvers may opt to
        adopt a somewhat different format .

        Changes from last time are the inclusion of the optional "comments" for moves.
        I have also noticed that the specification is quite Freecell-centric and that
        some of the assumptions may require adaptations for other types of Patience.

        Also, please voice your comments now before I start working on XML and
        JSON/Perl-5-like data structures representations of this format. Even if this
        proposal seems fine to you as it is, please note it.

        Regards,

        Shlomi Fish

        ---------------------

        Abstract
        --------

        This is a proposal for a universal format for encoding solitaire solutions.
        It grew out of a discussion on the fc-solve-discuss mailing list based on
        some people's frustration with the so-called “standard notation” for
        notating Freecell.

        This standard is written in a pseudo-BNF / pseudo-C-struct format, which
        will be encoding agnostic and can later be encoded in XML, JSON or a more
        human-readable format (though conversions to this format will be explicitly
        specified.).

        Format:
        -------

        Rank = {Integer: from 0 to MAX_RANK } (MAX_RANK is normally 13 for French
        playing card, but is specified at the header).

        Suit = One Of{'H','C','D','S' }

        Deck = {Integer: from 0 to NUM_DECKS - 1 }

        Card = {
        bool is_empty;
        bool is_hidden;
        Rank rank;
        Suit suit;
        Deck deck; # Optional
        }

        Column = {
        int len;
        Card cards[0 .. len-1];
        }

        Foundation_Id = { Deck deck, Suit suit }

        Foundations = {
        Map : from Foundation_Id to Rank.
        # For all decks and suits
        }

        Freecells = {
        Array of NUM_FREECELLS cards that can be empty.
        }

        GamePosition = {
        Foundations foundations;
        Freecells freecells;

        Column x NUM_COLUMNS;
        }

        Column_Idx = {Integer: from 0 to NUM_COLUMNS-1 }
        Freecell_Idx = {Integer: from 0 to NUM_FREECELLS-1 }

        Source_Or_Dest_Id = union {
        Column_Idx col;
        OR
        Freecell_Idx freecell;
        OR
        Foundation_Id foundation;
        }

        Move = Struct {
        Source_Or_Dest_Id source;
        Source_Or_Dest_Id dest;
        int num_cards; # Where appropriate;
        Card source_card; # Optional
        Card dest_card; # Optional
        bool implicit; # Whether this move is done implicitly by an automove.
        }

        Move_With_Position = Struct {
        GamePosition pos_before_move;
        Move move;
        }

        Solution = {
        Move_With_Position moves[0 .. NUM_MOVES - 1];
        GamePosition final_position;
        }



        Header = {
        int NUM_DECKS;
        int NUM_MOVES;
        int NUM_COLUMNS;
        int MAX_RANK;
        String variant; # such as "freecell", "bakers_dozen", "bakers_game", etc.
        enum sequences_are_built_by {
        RANK, SUIT, ALTERNATE_COLOR
        }
        enum empty_stacks_filled_by {
        KINGS_ONLY, NONE, ANY_CARD,
        }
        enum sequence_move {
        LIMITED, UNLIMITED
        }
        }

        Total = {
        Header header;
        Solution solution;
        }

        --
        -----------------------------------------------------------------
        Shlomi Fish http://www.shlomifish.org/
        Best Introductory Programming Language - http://shlom.in/intro-lang

        Beliefs are what divide people. Doubt unites them.
        http://en.wikiquote.org/wiki/Peter_Ustinov

        Please reply to list if it's a mailing list post - http://shlom.in/reply .
      • jgw321
        ... Bravo. ... I think this is a great idea. Trying to introduce/enforce a common standard across all patience games is a herculean task, but an interchange
        Message 3 of 13 , Dec 7, 2012
        View Source
        • 0 Attachment
          On 7 December 2012 11:20, Shlomi Fish <shlomif@...> wrote:
          a new standard notation for Freecell and similar variants of Solitaire, I have started working on a new specification

          Bravo.

          Note: this is intended primarily as an interchange format where solutions will be converted to and from it, and the authors of various solvers may opt to adopt a somewhat different format .

          I think this is a great idea.  Trying to introduce/enforce a common standard across all patience games is a herculean task, but an interchange standard with conversion filters is an excellent solution.

          I have also noticed that the specification is quite Freecell-centric and that
          some of the assumptions may require adaptations for other types of Patience.

          several solitaires are similar enough to freecell that they can be accomplished in this structure, but from memory there are some with strange layouts which may require something extra.  Is anyone going to volunteer to look for problems with other patience games, or would this just hold things up?
           

          --
          Without wishing to offend anyone, check all Urban Myths at http://www.snopes.com/
          but please don't send them to me, I do not forward chain letters.

          JG (this is my name)

        • Shlomi Fish
          Hi jgw321, thanks for your message. On Fri, 7 Dec 2012 12:04:36 +0000 ... Thanks. :-) ... Right. ... Well, the format is designed to be as extensible as
          Message 4 of 13 , Dec 7, 2012
          View Source
          • 0 Attachment
            Hi jgw321,

            thanks for your message.

            On Fri, 7 Dec 2012 12:04:36 +0000
            jgw321 <jgw321@...> wrote:

            > On 7 December 2012 11:20, Shlomi Fish <shlomif@...> wrote:
            >
            > > **
            > > a new standard notation for Freecell and similar variants of Solitaire, I
            > > have started working on a new specification
            > >
            >
            > Bravo.
            >

            Thanks. :-)

            > > Note: this is intended primarily as an interchange format where solutions
            > > will be converted to and from it, and the authors of various solvers may
            > > opt to adopt a somewhat different format .
            > >
            > I think this is a great idea. Trying to introduce/enforce a common
            > standard across all patience games is a herculean task, but an interchange
            > standard with conversion filters is an excellent solution.

            Right.

            >
            > > I have also noticed that the specification is quite Freecell-centric and
            > > that
            > > some of the assumptions may require adaptations for other types of
            > > Patience.
            > >
            > several solitaires are similar enough to freecell that they can be
            > accomplished in this structure, but from memory there are some with strange
            > layouts which may require something extra. Is anyone going to volunteer to
            > look for problems with other patience games, or would this just hold things
            > up?

            Well, the format is designed to be as extensible as possible. That put aside,
            one can use PySolFC ( http://pysolfc.sourceforge.net/ ) and go over the
            individual Solitaire games one by one. There are over a 1,000 of them in
            PySolFC alone, though some of them are either Mahjongg-based or not using the
            French cards, which may both fall out of the scope of the specification. I
            think I once went over the ones in the old PySol looking for games that are
            similar to Freecell, or that didn't have a talon, which makes solving
            using a computer much harder.

            And as you note there are also layout issues. In Baker's Dozen on PySolFC, the
            columns are split into 2 rows with 8 and 7 columns each, while in
            Freecell, the columns are arranged in a single row. Sometimes the "columns"
            can be horizontal, which complicates stuff.

            Regards,

            Shlomi Fish

            --
            -----------------------------------------------------------------
            Shlomi Fish http://www.shlomifish.org/
            Best Introductory Programming Language - http://shlom.in/intro-lang

            Bugs are too afraid to reproduce on Chuck Norris’ computer. As a result, when
            he uses Microsoft Windows, it behaves just like a Linux system.

            Please reply to list if it's a mailing list post - http://shlom.in/reply .
          • dannyjones183
            To me, using pseudo-C forces a constraint that isn t natural. I think all of your {0..N-1} statements should be {1..N}. That way, I would have a clearer idea
            Message 5 of 13 , Dec 7, 2012
            View Source
            • 0 Attachment
              To me, using pseudo-C forces a constraint that isn't natural. I think all of your {0..N-1} statements should be {1..N}. That way, I would have a clearer idea what move "m" from column "col" to freecell "fc" using deck "j" actually means. I don't care if my input/output modules have to do a little extra work. Better them than me!


              --- In fc-solve-discuss@yahoogroups.com, Shlomi Fish <shlomif@...> wrote:
              >
              > Hi all,
              >
              > in order to get the issue of creating a new standard notation for Freecell and
              > similar variants of Solitaire, I have started working on a new specification
              > here:
              >

              <snip>

              > ---------------------
              >
              > Abstract
              > --------
              >
              > This is a proposal for a universal format for encoding solitaire solutions.
              > It grew out of a discussion on the fc-solve-discuss mailing list based on
              > some people's frustration with the so-called “standard notation” for
              > notating Freecell.
              >
              > This standard is written in a pseudo-BNF / pseudo-C-struct format, which
              > will be encoding agnostic and can later be encoded in XML, JSON or a more
              > human-readable format (though conversions to this format will be explicitly
              > specified.).
              >
              > Format:
              > -------
              >
              > Rank = {Integer: from 0 to MAX_RANK } (MAX_RANK is normally 13 for French
              > playing card, but is specified at the header).
              >
              > Suit = One Of{'H','C','D','S' }
              >
              > Deck = {Integer: from 0 to NUM_DECKS - 1 }
              >
              > Card = {
              > bool is_empty;
              > bool is_hidden;
              > Rank rank;
              > Suit suit;
              > Deck deck; # Optional
              > }
              >
              > Column = {
              > int len;
              > Card cards[0 .. len-1];
              > }
              >
              > Foundation_Id = { Deck deck, Suit suit }
              >
              > Foundations = {
              > Map : from Foundation_Id to Rank.
              > # For all decks and suits
              > }
              >
              > Freecells = {
              > Array of NUM_FREECELLS cards that can be empty.
              > }
              >
              > GamePosition = {
              > Foundations foundations;
              > Freecells freecells;
              >
              > Column x NUM_COLUMNS;
              > }
              >
              > Column_Idx = {Integer: from 0 to NUM_COLUMNS-1 }
              > Freecell_Idx = {Integer: from 0 to NUM_FREECELLS-1 }
              >
              > Source_Or_Dest_Id = union {
              > Column_Idx col;
              > OR
              > Freecell_Idx freecell;
              > OR
              > Foundation_Id foundation;
              > }
              >
              > Move = Struct {
              > Source_Or_Dest_Id source;
              > Source_Or_Dest_Id dest;
              > int num_cards; # Where appropriate;
              > Card source_card; # Optional
              > Card dest_card; # Optional
              > bool implicit; # Whether this move is done implicitly by an automove.
              > }
              >
              > Move_With_Position = Struct {
              > GamePosition pos_before_move;
              > Move move;
              > }
              >
              > Solution = {
              > Move_With_Position moves[0 .. NUM_MOVES - 1];
              > GamePosition final_position;
              > }
              >
              >
              >
              > Header = {
              > int NUM_DECKS;
              > int NUM_MOVES;
              > int NUM_COLUMNS;
              > int MAX_RANK;
              > String variant; # such as "freecell", "bakers_dozen", "bakers_game", etc.
              > enum sequences_are_built_by {
              > RANK, SUIT, ALTERNATE_COLOR
              > }
              > enum empty_stacks_filled_by {
              > KINGS_ONLY, NONE, ANY_CARD,
              > }
              > enum sequence_move {
              > LIMITED, UNLIMITED
              > }
              > }
              >
              > Total = {
              > Header header;
              > Solution solution;
              > }
              >
              > --
            • Gary Campbell
              I second the motion! -Gary Campbell From: dannyjones183 Sent: Friday, December 07, 2012 10:44 AM To: fc-solve-discuss@yahoogroups.com Subject: Re: Request
              Message 6 of 13 , Dec 7, 2012
              View Source
              • 0 Attachment
                I second the motion!   -Gary Campbell
                 
                Sent: Friday, December 07, 2012 10:44 AM
                Subject: Re: Request for Comments: spec for the new solution notation standard
                 
                 

                To me, using pseudo-C forces a constraint that isn't natural. I think all of your {0..N-1} statements should be {1..N}. That way, I would have a clearer idea what move "m" from column "col" to freecell "fc" using deck "j" actually means. I don't care if my input/output modules have to do a little extra work. Better them than me!

                --- In mailto:fc-solve-discuss%40yahoogroups.com, Shlomi Fish <shlomif@...> wrote:

                >
                > Hi all,
                >
                >
                in order to get the issue of creating a new standard notation for Freecell and
                > similar variants of Solitaire, I have started working on a new
                specification
                > here:
                >

                <snip>

                >
                ---------------------
                >
                > Abstract
                > --------
                >
                > This is a proposal for a universal format for encoding solitaire
                solutions.
                > It grew out of a discussion on the fc-solve-discuss mailing
                list based on
                > some people's frustration with the so-called “standard
                notation” for
                > notating Freecell.
                >
                > This standard is
                written in a pseudo-BNF / pseudo-C-struct format, which
                > will be encoding
                agnostic and can later be encoded in XML, JSON or a more
                > human-readable
                format (though conversions to this format will be explicitly
                >
                specified.).
                >
                > Format:
                > -------
                >
                > Rank =
                {Integer: from 0 to MAX_RANK } (MAX_RANK is normally 13 for French
                >
                playing card, but is specified at the header).
                >
                > Suit = One
                Of{'H','C','D','S' }
                >
                > Deck = {Integer: from 0 to NUM_DECKS - 1
                }
                >
                > Card = {
                > bool is_empty;
                > bool
                is_hidden;
                > Rank rank;
                > Suit suit;
                > Deck deck; #
                Optional
                > }
                >
                > Column = {
                > int len;
                > Card
                cards[0 .. len-1];
                > }
                >
                > Foundation_Id = { Deck deck, Suit
                suit }
                >
                > Foundations = {
                > Map : from Foundation_Id to
                Rank.
                > # For all decks and suits
                > }
                >
                > Freecells =
                {
                > Array of NUM_FREECELLS cards that can be empty.
                > }
                >
                > GamePosition = {
                > Foundations foundations;
                > Freecells
                freecells;
                >
                > Column x NUM_COLUMNS;
                > }
                >
                >
                Column_Idx = {Integer: from 0 to NUM_COLUMNS-1 }
                > Freecell_Idx =
                {Integer: from 0 to NUM_FREECELLS-1 }
                >
                > Source_Or_Dest_Id = union
                {
                > Column_Idx col;
                > OR
                > Freecell_Idx freecell;
                >
                OR
                > Foundation_Id foundation;
                > }
                >
                > Move = Struct
                {
                > Source_Or_Dest_Id source;
                > Source_Or_Dest_Id dest;
                > int
                num_cards; # Where appropriate;
                > Card source_card; # Optional
                >
                Card dest_card; # Optional
                > bool implicit; # Whether this move is done
                implicitly by an automove.
                > }
                >
                > Move_With_Position =
                Struct {
                > GamePosition pos_before_move;
                > Move move;
                >
                }
                >
                > Solution = {
                > Move_With_Position moves[0 .. NUM_MOVES
                - 1];
                > GamePosition final_position;
                > }
                >
                >
                >
                > Header = {
                > int NUM_DECKS;
                > int NUM_MOVES;
                > int
                NUM_COLUMNS;
                > int MAX_RANK;
                > String variant; # such as "freecell",
                "bakers_dozen", "bakers_game", etc.
                > enum sequences_are_built_by
                {
                > RANK, SUIT, ALTERNATE_COLOR
                > }
                > enum
                empty_stacks_filled_by {
                > KINGS_ONLY, NONE, ANY_CARD,
                > }
                >
                enum sequence_move {
                > LIMITED, UNLIMITED
                > }
                > }
                >
                > Total = {
                > Header header;
                > Solution solution;
                >
                }
                >
                > --

              • dannyjones183
                The attachment represents my first suggested update to your Abstract. I m not familiar with tracking card from multiple decks. That said ... I do have an issue
                Message 7 of 13 , Dec 7, 2012
                View Source
                • 0 Attachment
                  The attachment represents my first suggested update to your Abstract.

                  I'm not familiar with tracking card from multiple decks. That said ...

                  I do have an issue with the following structures.

                  Move_With_Position = Struct {
                  GamePosition pos_before_move;
                  Move move;
                  }

                  Solution = {
                  Move_With_Position moves[1..NUM_MOVES];
                  GamePosition final_position;
                  }

                  To me, Move_With_Position is extraneous, and Solution should be:

                  Solution = {
                  GamePosition initial_position;
                  int moves_used;
                  Move moves[1..moves_used];
                  GamePosition final_position;
                  }

                  Carrying along GamePosition at every move is extraneous information because each move should accurately identify a change to the table. If not, then the definition of Move is incomplete. If someone wishes to discuss a specific set of moves, then recreating the GamePosition associated with those moves might be necessary, or not.

                  Moving on to the following structure:

                  Move = Struct {
                  Source_Or_Dest_Id source;
                  Source_Or_Dest_Id dest;
                  int num_cards; # Where appropriate;
                  Card source_card; # Optional
                  Card dest_card; # Optional
                  bool implicit; # Whether this move is done implicitly by an automove.
                  }

                  There is a big difference between a Horne automove and a WKR automove when replaying a FreeCell solution through existing game players. I need more information ...

                  int automove = { 0, Horne, WKR, ... }; # Whether this move is done implicitly by an automove.

                  should replace ...

                  bool implicit; # Whether this move is done implicitly by an automove.

                  In addition, I once wrote that one must be careful in mixing Horne and WKR automoves. I don't think this message sequence is the proper place for that discussion, though.

                  Regards, Danny



                  > ---------------------
                  >
                  > Abstract -- range indexing updated
                  > --------
                  >
                  > This is a proposal for a universal format for encoding solitaire solutions.
                  > It grew out of a discussion on the fc-solve-discuss mailing list based on
                  > some people's frustration with the so-called "standard notation" for
                  > notating Freecell.
                  >
                  > This standard is written in a pseudo-BNF / pseudo-C-struct format, which
                  > will be encoding agnostic and can later be encoded in XML, JSON or a more
                  > human-readable format (though conversions to this format will be explicitly
                  > specified.).
                  >
                  > Format:
                  > -------
                  >
                  > Rank = {Integer: from 0 to MAX_RANK } (MAX_RANK is normally 13 for French
                  > playing card, but is specified at the header).
                  >
                  > Suit = One of {'H','C','D','S' }
                  >
                  > Deck = {Integer: from 1 to NUM_DECKS }
                  >
                  > Card = {
                  > bool is_empty;
                  > bool is_hidden;
                  > Rank rank;
                  > Suit suit;
                  > Deck deck; # Optional
                  > }
                  >
                  > Column = {
                  > int len;
                  > Card cards[1..len];
                  > }
                  >
                  > Foundation_Id = { Deck deck, Suit suit }
                  >
                  > Foundations = {
                  > Map : from Foundation_Id to Rank.
                  > # For all decks and suits
                  > }
                  >
                  > Freecells = {
                  > Array of NUM_FREECELLS cards that can be empty.
                  > }
                  >
                  > GamePosition = {
                  > Foundations foundations;
                  > Freecells freecells;
                  >
                  > Column [1..NUM_COLUMNS];
                  > }
                  >
                  > Column_Idx = {Integer: from 1 to NUM_COLUMNS }
                  > Freecell_Idx = {Integer: from 1 to NUM_FREECELLS }
                  >
                  > Source_Or_Dest_Id = union {
                  > Column_Idx col;
                  > OR
                  > Freecell_Idx freecell;
                  > OR
                  > Foundation_Id foundation;
                  > }
                  >
                  > Move = Struct {
                  > Source_Or_Dest_Id source;
                  > Source_Or_Dest_Id dest;
                  > int num_cards; # Where appropriate;
                  > Card source_card; # Optional
                  > Card dest_card; # Optional
                  > bool implicit; # Whether this move is done implicitly by an automove.
                  > }
                  >
                  > Move_With_Position = Struct {
                  > GamePosition pos_before_move;
                  > Move move;
                  > }
                  >
                  > Solution = {
                  > Move_With_Position moves[1..NUM_MOVES];
                  > GamePosition final_position;
                  > }
                  >
                  >
                  >
                  > Header = {
                  > int NUM_DECKS;
                  > int NUM_MOVES;
                  > int NUM_COLUMNS;
                  > int MAX_RANK;
                  > String variant; # such as "freecell", "bakers_dozen", "bakers_game", etc.
                  > enum sequences_are_built_by {
                  > RANK, SUIT, ALTERNATE_COLOR
                  > }
                  > enum empty_stacks_filled_by {
                  > KINGS_ONLY, NONE, ANY_CARD
                  > }
                  > enum sequence_move {
                  > LIMITED, UNLIMITED
                  > }
                  > }
                  >
                  > Total = {
                  > Header header;
                  > Solution solution;
                  > }
                  >
                  > --
                • Shlomi Fish
                  Hi Danny, thanks for your E-mail. On Sat, 08 Dec 2012 02:21:00 -0000 ... Your message does not appear to contain an attachment. ... Well, we can make
                  Message 8 of 13 , Dec 7, 2012
                  View Source
                  • 0 Attachment
                    Hi Danny,

                    thanks for your E-mail.

                    On Sat, 08 Dec 2012 02:21:00 -0000
                    "dannyjones183" <dannyjones183@...> wrote:

                    > The attachment represents my first suggested update to your Abstract.
                    >

                    Your message does not appear to contain an attachment.

                    > I'm not familiar with tracking card from multiple decks. That said ...
                    >
                    > I do have an issue with the following structures.
                    >
                    > Move_With_Position = Struct {
                    > GamePosition pos_before_move;
                    > Move move;
                    > }
                    >
                    > Solution = {
                    > Move_With_Position moves[1..NUM_MOVES];
                    > GamePosition final_position;
                    > }
                    >
                    > To me, Move_With_Position is extraneous, and Solution should be:
                    >
                    > Solution = {
                    > GamePosition initial_position;
                    > int moves_used;
                    > Move moves[1..moves_used];
                    > GamePosition final_position;
                    > }

                    Well, we can make GamePosition optional. But one advantage to
                    GamePosition is that it gives some redundancy and allows the processor of the
                    format to make sure that the move is correct.

                    >
                    > Carrying along GamePosition at every move is extraneous information because
                    > each move should accurately identify a change to the table. If not, then the
                    > definition of Move is incomplete. If someone wishes to discuss a specific set
                    > of moves, then recreating the GamePosition associated with those moves might
                    > be necessary, or not.
                    >
                    > Moving on to the following structure:
                    >
                    > Move = Struct {
                    > Source_Or_Dest_Id source;
                    > Source_Or_Dest_Id dest;
                    > int num_cards; # Where appropriate;
                    > Card source_card; # Optional
                    > Card dest_card; # Optional
                    > bool implicit; # Whether this move is done implicitly by an automove.
                    > }
                    >
                    > There is a big difference between a Horne automove and a WKR automove when
                    > replaying a FreeCell solution through existing game players. I need more
                    > information ...
                    >
                    > int automove = { 0, Horne, WKR, ... }; # Whether this move is done implicitly
                    > by an automove.

                    I would prefer "NONE" instead of "0". And you should use an enum or a string
                    instead of an "int".

                    >
                    > should replace ...
                    >
                    > bool implicit; # Whether this move is done implicitly by an automove.
                    >
                    > In addition, I once wrote that one must be careful in mixing Horne and WKR
                    > automoves. I don't think this message sequence is the proper place for that
                    > discussion, though.

                    Can you give a link? Sounds interesting.

                    Regards,

                    Shlomi Fish

                    >
                    > Regards, Danny
                    >
                    >

                    --
                    -----------------------------------------------------------------
                    Shlomi Fish http://www.shlomifish.org/
                    My Favourite FOSS - http://www.shlomifish.org/open-source/favourite/

                    Trying to block Internet pornography is like climbing a waterfall and trying
                    to stay dry. (— one of Shlomi Fish’s Internet Friends)

                    Please reply to list if it's a mailing list post - http://shlom.in/reply .
                  • Shlomi Fish
                    Hi Danny, On Fri, 07 Dec 2012 18:44:01 -0000 ... OK, but remember that this is an interchange format. Assuming the solution format is valid, then one can
                    Message 9 of 13 , Dec 7, 2012
                    View Source
                    • 0 Attachment
                      Hi Danny,

                      On Fri, 07 Dec 2012 18:44:01 -0000
                      "dannyjones183" <dannyjones183@...> wrote:

                      > To me, using pseudo-C forces a constraint that isn't natural. I think all of
                      > your {0..N-1} statements should be {1..N}. That way, I would have a clearer
                      > idea what move "m" from column "col" to freecell "fc" using deck "j" actually
                      > means. I don't care if my input/output modules have to do a little extra
                      > work. Better them than me!

                      OK, but remember that this is an interchange format. Assuming the solution
                      format is valid, then one can easily convert it to a one based on format using
                      an XSLT transformation or whatever. Furthermore in XML and JSON the index in the
                      sequence is normally not given or needed, so the starting index is irrelevant
                      (unless it is referenced).

                      Another thing I've considered is how to represent PySolFC-like saved games
                      with undos and redos and tree diversions. I don't know whether it falls in the
                      scope.

                      Also see http://bikeshed.com/ .

                      Regards,

                      Shlomi Fish

                      >
                      >
                      > --- In fc-solve-discuss@yahoogroups.com, Shlomi Fish <shlomif@...> wrote:
                      > >
                      > > Hi all,
                      > >
                      > > in order to get the issue of creating a new standard notation for Freecell
                      > > and similar variants of Solitaire, I have started working on a new
                      > > specification here:
                      > >
                      >
                      > <snip>
                      >
                      > > ---------------------
                      > >
                      > > Abstract
                      > > --------
                      > >
                      > > This is a proposal for a universal format for encoding solitaire solutions.
                      > > It grew out of a discussion on the fc-solve-discuss mailing list based on
                      > > some people's frustration with the so-called “standard notationâ€_ for
                      > > notating Freecell.
                      > >
                      > > This standard is written in a pseudo-BNF / pseudo-C-struct format, which
                      > > will be encoding agnostic and can later be encoded in XML, JSON or a more
                      > > human-readable format (though conversions to this format will be explicitly
                      > > specified.).
                      > >
                      > > Format:
                      > > -------
                      > >
                      > > Rank = {Integer: from 0 to MAX_RANK } (MAX_RANK is normally 13 for French
                      > > playing card, but is specified at the header).
                      > >
                      > > Suit = One Of{'H','C','D','S' }
                      > >
                      > > Deck = {Integer: from 0 to NUM_DECKS - 1 }
                      > >
                      > > Card = {
                      > > bool is_empty;
                      > > bool is_hidden;
                      > > Rank rank;
                      > > Suit suit;
                      > > Deck deck; # Optional
                      > > }
                      > >
                      > > Column = {
                      > > int len;
                      > > Card cards[0 .. len-1];
                      > > }
                      > >
                      > > Foundation_Id = { Deck deck, Suit suit }
                      > >
                      > > Foundations = {
                      > > Map : from Foundation_Id to Rank.
                      > > # For all decks and suits
                      > > }
                      > >
                      > > Freecells = {
                      > > Array of NUM_FREECELLS cards that can be empty.
                      > > }
                      > >
                      > > GamePosition = {
                      > > Foundations foundations;
                      > > Freecells freecells;
                      > >
                      > > Column x NUM_COLUMNS;
                      > > }
                      > >
                      > > Column_Idx = {Integer: from 0 to NUM_COLUMNS-1 }
                      > > Freecell_Idx = {Integer: from 0 to NUM_FREECELLS-1 }
                      > >
                      > > Source_Or_Dest_Id = union {
                      > > Column_Idx col;
                      > > OR
                      > > Freecell_Idx freecell;
                      > > OR
                      > > Foundation_Id foundation;
                      > > }
                      > >
                      > > Move = Struct {
                      > > Source_Or_Dest_Id source;
                      > > Source_Or_Dest_Id dest;
                      > > int num_cards; # Where appropriate;
                      > > Card source_card; # Optional
                      > > Card dest_card; # Optional
                      > > bool implicit; # Whether this move is done implicitly by an automove.
                      > > }
                      > >
                      > > Move_With_Position = Struct {
                      > > GamePosition pos_before_move;
                      > > Move move;
                      > > }
                      > >
                      > > Solution = {
                      > > Move_With_Position moves[0 .. NUM_MOVES - 1];
                      > > GamePosition final_position;
                      > > }
                      > >
                      > >
                      > >
                      > > Header = {
                      > > int NUM_DECKS;
                      > > int NUM_MOVES;
                      > > int NUM_COLUMNS;
                      > > int MAX_RANK;
                      > > String variant; # such as "freecell", "bakers_dozen", "bakers_game",
                      > > etc. enum sequences_are_built_by {
                      > > RANK, SUIT, ALTERNATE_COLOR
                      > > }
                      > > enum empty_stacks_filled_by {
                      > > KINGS_ONLY, NONE, ANY_CARD,
                      > > }
                      > > enum sequence_move {
                      > > LIMITED, UNLIMITED
                      > > }
                      > > }
                      > >
                      > > Total = {
                      > > Header header;
                      > > Solution solution;
                      > > }
                      > >
                      > > --
                      >
                      >



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

                      The difference between a good student and a bad student is that a bad student
                      forgets the material five minutes before the test, while a good student five
                      minutes afterwards.
                      — One of Shlomi Fish’s Technion Lecturers

                      Please reply to list if it's a mailing list post - http://shlom.in/reply .
                    • dannyjones183
                      ... I never sent an e-mail. The !@#$%^ Yahoo system created one as a copy of my reply in the discussion group. This would also explain why I m getting e-mail
                      Message 10 of 13 , Dec 8, 2012
                      View Source
                      • 0 Attachment
                        --- In fc-solve-discuss@yahoogroups.com, Shlomi Fish <shlomif@...> wrote:
                        >
                        > Hi Danny,
                        >
                        > thanks for your E-mail.
                        >

                        I never sent an e-mail. The !@#$%^ Yahoo system created one as a copy of my reply in the discussion group. This would also explain why I'm getting e-mail copies of your responses.

                        > On Sat, 08 Dec 2012 02:21:00 -0000
                        > "dannyjones183" <dannyjones183@...> wrote:
                        >
                        > > The attachment represents my first suggested update to your Abstract.
                        > >
                        >
                        > Your message does not appear to contain an attachment.
                        >

                        The "attachment" was the altered text version of your Abstract that I included after my name.

                        > > I'm not familiar with tracking card from multiple decks. That said ...
                        > >
                        > > I do have an issue with the following structures.
                        > >
                        > > Move_With_Position = Struct {
                        > > GamePosition pos_before_move;
                        > > Move move;
                        > > }
                        > >
                        > > Solution = {
                        > > Move_With_Position moves[1..NUM_MOVES];
                        > > GamePosition final_position;
                        > > }
                        > >
                        > > To me, Move_With_Position is extraneous, and Solution should be:
                        > >
                        > > Solution = {
                        > > GamePosition initial_position;
                        > > int moves_used;
                        > > Move moves[1..moves_used];
                        > > GamePosition final_position;
                        > > }
                        >
                        > Well, we can make GamePosition optional. But one advantage to
                        > GamePosition is that it gives some redundancy and allows the processor of the
                        > format to make sure that the move is correct.
                        >

                        Optional works for me.

                        > >
                        > > Carrying along GamePosition at every move is extraneous information because
                        > > each move should accurately identify a change to the table. If not, then the
                        > > definition of Move is incomplete. If someone wishes to discuss a specific set
                        > > of moves, then recreating the GamePosition associated with those moves might
                        > > be necessary, or not.
                        > >
                        > > Moving on to the following structure:
                        > >
                        > > Move = Struct {
                        > > Source_Or_Dest_Id source;
                        > > Source_Or_Dest_Id dest;
                        > > int num_cards; # Where appropriate;
                        > > Card source_card; # Optional
                        > > Card dest_card; # Optional
                        > > bool implicit; # Whether this move is done implicitly by an automove.
                        > > }
                        > >
                        > > There is a big difference between a Horne automove and a WKR automove when
                        > > replaying a FreeCell solution through existing game players. I need more
                        > > information ...
                        > >
                        > > int automove = { 0, Horne, WKR, ... }; # Whether this move is done implicitly
                        > > by an automove.
                        >
                        > I would prefer "NONE" instead of "0". And you should use an enum or a string
                        > instead of an "int".
                        >

                        Accepted.

                        > >
                        > > should replace ...
                        > >
                        > > bool implicit; # Whether this move is done implicitly by an automove.
                        > >
                        > > In addition, I once wrote that one must be careful in mixing Horne and WKR
                        > > automoves. I don't think this message sequence is the proper place for that
                        > > discussion, though.
                        >
                        > Can you give a link? Sounds interesting.
                        >

                        The link isn't going to provide any additional information. I simply repeated a comment that I'd made previously. I'll start a new topic to explain my concerns.

                        Regards, Danny
                      • dannyjones183
                        ... OK, I ll remember that this is an interchange format. That said, I m withdrawing from the discussion because all I m after is a modest, yet unambiguous
                        Message 11 of 13 , Dec 8, 2012
                        View Source
                        • 0 Attachment
                          --- In fc-solve-discuss@yahoogroups.com, Shlomi Fish <shlomif@...> wrote:
                          >
                          > Hi Danny,
                          >
                          > On Fri, 07 Dec 2012 18:44:01 -0000
                          > "dannyjones183" <dannyjones183@...> wrote:
                          >
                          > > To me, using pseudo-C forces a constraint that isn't natural. I think all of
                          > > your {0..N-1} statements should be {1..N}. That way, I would have a clearer
                          > > idea what move "m" from column "col" to freecell "fc" using deck "j" actually
                          > > means. I don't care if my input/output modules have to do a little extra
                          > > work. Better them than me!
                          >
                          > OK, but remember that this is an interchange format. Assuming the solution
                          > format is valid, then one can easily convert it to a one based on format using
                          > an XSLT transformation or whatever. Furthermore in XML and JSON the index in the
                          > sequence is normally not given or needed, so the starting index is irrelevant
                          > (unless it is referenced).
                          >

                          OK, I'll remember that this is an interchange format. That said, I'm withdrawing from the discussion because all I'm after is a modest, yet unambiguous FreeCell exchange format that I can manually use to: (1) translate someone else's solution into an input file for FcPro, or (2) represent a solution from my solver.

                          <snip>

                          Regards, Danny
                        • Gary Campbell
                          I’m after what I think Danny also wants. And here is my suggestions for it. -Gary Campbell Standard Freecell Notation ... This notation could be
                          Message 12 of 13 , Dec 8, 2012
                          View Source
                          • 0 Attachment
                            I’m after what I think Danny also wants.  And here is my suggestions for it.      -Gary Campbell
                             
                            Standard Freecell Notation
                            ----------------------------------
                            This notation could be adapted to other games, but is directly intended only for common freecell players and solvers.
                             
                            1.  A standard fixed-width font should be used to display a layout using only plain text (ASCII) characters and line endings.
                            2.  A layout consists of an optional Game# line and/or a freecell+home line, up to 18 column lines, and an optional solution on one or more lines.
                            3.  If a Game# line is present, the freecell+home line must be missing or empty, and the Column lines must depict a fresh deal of the cards.
                            4.  A Standard Deck of cards is assumed (52 cards.  4 Suits: C, D, H, S.  13 Ranks: A, 2, 3, 4, 5, 6, 7, 8, 9, T, J, Q, K).
                            5.  A Game# line may have commentary text, but is required to have a sequence of digits with an optional leading “-“ sign.  An unsigned number indicates a standard game (defined using the original random number generator and card dealing algorithm present in the original MicroSoft FreeCell player).  A standard game# is less than 2**33.  A “negative” game# is used to indicate “cookie” deals, such as the -1 and -2 deals in the original FreeCell Player.
                            6.  The freecell+home line consists of 23 character positions.  Positions 1-2, 4-5, 7-8, and 10-11, are either blank or they indicate cards contained in the freecells.  Additionally, a freecell position may contain the letters BB (or any other non-card) to indicate a “blocked” freecell.  This notation is used to play with fewer than 4 freecells.  Position 12 must contain a + character.  Positions 13-14, 16-17, 19-20, and 22-23 are either blank or they indicate cards contained on the top of the home stacks, or foundations.  Positions 15, 18, and 21 contain blanks or spaces.
                            7.  Now, what do positions 3, 6, and 9 contain?  Normally, they would contain - characters (- signs).  However, if a solution is given that assumes WKR Automoves, these positions contain = characters, to signify that fact.  Otherwise, a solution is assumed to use Horne Automoves.  There are no other (standard) options for Automoves.
                            8.  The only required part of a Standard Layout is the column section (1-18 lines).  A layout must either be a fresh deal of the cards with 8 columns, the left 4 columns containing 7 cards and the right 4 containing 6, or a card layout that could conceivably result from playing from a fresh deal.  This means that all 52 cards must be present exactly once in a layout (either in a home stack, a freecell, or in the column section).  This is why 18 lines are sufficient to represent the deepest column possible:  An original column of 7 cards with a King on top that has a proper sequence of cards played onto the King down to a Two.  An Ace is not possible, since it would have been Automoved before any sequencing could have taken place.
                            9.  The Column Section consists of 3 characters per column:  Two characters for a card followed by a space.  The card characters may be blank or any valid card indicator: {A 2 3 4 5 6 7 8 9 T J Q K} x {C H D S}.  Embedded spaces must be present; trailing spaces are optional.
                            10.  The Solution Section (this is the hard part, and will probably receive the most criticism).
                                a. Optional comment lines may preceed the first solution line.
                                b. A solution line must begin with either a space or a . (period).
                                c. If it does, it must then have the (first or next) explicit (non-automove) move of the solution given as two characters:  The source of the move followed by the target of the move.  Source may be an occupied freecell (a b c d) or an occupied column (1 2 3 4 5 6 7 8).  Target may be an empty freecell (a b c d) or any column (1 2 3 4 5 6 7 8), or a home cell (foundation) indicated by an h.  If the target is an occupied column, the move must imply a move of one or more cards that form a proper sequence with the target, and the number of cards must be less than or equal to the number of freecells plus one, times two raised to the power of the number of empty columns.  This is the limit allowed by a series of single card moves given some number of freecells and empty columns.  If the target is an empty column, there are two caveats:  If the character in front of the move (the prefix character) is a space, the move is assumed to be the maximum number of cards allowed.  If the prefix character is a . (period), the move is a single card.  The second caveat is that the target column may not be counted when computing the maximum number of cards allowed.
                                d. A solution line may begin with any number of moves, but 10 moves per line should be the most common.  If the cycle of 3 characters per move is broken (fails to parse) the rest of the line is considered to be a comment.
                            11.  Complete solutions.  The above is used to display the initial layout (a fresh deal or an intermediate layout) and all the moves needed for a solution from that position.
                            12.  Partially played solutions.  When the game# is given, the initial layout is implied.  The most compact form to convey a solution would be to show the final position (which is all 4 Kings home), followed by the sequence of moves that solves the game.  When the sequence of moves does not begin with the depicted layout, additional notation is requied.  This will be indicated by using [  ] around the next move to be made, so that the layout depicted is the position reached from some implied beginning layout followed by the moves up to the [move].  If the [move] is after the final move, [??] may be used to indicate an undefined move.  If a constructed layout or non-standard deal is to be used, instead of indicating a game number, my suggestion is to reference a tag or filename that defines the layout in place of the game#.
                             
                            Sent: Saturday, December 08, 2012 3:25 AM
                            Subject: Re: Request for Comments: spec for the new solution notation standard
                             

                            <snip>
                            OK, I'll remember that this is an interchange format. That said, I'm withdrawing from the discussion because all I'm after is a modest, yet unambiguous FreeCell exchange format that I can manually use to: (1) translate someone else's solution into an input file for FcPro, or (2) represent a solution from my solver.

                            <snip>

                            Regards, Danny

                          • Gary Campbell
                            Followup by the author. Point 3 should read: 3. If the Column lines depict a fresh deal of the cards, the freecell+home line may be missing or empty. If a
                            Message 13 of 13 , Dec 8, 2012
                            View Source
                            • 0 Attachment
                              Followup by the author.
                               
                              Point 3 should read:
                              3.  If the Column lines depict a fresh deal of the cards, the freecell+home line may be missing or empty.
                               
                              If a freecell player uses a different algorithm for any of the following, the given remedy applies:
                              1.  A different game numbering system: Use the tag or filename approach.  Any unsigned number must indicate a Standard Game#.  Or, simply omit the game# line and begin with an empty freecell+home line, or the initial layout.
                              2.  A different implied move length to an empty column:  break down the move into a series of “atomic” moves (moves to and from freecells or  “dot” moves of single cards to empty columns) as necessary.
                              3.  A different Automove:  Use Horne Automoves and make all other moves explict.
                               
                              Sent: Saturday, December 08, 2012 9:06 AM
                              Subject: Re: Request for Comments: spec for the new solution notation standard
                               
                               

                              I’m after what I think Danny also wants.  And here is my suggestions for it.      -Gary Campbell
                               
                              Standard Freecell Notation
                              ----------------------------------
                              This notation could be adapted to other games, but is directly intended only for common freecell players and solvers.
                               
                              1.  A standard fixed-width font should be used to display a layout using only plain text (ASCII) characters and line endings.
                              2.  A layout consists of an optional Game# line and/or a freecell+home line, up to 18 column lines, and an optional solution on one or more lines.
                              3.  If a Game# line is present, the freecell+home line must be missing or empty, and the Column lines must depict a fresh deal of the cards.
                              4.  A Standard Deck of cards is assumed (52 cards.  4 Suits: C, D, H, S.  13 Ranks: A, 2, 3, 4, 5, 6, 7, 8, 9, T, J, Q, K).
                              5.  A Game# line may have commentary text, but is required to have a sequence of digits with an optional leading “-“ sign.  An unsigned number indicates a standard game (defined using the original random number generator and card dealing algorithm present in the original MicroSoft FreeCell player).  A standard game# is less than 2**33.  A “negative” game# is used to indicate “cookie” deals, such as the -1 and -2 deals in the original FreeCell Player.
                              6.  The freecell+home line consists of 23 character positions.  Positions 1-2, 4-5, 7-8, and 10-11, are either blank or they indicate cards contained in the freecells.  Additionally, a freecell position may contain the letters BB (or any other non-card) to indicate a “blocked” freecell.  This notation is used to play with fewer than 4 freecells.  Position 12 must contain a + character.  Positions 13-14, 16-17, 19-20, and 22-23 are either blank or they indicate cards contained on the top of the home stacks, or foundations.  Positions 15, 18, and 21 contain blanks or spaces.
                              7.  Now, what do positions 3, 6, and 9 contain?  Normally, they would contain - characters (- signs).  However, if a solution is given that assumes WKR Automoves, these positions contain = characters, to signify that fact.  Otherwise, a solution is assumed to use Horne Automoves.  There are no other (standard) options for Automoves.
                              8.  The only required part of a Standard Layout is the column section (1-18 lines).  A layout must either be a fresh deal of the cards with 8 columns, the left 4 columns containing 7 cards and the right 4 containing 6, or a card layout that could conceivably result from playing from a fresh deal.  This means that all 52 cards must be present exactly once in a layout (either in a home stack, a freecell, or in the column section).  This is why 18 lines are sufficient to represent the deepest column possible:  An original column of 7 cards with a King on top that has a proper sequence of cards played onto the King down to a Two.  An Ace is not possible, since it would have been Automoved before any sequencing could have taken place.
                              9.  The Column Section consists of 3 characters per column:  Two characters for a card followed by a space.  The card characters may be blank or any valid card indicator: {A 2 3 4 5 6 7 8 9 T J Q K} x {C H D S}.  Embedded spaces must be present; trailing spaces are optional.
                              10.  The Solution Section (this is the hard part, and will probably receive the most criticism).
                                  a. Optional comment lines may preceed the first solution line.
                                  b. A solution line must begin with either a space or a . (period).
                                  c. If it does, it must then have the (first or next) explicit (non-automove) move of the solution given as two characters:  The source of the move followed by the target of the move.  Source may be an occupied freecell (a b c d) or an occupied column (1 2 3 4 5 6 7 8).  Target may be an empty freecell (a b c d) or any column (1 2 3 4 5 6 7 8), or a home cell (foundation) indicated by an h.  If the target is an occupied column, the move must imply a move of one or more cards that form a proper sequence with the target, and the number of cards must be less than or equal to the number of freecells plus one, times two raised to the power of the number of empty columns.  This is the limit allowed by a series of single card moves given some number of freecells and empty columns.  If the target is an empty column, there are two caveats:  If the character in front of the move (the prefix character) is a space, the move is assumed to be the maximum number of cards allowed.  If the prefix character is a . (period), the move is a single card.  The second caveat is that the target column may not be counted when computing the maximum number of cards allowed.
                                  d. A solution line may begin with any number of moves, but 10 moves per line should be the most common.  If the cycle of 3 characters per move is broken (fails to parse) the rest of the line is considered to be a comment.
                              11.  Complete solutions.  The above is used to display the initial layout (a fresh deal or an intermediate layout) and all the moves needed for a solution from that position.
                              12.  Partially played solutions.  When the game# is given, the initial layout is implied.  The most compact form to convey a solution would be to show the final position (which is all 4 Kings home), followed by the sequence of moves that solves the game.  When the sequence of moves does not begin with the depicted layout, additional notation is requied.  This will be indicated by using [  ] around the next move to be made, so that the layout depicted is the position reached from some implied beginning layout followed by the moves up to the [move].  If the [move] is after the final move, [??] may be used to indicate an undefined move.  If a constructed layout or non-standard deal is to be used, instead of indicating a game number, my suggestion is to reference a tag or filename that defines the layout in place of the game#.
                               
                              Sent: Saturday, December 08, 2012 3:25 AM
                              Subject: Re: Request for Comments: spec for the new solution notation standard
                               

                              <snip>
                              OK, I'll remember that this is an interchange format. That said, I'm withdrawing from the discussion because all I'm after is a modest, yet unambiguous FreeCell exchange format that I can manually use to: (1) translate someone else's solution into an input file for FcPro, or (2) represent a solution from my solver.

                              <snip>

                              Regards, Danny

                            Your message has been successfully submitted and would be delivered to recipients shortly.