Shlomi Fish wrote:
>
> On Tue, 13 Feb 2001, Markus F.X.J. Oberhumer wrote:
>
> > Shlomi,
> >
> > below you will find my final python bindings, ready for inclusion
> > in 1.4.2. I'd still ask you to have a look - esp. the result
> > from fcs_move_get_num_cards_in_seq() looks suspicious.
> >
>
> Pay attention to the move type. It is move type
> FCS_MOVE_TYPE_STACK_TO_FREECELL in which this field is irrelevant because
> only one card can be moved at a time.
>
> Would it be possible for the bindings to return an array of all the moves
> that should be made till the solution, instead of just one? It would be a
> waste of resources to call it each time the user requires a hint.
>
> And here are some other thoughts:
>
> 1. The bindings should use Soft-DFS as it is much more resume friendly
> than DFS.
> 2. The bindings should be compiled with INDIRECT_STACK_STATES. That
> generally consumes much less memory and can scale well even on games of
> Der Katzenschwanz (excuse my poor German) and Die Schlange. BTW, I suggest
> that Die Schlange will be treated as Der Katz because Freecell Solver
> excpects games to be as close to Freecell as possible.
> 3. You should supply an initialization option to initialize the tests
> order, because it is a very useful option (see below).
>
> > The second file is an unrelated patch against the 1.4.1 source
> > tree - mainly fixing spelling errors and constifying some fields.
> >
>
> Applied.
>
> > The next step would be speeding up your algorithm ;-) I've had
> > a quick look but didn't get too far - what are you using,
> > brute force or some sort of alpha/beta pruning ?
> >
>
> Freecell Solver solves game using logical multi-moves (i.e: several
> supermoves that it thinks _might_ make sense). It can do it using either
> hard DFS, Soft (i.e: without procedural recursion) DFS, A*, or BFS. BFS
> does not work well because the number of possible states of distance N is
> too large to be effective, at least for multi-moves. A* gives mixed
> results.
>
> I have 1000 test boards at home and while limiting them to 150000
> iterations, I get that the linear average of A* is about 2 times of DFS.
> My main problem is finding a good weight function.
>
> In order to improve the algorithm, Dr. Tom Holroyd (who is
> subscribed to fc-solve-discuss) suggested using threads that will
> operate on the same state collection. Each thread will have a different
> tests order, or a different weight function, which will increase the
> chance that one of them will work.
Yes, fuck the CPU - we want threads :)
What is your current weight function? I still think that the multi-move
approach doesn't go well with A* speed wise. You're right that this
helps
reducing memory usage, but it also widens your search tree
Greetings, Stephan
--
Sitzen zwei Emanzen am Frühstückstisch. Sagt die eine zur anderen:
"Du, gib mir doch mal bitte die Salzstreuerin!"
Received on Tue Feb 13 2001 - 02:42:18 IST