Re: [gnugo-devel] A very annoying bug

[Arend Bayer]

Gunnar wrote:
> In the handtalk game handtalk12.sgf (available in CVS), GNU Go was hit
> by a bug (sort of) that is more than a little annoying. This does not
> happen very frequently, thankfully, but when it happens it can be very
> devastating. The first loss in the Computer Go Ladder against Indigo
> long ago was directly caused by the same kind of problem.

Thanks for explaining this. Btw, the bug could easily have caused a bigger
loss if handtalk had at some point found the move at O15/N19.

> What can we do to solve this problem?
> * First we can of course fix the mistake by small_semeai(), which we
>   should do anyway. This doesn't do anything about the potential for
>   escalated problems though.
> * Second we can turn off the search for additional attack/defense
>   points. This would solve the problem but would probably cause a
>   substantial decrease in playing strength.
> * Third we can avoid testing completely irrelevant moves for
>   additional attack/defense points. This could in theory be
>   implemented using the active areas in the persistent cache. In
>   practice there are complications due to the facts that the active
>   areas aren't very sharp and that the persistent cache is selective
>   and doesn't store entries for all reads. In summary this is a good
>   idea in principle but with implementation difficulties. It's unclear
>   whether it will be possible to completely eliminate the problem in
>   this way, but it should definitely suffice to reduce it. It should
>   also help to improve speed somewhat.

I've recently considered using the active areas for s.th. completely
different. It strikes me that they might be the way to measure the aji of
dead stones/danger of alive stones. I'd dream of helping GNU Go to play
honte this way.
The idea would be to not simply add a strategic penalty proportional to
the size of the active area, but to use the active area directly in the
influence computation. For example, if the attack on some alive white
stones produces a big active area, I'd suggest to reduce the white
permeability. (Note: The area used here should probably be a lot smaller
the current "active area" in the persistent reading cache.)

Also, I have experimented with setting the persistent reading cache size
to 1000. The result was a save in reading nodes of ~8%, but a decrease in
performance. I didn't check, but I'd assume that this is due to added costs
when searching through the cache. This can be cured by adding a hash
value to the persistent cache entries. If we then increase the cache size,
the problem with the selectivity could be solved as well.

> * Fourth we should try to eliminate the need for (a separate)
>   small_semeai(). The real root of the problem is that the tactical
>   reading code doesn't have sole responsibility for the tactical
>   analysis. Changing this should robustly solve the problem.
In other words, the problem is that the analysis in
find_more_attack_and_defense_moves works differently than the one in
make_worms, and the other solution would be to re-run small_semai when
checking for additional attack/defense moves. But I agree that it would be
best to make small_semeai mostly unnecessary: Its other drawback is that
it gets only called for tactical semeais existing at stackp==0, while 
semeais can also occur later after some breack_chain_...-type move.
(Several failures of the (rare) tactical reading mistakes I have seen are due
to this problem.)

The list of plans for 3.3 is growing... :-)

Arend