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

FC-Pro policy

Expand Messages
  • Adrian Ettlinger
    We seem to be entering a phase of work on FcPro where a version of it is evolving which we re calling the Solver Evaluation Edition FCS is, of course, the
    Message 1 of 7 , Dec 8, 2001
    View Source
    • 0 Attachment
      We seem to be entering a phase of work on FcPro where a version of it is
      evolving which we're calling the "Solver Evaluation Edition" FCS is, of
      course, the first addition, and we now have Patsolve partially integrated.

      We do not consider that the problem with playing back FCS move sequences
      is a "bug". A better description is that it is an incompatibility between
      the two programs. We would not consider modifying FcPro itself to
      accommodate the move format of FCS. A solution to the problem would be
      possible, and the methodology which should be used would be to insert a
      layer of code in the interface software to convert the FCS moves into moves
      that would be usable by FcPro.

      The moves which could be fed into FcPro would not have to be moves that
      would conform to M/S Freecells multiple-card moves. The best universal
      standard to adopt for interfacing move sequences, we have decided on further
      analysis, would be single-card moves. After all, if one were to play
      Freecell with a "hardware" deck of playing cards, one would be moving one
      card at a time. And FcPro can accept all moves as single-card moves,
      although there is one further wrinkle that would need to be added -- the
      automatic moves to the foundation, which are made by M/S Freecell and should
      be made by any Freecell-playing software. These moves should be assumed to
      have been made by FcPro, and omitted from the moves delivered to FcPro,
      otherwise they can cause an error in some circumstances.

      If someone could be found who has the capability and time to write the
      interface package, I would be glad to provide the interface specs and the
      source code for the connecting modules.

      I will soon be sending to Shlomi a copy of the new "Build 6" of FcPro
      version 6.5, the "Solver Evaluation Edition". In this version, I have
      changed the "Illegal Move" announcement, when using FCS, to be an
      information message explaining the situation, and also advising that the
      full solution as delivered by FCS can be found in a file named "FCSSolution.
      txt". BTW, the fraction of hands which cannot be played on FcPro is
      approximately 30%, and the other 70% play back normally without
      interruption.

      Best regards, --------------Adrian Ettlinger
    • Shlomi Fish
      ... I did not say such a thing was not good. ... I consider such a thing as a kludge. But I guess that I unless I volunteer to modify FC-Pro to work in both
      Message 2 of 7 , Dec 9, 2001
      View Source
      • 0 Attachment
        On Sat, 8 Dec 2001, Adrian Ettlinger wrote:

        > We seem to be entering a phase of work on FcPro where a version of it is
        > evolving which we're calling the "Solver Evaluation Edition" FCS is, of
        > course, the first addition, and we now have Patsolve partially integrated.
        >

        I did not say such a thing was not good.

        > We do not consider that the problem with playing back FCS move sequences
        > is a "bug". A better description is that it is an incompatibility between
        > the two programs. We would not consider modifying FcPro itself to
        > accommodate the move format of FCS. A solution to the problem would be
        > possible, and the methodology which should be used would be to insert a
        > layer of code in the interface software to convert the FCS moves into moves
        > that would be usable by FcPro.
        >

        I consider such a thing as a kludge. But I guess that I unless I volunteer
        to modify FC-Pro to work in both modes myself, then I cannot complain.

        > The moves which could be fed into FcPro would not have to be moves that
        > would conform to M/S Freecells multiple-card moves. The best universal
        > standard to adopt for interfacing move sequences, we have decided on further
        > analysis, would be single-card moves. After all, if one were to play
        > Freecell with a "hardware" deck of playing cards, one would be moving one
        > card at a time. And FcPro can accept all moves as single-card moves,
        > although there is one further wrinkle that would need to be added -- the
        > automatic moves to the foundation, which are made by M/S Freecell and should
        > be made by any Freecell-playing software. These moves should be assumed to
        > have been made by FcPro, and omitted from the moves delivered to FcPro,
        > otherwise they can cause an error in some circumstances.
        >

        Hmmm. Single-Card moves may make the solution longer than it really is.
        However, I agree to this workaround if only it won't be implemented for
        each one of FCS' moves, just for the stack->empty stack ones.

        > If someone could be found who has the capability and time to write the
        > interface package, I would be glad to provide the interface specs and the
        > source code for the connecting modules.
        >

        I could try to do that. Should be easy with recursion or soft-recursion.

        > I will soon be sending to Shlomi a copy of the new "Build 6" of FcPro
        > version 6.5, the "Solver Evaluation Edition". In this version, I have
        > changed the "Illegal Move" announcement, when using FCS, to be an
        > information message explaining the situation, and also advising that the
        > full solution as delivered by FCS can be found in a file named "FCSSolution.
        > txt". BTW, the fraction of hands which cannot be played on FcPro is
        > approximately 30%, and the other 70% play back normally without
        > interruption.
        >

        30% is something the user is bound to get into. But %70 success is better
        than nothing.

        Regards,

        Shlomi Fish

        > Best regards, --------------Adrian Ettlinger
        >
        >
        >
        >
        > To unsubscribe from this group, send an email to:
        > fc-solve-discuss-unsubscribe@yahoogroups.com
        >
        >
        >
        > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
        >
        >

        --


        ----------------------------------------------------------------------
        Shlomi Fish shlomif@...
        Home Page: http://t2.technion.ac.il/~shlomif/
        Home E-mail: shlomif@...

        If:
        1. A is A
        2. A is not not-A
        does it imply that
        1. B is B
        2. B is not not-B
      • WKRfresno@aol.com
        In a message dated 12/8/01 8:38:10 PM Pacific Standard Time, ... sequences ... All very reasonable. FcPro shouldn t try to accommodate a myriad of move
        Message 3 of 7 , Dec 9, 2001
        View Source
        • 0 Attachment
          In a message dated 12/8/01 8:38:10 PM Pacific Standard Time,
          aettlinger@... writes:

          > We seem to be entering a phase of work on FcPro where a version of it is
          > evolving which we're calling the "Solver Evaluation Edition" FCS is, of
          > course, the first addition, and we now have Patsolve partially integrated.
          >
          > We do not consider that the problem with playing back FCS move
          sequences
          > is a "bug". A better description is that it is an incompatibility between
          > the two programs. We would not consider modifying FcPro itself to
          > accommodate the move format of FCS. A solution to the problem would be
          > possible, and the methodology which should be used would be to insert a
          > layer of code in the interface software to convert the FCS moves into moves
          > that would be usable by FcPro.

          All very reasonable. FcPro shouldn't try to accommodate a myriad of move
          sequence formats produced by disparate solvers. Each solver should convert
          its own solutions to some universal format.

          > The moves which could be fed into FcPro would not have to be moves that
          > would conform to M/S Freecells multiple-card moves.

          Good, because M/S multiple-card moves are severely defective.

          > The best universal
          > standard to adopt for interfacing move sequences, we have decided on
          further
          > analysis, would be single-card moves. After all, if one were to play
          > Freecell with a "hardware" deck of playing cards, one would be moving one
          > card at a time.

          Please! If you have a single empty freecell and a single empty column, surely
          you would pick up a four-card sequence and transfer it as a group from one
          column to another.

          > And FcPro can accept all moves as single-card moves,
          > although there is one further wrinkle that would need to be added -- the
          > automatic moves to the foundation, which are made by M/S Freecell and
          should
          > be made by any Freecell-playing software. These moves should be assumed to
          > have been made by FcPro, and omitted from the moves delivered to FcPro,
          > otherwise they can cause an error in some circumstances.

          You have not described "Solver Evaluation," but SOLUTION evaluation. I assume
          that FCS and FcPro and many more solvers will produce accurate solutions.
          Evaluating the solvers themselves will require something more.
          Let me suggest that if all of us are truly interested in pounding the
          freecell problem into the dust, we must adopt a better format for solutions.
          The format published on Keller's fine site has been useful. Now that several
          solvers are about to enter the field, a more informative code would make
          communication much easier. I am thinking of two changes. First, a symbol that
          indicates which automove scheme to use. I know of three valid automove
          policies. And second, each move should indicate how many cards to move in a
          sequence. Something like this: 24-6 means six cards move from column 2 to
          column 4; 35-1 means one card moves from column 3 to column 5. I don't
          particularly care about the precise symbology, but I do think we all need
          that kind of format.

          Bill Raymond
        • Adrian Ettlinger
          Hi Shlomi,
          Message 4 of 7 , Dec 9, 2001
          View Source
          • 0 Attachment
            Hi Shlomi,

            <<<<.........we're calling the "Solver Evaluation Edition".........>>
            <<I did not say such a thing was not good.>>
            Hmmm, we're getting into a triple negative here. I really didn't think
            you would consider such a thing as not good. My intent was merely to inform
            you of the terminology I'm adopting.

            <<I consider such a thing as a kludge. But I guess that I unless I volunteer
            to modify FC-Pro to work in both modes myself, then I cannot complain.>>
            I'll reiterate that the wisest approach would be to do the conversion
            outside of the body of the FcPro code itself. One of the reasons I say this
            is that I know the source and I know how messy it is and how hard it is to
            follow, and also my recollection of the difficult problems we had in
            developing it and testing that it did what it was supposed to do. I
            wouldn't consider that approach a kludge; it's better described as an
            architectural design decision. If the body of the code were modified, I
            would not approve using it in the standard edition of FcPro, for the
            principal reason that it would be a substantial project to make a thorought
            test of it.

            <<Hmmm. Single-Card moves may make the solution longer than it really is.
            However, I agree to this workaround if only it won't be implemented for each
            one of FCS' moves, just for the stack->empty stack ones.>>
            Right on. I might have mentioned that. Stack-to-occupied stack
            movements do not have to be treated. Only stack to empty stack moves. But
            we need also to consider moves to the foundation. What you might give up in
            solution length by expanding such moves to their single-card equivalents,
            you would probably more than gain back by omitting all moves which would be
            automatic moves to the foundation. There is an explicit formula for such
            moves. Are you aware of that?

            <<30% is something the user is bound to get into. But %70 success is better
            than nothing.>>
            Note also, that to make it still further "better than nothing" in its
            current interim form, FCS's full solution is output to a text file, where it
            can be read. Not very convenient, I'd agree, but at least there's a way to
            get at it.

            I now have that Build 6 in good enough shape to pass along to you, and
            it will follow in a separate side E-mail.

            Best regards, ---------------Adrian
          • Adrian Ettlinger
            In response to Bill Fresno Raymond.
            Message 5 of 7 , Dec 9, 2001
            View Source
            • 0 Attachment
              In response to Bill "Fresno" Raymond.

              <<All very reasonable. FcPro shouldn't try to accommodate a myriad of move
              sequence formats produced by disparate solvers. Each solver should convert
              its own solutions to some universal format.>>
              Thanks, Bill.

              <<Good, because M/S multiple-card moves are severely defective.>>
              Defective in the sense that they could have been designed to more more
              cards in many situations than they do. But, nevertheless, more people play
              Freecell on M/S Freecell than any other environment. (Any debate on that?).
              Questions are sometimes asked by skeptical Freecell players who don't
              believe a given deal is solvable. If you want to give such a skeptic a
              written-out solution, unless you express it in moves that can be made on M/S
              Freecell, they won't believe it is a valid solution.

              <<<<After all, if one were to play Freecell with a "hardware" deck of
              playing cards, one would be moving one card at a time.>>
              <<Please! If you have a single empty freecell and a single empty column,
              surely you would pick up a four-card sequence and transfer it as a group
              from one column to another.>>
              OK, OK. I perhaps should have qualified that comment. An experienced,
              careful player would probably do that. But if one got into that habit and
              got careless about it, it would be very easy to cheat accidentally. One
              could wind up thinking he/she'd solved an impossible deal. The four-card
              move when there is one each empty freecell and column is the "classic"
              everyone remembers, but memorizing all the possible multiple-card
              permissible moves isn't likely. Actually, that might be a reason why
              Freecell lends itself more naturally to computer play than playing-card
              play. Has anyone ever heard of anyone playing Freecell with a deck of
              cards?

              <<You have not described "Solver Evaluation," but SOLUTION evaluation. I
              assume that FCS and FcPro and many more solvers will produce accurate
              solutions. >>
              We happen to be talking about solutions at the moment because of this
              compatibilty problem, but I consider solution evaluation just a subdivision
              of solver evaluation. Solver evaluation also includes speed of range
              solving, absence of false impossibles, size of solution (OK, you could call
              that solution evaluation).

              Comparison of the lengths of solutions will certainly require a standard
              for permissible multi-card moves. Also the question of whether to count
              automatic moves to the foundation. The least common denominator would be to
              use the count of equivalent single-card moves, but that could impose an
              unfair penalty, in that two solutions might rank differently with respect to
              each other depending on what rule were used. For the reason stated above,
              my vote would still be to favor the M/S Freecell moves. The formula for
              those is simple and easy to express.

              If a notation were employed for number of cards moves, wouldn't this
              need to employed only for moves to an empty column?

              Best regards, ------------------Adrian
            • WKRfresno@aol.com
              In a message dated 12/9/01 10:21:54 PM Pacific Standard Time, ... that?). ... M/S ... Yes. Consider this very carefully. To communicate with everyday freecell
              Message 6 of 7 , Dec 10, 2001
              View Source
              • 0 Attachment
                In a message dated 12/9/01 10:21:54 PM Pacific Standard Time,
                aettlinger@... writes:

                > ... But, nevertheless, more people play
                > Freecell on M/S Freecell than any other environment. (Any debate on
                that?).
                > Questions are sometimes asked by skeptical Freecell players who don't
                > believe a given deal is solvable. If you want to give such a skeptic a
                > written-out solution, unless you express it in moves that can be made on
                M/S
                > Freecell, they won't believe it is a valid solution.

                Yes. Consider this very carefully. To communicate with everyday freecell
                players, the freecell solver community is stuck with MS moves and autoplay
                for now, just as everyday computer users are stuck with Intel architecture
                for now. But we must not let that scourge be a permanent hobble for our
                understanding of solver tactics and our march toward the perfect solver. Two
                solution formats are required to handle all situations. One for Fred out in
                the shed with freecell in his head. Fred needs a list of moves that he can
                follow line by line as he tries to solve one of the MS 32K (now the MS 1M).
                Fred's solution should be limited to Horne's MS moves and autoplay. But a
                second format is needed to exchange solutions among automated solvers and
                their authors/custodians. This second format will be able to handle any legal
                move, will tell the solver which autoplay rules to use, and will indicate how
                many cards to move in a sequence from a column to an empty column (at the
                very least. It may be easier to indicate how many cards move in all moves).

                > <<<<After all, if one were to play Freecell with a "hardware" deck of
                > playing cards, one would be moving one card at a time.>>
                > <<Please! If you have a single empty freecell and a single empty column,
                > surely you would pick up a four-card sequence and transfer it as a group
                > from one column to another.>>
                > OK, OK. I perhaps should have qualified that comment. An experienced,
                > careful player would probably do that. But if one got into that habit and
                > got careless about it, it would be very easy to cheat accidentally. One
                > could wind up thinking he/she'd solved an impossible deal. The four-card
                > move when there is one each empty freecell and column is the "classic"
                > everyone remembers, but memorizing all the possible multiple-card
                > permissible moves isn't likely. Actually, that might be a reason why
                > Freecell lends itself more naturally to computer play than playing-card
                > play. Has anyone ever heard of anyone playing Freecell with a deck of
                > cards?

                Well. It has been tried. Computers make the game so much easier to play. But
                mainly I want to avoid silly-looking solutions that have nothing but
                single-card moves.
                And surely Woods' solver doesn't use eight single-card moves within itself to
                represent a four-card sequence move!

                > <<You have not described "Solver Evaluation," but SOLUTION evaluation. I
                > assume that FCS and FcPro and many more solvers will produce accurate
                > solutions. >>
                > We happen to be talking about solutions at the moment because of this
                > compatibilty problem, but I consider solution evaluation just a subdivision
                > of solver evaluation. Solver evaluation also includes speed of range
                > solving, absence of false impossibles, size of solution (OK, you could call
                > that solution evaluation).

                No, you're right. Size of a single solution is solution evaluation. Average
                size of solutions is solver evaluation.

                Bill Raymond
              • Tom Holroyd
                ... I don t know about that, but my solver moves single cards. There is an advantage to that, too: one of the fun variations on Freecell is to solve it in the
                Message 7 of 7 , Dec 10, 2001
                View Source
                • 0 Attachment
                  > And surely Woods' solver doesn't use eight single-card moves within itself to
                  > represent a four-card sequence move!

                  I don't know about that, but my solver moves single cards. There is an
                  advantage to that, too: one of the fun variations on Freecell is to solve
                  it in the minimum possible number of moves, and that can be defined as the
                  minimum number of single card moves. (I realize that not everybody counts
                  single card moves, and not every program does, but some do, like the Tcl
                  Patience implementation, and maybe other programs should.) Moving stacks
                  is inefficient. You can usually do better by moving single cards. Also,
                  the moves that the program prints out are quite clear to anybody, and
                  don't depend on magic supermove settings. 5C to 6H. AH out. 7C to temp.
                  Easy. Intuitive.

                  Just my 2 yen.
                Your message has been successfully submitted and would be delivered to recipients shortly.