On Thu, Mar 6, 2008 at 9:02 PM, terry mcintyre <[EMAIL PROTECTED]> wrote: > Often, when I study sprawling groups in the middle > game, I have found that gnugo --decide-dragon-status > will fail with an uncertain result, but if I increase > the owl-node-limits and semeai-node-limits to 10k, > gnugo finds a resolution to the problem in a matter of > seconds. I sall run gnugo's solutions past stronger > players, but at the moment, they look reasonable to > me; certainly they are playable against low kyu > opponents. > > I suspect that gnugo's limits were tuned for slower > processors and smaller memory sets. Now that machines > come "off the shelf" with 3 gigabytes of RAM, perhaps > it's time to revisit those parameters. A 10 megabyte > cache ( the default ) seems too parsimonious. > > If traditional programs were to fully use the RAM now > available, building trees with tens or hundreds of > thousands of nodes, it looks to me like their middle > game on a 19x19 board might impress dan-level players.
Do you have specific positions in mind? Cases where increasing the node limits improves the move that gets played (and especially where it degrades it) are interesting. I ran the GNU Go regression test suite with these settings: Owl node limit: 20000 Semeai node limit: 10000 Cache size: 32 MB and got a regression delta of 42 [unexpected] PASS, 37 [unexpected] FAIL. It also took approximately twice as long (imprecise measurement). Of course, some of those FAILs may well represent an improved understanding of the situation that is still imperfect, but has managed to uncover other flaws. The real question, of course, is whether that's the best way for GNU Go to spend the extra time -- and I have no answer for that :) Evan Daniel _______________________________________________ computer-go mailing list [email protected] http://www.computer-go.org/mailman/listinfo/computer-go/
