In a message dated 12/13/01 4:43:39 AM Pacific Standard Time,
aettlinger_at_worldnet.att.net writes:
> <<PLEASE don't take my word for it. I'm trying to get you out of your
> MS/FcPro chains.>>
> Sorry to say it, but I really don't have any stomach left to dig into
> the FcPro Solver any more. Whether I'll relent some day, I don't know.
But
> I'd rather concentrate on finding a better solver written by someone else.
It would be a wonderful thing for all of us if you could be our official
solver tester. Build a main() that can call FcPro, PatSolve, Shlomi's and
each of the others that are out there, on one machine, with the same range of
deals, using the same number of freecells.
> <>
> I'd take issue with the word "wrong". It's limited because it doesn't
> provide the maximum capability. But that doesn't make it "wrong" in any
> sense.
Of course it's not wrong in any absolute sense, but it would be wrong to
perpetuate that limitation. To be more precise, I'm very uncomfortable and
even offended by that limitation. On the other hand, a user asked recently
about MS' not allowing a homecell card to be brought back into play. That's
a limit that I wouldn't want to change. But I would be very interested to
learn whether lifting that restriction would make solvable 11982 and others.
> <<I'm happy with MK's explanation if it is complete and can be confirmed.>>
> This isn't rocket science. It's a simple algebraic formula. Where c
is
> the number of vacant columns and f is the number of vacant freecells, for
MS
> the number of cards that can be moved from a column to an occupied column
is
> (c+1)*(f+1), to an empty column c*(f+1) For FcPro's "supermove", to an
> occupied column it's (2^(c+1))*(f+1), to an empty column (2^c)*(f+1). I
> think I have that right, but I'm not absolutely sure. That's what the code
> seems to say. You have to put limits on it for high values of c.
MS' equations are certainly not ideal. And I think your're wrong on both for
c>1. Item: f=1, c=2, formula says 4 cards move from column to empty column.
And 4 cards should move. But MS actually moves only 3. That's the restriction
that must not hobble the solver community.
For FcPro, your formula works out to 8 cards c2oc, c=1, f=1, which cannot be
right.
What limit can there be for the number of cards that can be moved with high
values of c, other than the fact that the longest possible supermove is 13
cards? (no autoplay).
> Now, then, there is a degree to which FcPro doesn't quite go as far as
> it might. I'd brought up the question of whether it's legitimate to
include
> in a supermove the move of a single card from a single-card column from the
> column to an empty freecell to balance the distribution to allow a higher
> number of cards to be moved. You'd replied that it's legal, but you
> wouldn't count it as included within the automatic part of the move. FcPro
> takes the same approach. It's up to the player to do that move
> him/herself. But it would be possible to extend the code further,
recognize
> that situation, and include that column-to-freecell shift as a device to
> give the player a still further shortcut.
There may be other situations where something similar could work, but not
here. Suppose there are two empty freecells, no empty columns, one column has
a single card, and a four-card supermove could be made if the single card
were to be moved to a freecell. If the player doesn't see that possibility
she's unlikely to click on that column to move three cards somewhere else. So
when would the computer alert her to the possibility? And what if that
sequence leads to a dead end? It would be the computer's fault that she lost.
> Re hash, I'm still somewhat curious academically to learn how what Don
> and I did compares to the way you big boys approach it. Later on I might
> dig out the code for the hash value computation, and you can tell me what
it
> is we've been doing.
I'd actually be willing to look at that, but I don't have time now and if
someone else does it I'll be just as happy.
Bill Raymond
Received on Thu Dec 13 2001 - 17:10:12 IST