Terry wrote:
Regressions are not run often ...
On the contrary regressions are run frequently to try out new patches.
It may not be run often, or at all, by ordinary users but for
developers the regression run time has a big impact on the
productivity. This does not mean that it's automatically wrong to slow
down the regressions but we need to be careful about it.
it would be more pertinent to ask a) whether gnugo picks better
moves with a higher node limit,
In general it can be expected not to do worse on average, at least.
But as long we are doing selective search with heuristic evaluation of
the leaf nodes there will always be anomalies where a deeper search
gives a worse result.
More important here is the fact that the semeai reading tends to have
a high branching factor. My feeling is that for the simpler semeais,
the node limit is not much of a problem, while for complex semeais the
node limit can be increased a lot and still be insufficient. There's
certainly a class of semeais where changes in the 500-2000 range are
significant but the question is how often we encounter those.
and b) whether the cost time-wise is acceptable for ordinary usage.
I'm more interested in the question which ways to slow down the engine
have most impact on the playing strength. Maybe large-scale (ticket
#29), a new dragon amalgamation algorithm (#97) or Alain's twin option
(#104) are better places to spend time. Or maybe just increasing some
depth parameter (e.g. ko_depth).
/Gunnar
_______________________________________________
gnugo-devel mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/gnugo-devel