gnugo-devel
[Top][All Lists]
Advanced

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

RE: [gnugo-devel] nando_3_17.6


From: Portela Fernand
Subject: RE: [gnugo-devel] nando_3_17.6
Date: Sat, 15 Feb 2003 20:24:56 +0100

Arend wrote:

> I vote for making it default, although maybe not immediately. The
> only case where I see the need to disable it is for tournament games.
> (In particular, I think it would be nice to allow resignation of NNGS
> games -- if only to see whether it is working well.)

Yup, making it default should be conditioned on the proof that it works
correctly on NNGS. I don't know which interfacing software Gunnar is using
to connect it. If it needs modifications to handle it, I can try
to patch it, as soon as I know what is to be patched of course.

> Maybe it would be cleaner not to disable resign_allowed in the
> playing modes that don't support it, but instead simply ignore the
> negative move value in the interface code.

I chose the line of the least amount of changes and the work is still
not finished, as there are changes to be made in other playing modes.
I'll look into implementing it the way you suggest.

> Do I understand correctly that you compare GNU Go's valuation of the
> "perfect" move with the move played by GNU Go? Yes, that looks
> useful.

Correct.

> My impression is that your policy so far is pretty conservative. If
> we want to allow GNU Go to resign earlier on, making a couple of
> settings more aggressive, then we might need to take the handicap
> into account.

Possibly, but I think we should do our best to find a way to ignore
them and still get correct results if we can, and only if it proves
impossible to do so, then consider taking handicap into account.

> (At the moment, we will mostly save the endgame, which usually
> doesn't take very long anyway.)

Indeed, but that's just what I was humbly looking for in the first
place, e.g. prevent GG from playing out a 100% meaningless yose.

/nando





reply via email to

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