gnugo-devel
[Top][All Lists]
Advanced

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

Réf. : Re: [gnugo-devel] GnuGO 3.4 : moves to consider


From: Emmanuel BERANGER
Subject: Réf. : Re: [gnugo-devel] GnuGO 3.4 : moves to consider
Date: Thu, 28 Aug 2003 12:53:49 +0100


Hello,

Thanks for your answer. Glad it proves interesting.

I sincerily hope you can bring some improvement to gnugo from this (but I
reckon the position in game 1 with the quad-cut at H8 is fairly intricate
!)

BTW, I sometimes go to the computer ladder page, but it does not seem very
active ...
And computer go events are not very much advertised ...
Have you compared 3.4 to other proggies ?

Regards

Emmanuel

PS : some day, qGo should have its GTP interface implemented ...





address@hidden on 27/08/2003 19:32:03

Pour : Emmanuel BERANGER/A/EDFGDF/address@hidden, address@hidden
cc :
Objet :     Re: [gnugo-devel] GnuGO 3.4 : moves to consider


On Wed, 27 Aug 2003, Emmanuel BERANGER wrote:

> Hello,
>
> I've been playing GNUGO 3.4 recently. (windows version, from Teun Burgers
> site)
> Among the several games I played, I think worth mentionning two of them,
in
> which GNUGO made what I would call "braindead tenuki" ...
>
> Other than that, for the kyu player I am, I particularly reckon its
ability
> at cutting shapes and kill small groups :-)
>
> Please take a look at moves 181-182 in file 1, and 117-118 in file 2.
>
>
> As an option, one could also consider 199-200 in file 1, but this is less
> of an obvious mistake

These are indeed interesting mistakes for gnugo; thanks for sending them.

In the first error (game 1, move 182) gnugo for some reason believes that
N11 wins the semeai between D8 and L10 (obviously an error); Q5 is the
second highest move at 55 points instead of 88 for N11.

At move 200, gnugo properly understands that Q2 does not save the black
group; it also properly understands that white wins the capturing race
between L10 and Q4.  However, it also thinks that Q2 kills L10 (?!).

The problem in the second one is a problem of the persistent cache; gnugo
reads things earlier in the game, and then fails to update when the board
changes.  If the game is replayed from move 112, gnugo produces the game
move; if given the position without any leadup, it plays H7 (the correct
move).

Thanks

 Evan Daniel









reply via email to

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