gnugo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: david doshay
Subject: [gnugo-devel] Re: [computer-go] Parallel lookahead with GNU Go
Date: Tue, 16 Dec 2003 16:27:49 -0800


On Tuesday, December 16, 2003, at 03:19  PM, Gunnar Farnebäck wrote:

David wrote:
 I would guess that it is only of interest to GNU Go developers.

If people here are not otherwise interested, you can always send a
report to the GNU Go development list, address@hidden We are of
course interested and can provide feedback on your set-up.

We will when we think we have something of more substance.


GNU Go 3.4 does not have the influence function we had been using,

This confuses me. I can't remember any influence function disappearing
between 3.2 and 3.4. What exactly are you using? (Better move this to
the GNU Go list.)

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.

so we played our modified 3.2-with-lookahead against 3.4. 3.4
trounced 3.2 with lookahead by over a 100 point margin. We only did
the one run.

One run indicates nothing; that is certainly not a typical result
between 3.4 and 3.2 (without lookahead). But of course you should base
your experiments on the most recent release.


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.


other questions:

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?

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

Our integration with 3.4 is now done, and we have played 2 games. One
win by resign, one loss by 0.5.

Thanks,
David





reply via email to

[Prev in Thread] Current Thread [Next in Thread]