In a message dated 12/18/01 8:46:14 AM Pacific Standard Time,
shlomif_at_vipe.technion.ac.il writes:
> Why don't you release (or give verbatim copies of it to individuals) your
> solver, yet? You may care to look at the following article:
> http://www.tuxedo.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/
> Which gives an explanation why I think you should release your solver now
> as it is. In any case, is there a specific reason that you don't?
Hi, Shlomi. Thanks for asking.
I cannot yet release my solver because:
1. It is not fit for use by anyone else. Right now everything is controlled
by compiler switches -- freecells, search method, solution depth,
transposition table discard, automoves, MS moves vs. robust moves, game
range, statistics subset, progress monitoring, many more. About a third of
the code is experimental. Much of the code is concerned with statistics. Some
of the code (blocked off by c or c++ comments) is just dead and will be
removed. I do believe in frequent beta release, but my solver is not yet
ready for beta testing. Many changes have already been made so that it can be
released eventually. Example: it can now run on any size memory.
2. Improvements are frequent. As I played out the 54-move solution to MS deal
164, zero freecells, I discovered a way of making better decisions. The
change won't find a shorter solution, but it will find the first solution
sooner. (That's my current assessment. Programmers have been called
notoriously poor guessers. Most of my guesses have been accurate in the past,
if only that a change has usually resulted in some improvement. The degree of
improvement has sometimes been smaller than expected, occasionally
spectacular.)
3. Other solvers will appropriate some of my tactics; then all solvers will
be pretty much the same. That will be fine after I publish my results. Not
now.
4. One of my major algorithms is amateurish in that it is greedy rather than
optimal. Must fix that. That will be where most of my doubled speed will come
from. The algorithm is not actually visible in the code, but the greedy
approach is responsible for much of my speed; the optimal approach will be
much faster.
Bill Raymond
Received on Tue Dec 18 2001 - 16:31:15 IST