Re: [gnugo-devel] Re: [computer-go] Parallel lookahead with GNU Go

[Gunnar Farneback]

David wrote:
> We had been using get_initial_influence in 3.2 and now use get_influence
> in 3.4. get_initial_influence cared very much when it was called (assert
> failure), but get_influence seems not to be so picky.

Ah, you're well into the internals, then you had better know what
you're doing. :-)

> In some way you could think of what we had as 3.2 with an overweighted
> tendency to play a big influence dominated game. It clearly often
> ignored moves with tactical urgency. I am guessing that 3.4 has a
> better sense of balance that lets it attack the big open groups that
> our particular lookahead has selected, but that 3.2 had evaluated as
> too strong to attack. But we are just guessing because we try to
> minimize our changes to GNU Go code, so we don't know it very well.

Might be a plausible explanation but I couldn't say without seeing a
few games. An evaluation function which doesn't take dragon weaknesses
into account would certainly be prone to getting into big trouble now
and then.

> We had first put our hook for our multiprocessor code into
> gnugo_genmove, which is almost always the path to genmove. But
> interface/play_gtp.c calls genmove directly, missing our hook. Why did
> you folks do that?

For various historical reasons but basically the GTP interface
accesses so many parts of the engine that using the gnugo_*
trampolines for a few of them is pointless. Personally I consider the
trampolines mostly useless in general, although there are differing
opinions about that.

> We just ran into our first win by resignation, which does not give us
> a score. Has anything changed in the resign code?

It certainly has. It has been implemented at all for a start. :-)
But by default it should be turned off so I don't know why you're
seeing resignations.


How are you doing the multiprocessing? Is it entirely at the genmove()
level? Are you able to reuse the contents of the persistent reading
caches?

/Gunnar