> I don't remember from the earlier description; are the searches being done
> depth-first or breadth-first? If breadth-first, then there is no reason to
> put an upper limit on the number of moves for finding a phase1 solution,
> since the algorithm HAS to solve phase1 in order to find an overall solution.
I do depth-first. I think the breadth of the tree is much too large to be
handled in breadth first fashion (currently I abort the program when it
reaches a length in phase 1 such that the number of solutions is a few
> Once you have an overall solution, of course, the length of phase1+phase2
> solution can be used as an upper bound on subsequent phase1 solutions.
> Also, do you reduce the "maximum number of moves" for phase2 based on
> solutions already found? For instance, once you have found a combined
> phase1+phase2 solution in 20 moves, then if you find an alternative phase1
> solution in 14 moves there is no reason to look deeper than 5 moves in
> phase2 (or 6 if you want to find all solutions that tie for minimum length).
Also done, I do not look for ties.