>I came at it from another direction, starting out caching the board state (equivalent to @state) for each board seen. [In most cases, there are several "paths" to a given board state.
I also used some other speedups, like precomputing the jump neighbors for each hole, and computing all rotations/reflections of each board and caching all of them (there are 5 equivalents for each board state, besides itself).
The problem space soon blows up rather large for larger board sizes. For instance, I've seen it run out of memory on a large machine (caching boards) for N=7 (7 pegs on a side, 28 holes total), having cached about 1M boards.
I think you could either use your hard disk for caching (I know it's slower, but CPU&time may not be the limiting factor) or think about using a more compact representation of the board - What about a bit string? Or a C-style array? There are modules for that. Oh, and pack/unpack are friends. :)
But N=8 finds a solution in a few minutes. Stopping at the first solution, it doesn't run out of memory.
I'm working on balancing time and memory so that larger N will still find a solution in a reasonable time, but not run out of memory.
I've had similar problems to work on. It was the n-dames problem in Haskell then (for CS I). We were to reduce the number of required memory cells and reductions to below 2M each for a board size of 19.
I just wished I had had the option of switching to an arbitrary language then...
Steffen
--
sub'_{q} tsuJ}}_();sub's{seek+DATA,0,0}sub'p{print&_}sub'r{reverse$_[0]}
@_=(('')x2,split" ",<DATA>);s!!&s,$_=<DATA>;s/}.*?}/$_[$s+1]/
if$s;s/(}.*?})/r$1/e;eval$_;p,[EMAIL PROTECTED];
__DATA__
} rehtona} } lreP} },rekcah}