gnugo-devel
[Top][All Lists]
Advanced

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

Re: [gnugo-devel] atari-atari status?


From: Gunnar Farneback
Subject: Re: [gnugo-devel] atari-atari status?
Date: Wed, 16 Jan 2002 17:50:58 +0100
User-agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/20.7 (sparc-sun-solaris2.7) (with unibyte mode)

Trevor wrote:
> What's the status of the atari-atari code?  Is it stable enough
> to be worth my examining?

I have some rather extensive revisions coming up. You'd better wait
for those.

> It still has some weaknesses, for example:
> 
> Invalid blunder:
>   trevorc:270
>   trevorc:440
>   trevorc:800

These three pass with my changes.

>   trevorc:1000

I don't understand this problem. GNU Go wants to capture the ko at N9
and this certainly looks biggest to me. The listed moves all look like
ko threats, but there's no need for that at this time.

> ATARI_ATARI mistake:
>   trevorc:500

I don't understand the answer to this problem either. I agree that
there is a combination attack at D8 and that the best defense against
it is E7, but it looks bigger to play J2 than to save the D7 stone.

Dan wrote:
> Yes. Gunnar and Inge have been working on it. It's called and
> finds moves in almost every game. One thing that should be
> considered a FIXME is that currently it can find at most
> one combination per move.

Here are some more:

1. The valuation can only be done properly if the move valuation is
passed a list of the involved strings, from which it can decide which
one is most likely to become sacrificed and the exact value of it.

2. It's necessary to find virtually every defense move against a
combination attack for the opponent. Currently only a few defense
moves are identified and there are several test cases where that's not
enough.

3. It's pointless to try combinations of attack threats which are not
related. With lots of threats on the board we get into a needless
combinatorial explosion, which potentially may be time consuming but
more importantly makes it hard to debug real mistakes.

My current work solves item 3 (in one example the number of
atari_atari variations was reduced from 3000 to 60) and improves the
move valuation, but still without doing it right as outlined in item
1.

/Gunnar



reply via email to

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