gnugo-devel
[Top][All Lists]
Advanced

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

Re: [gnugo-devel] fast_defense() improvement


From: nando
Subject: Re: [gnugo-devel] fast_defense() improvement
Date: Sun, 30 May 2004 01:40:57 +0200

Hi again,

I didn't expect a reply that soon, thanks for checking.

On Sun, May 30, 2004 at 12:59:49AM +0300, Paul Pogonyshev wrote:
>  
> > - new function count_adj_stones() in board.c
> 
> I would prefer count_adjacent_stones().

Agreed.

> (libs[0] == lib) instead of liberty_of_string() seems better.

Ah, I missed that one, good point, thanks.

> However, I don't understand why this check is needed at all: if you run
> into snapback, you only don't get enough liberties to reach `goal_liberties'
> or am I missing something?

You can just try. Omit the test and you'll get a bogus PASS in reading:194
and maybe some other problems elsewhere. It's bogus because the reading code
believes it won when the string has actually been caught in a snapback. But
this is clearly related to the next issue.

> This looks risky.

Possibly.

> First of all, I cannot read this, at least quickly enough. 

You're right, it lacks some comments. I'll try to document it better.

> And secondly, the attacker gives up when _the attacked_
> string gains 5 (or 4) liberties, it doesn't consider adjacent strings
> in this respect.  So you seem to introduce deviations from "normal"
> `reading.c' logic here.  Maybe this also explains your snapback test
> above, but then it seems like another reason to drop these
> complications.

The idea is following : once we've eliminated risks like kos and snapbacks,
it is assumed that the capture will connect the surrounding friendly
strings. So that part of the code tries to sum up the liberties of all these
strings, with a couple adjustements. For instance, the mw[] array gives a
hint that the move at lib already connects some strings (if mw[lib] >= 2),
so no penalty in that case.

This is indeed a bit different than the usual reading.c logic. This portion
of code tries to use the properties of the resulting superstring, given the
confidence that it can't be cut or that the liberties potential can't be
significantly reduced. I thought it was worth a try and results in
regressions are good, but granted, that can't be taken as a proof.
 
> Can you verify if this part gives any serious improvement?  Maybe we
> can live with the simpler things, counting only direct liberties?

I believe that part gives indeed some serious speed improvements. I can rerun
the regressions to make sure. Will do.

nando




reply via email to

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