Re: [gnugo-devel] reading.c / special_rescue_moves

[Gunnar Farneback]

Martin wrote:
> I have investigated reading.c to see whether it could be easily modified
> to see that the double-bamboo-joint would save the left-most string. I
> have stumbled upon special_rescue_moves(), which supposedly adds
> second-order liberties as move candidates - exactly what I want.
> Unfortunately, it also verifies that an X stone at the respective
> first-order liberty could be trivially captured, which is not the case
> for my example, but works well for the examples given in the source. As
> this test is only meant to optimise away unnecessary branches, removing
> it should be a conservative modification.

You're right on track, although this specific change turns out to be
too expensive.

> That's four unexpected PASSES against three unexpected FAILS - at least
> a net gain. What puzzles me, however, is how considering more
> possibilities in a brute-force search can worsen the result in any case
> at all.

Evan has explained this well, nothing for me to add here.

> Am I missing some assumption here about what defences should _not_
> be found for some reason?

No, defenses should be found if they exist. The only exceptions are
performance tradeoffs and the issue of balance between attack moves
and defense moves. If adding a defense move in the reading causes a
lot of valid attacks to no longer be found, it may be more severe than
missing a valid defense. However, generally speaking it's better to
miss an attack than a defense. The reason for this is that the goal of
attacking (removing the string) is more definite than the goal of
defense (reaching five liberties or fewer at large depths), so the
higher levels of reading (connection, owl, semeai) can easier cope
with a false defense than with a false attack.

> Furthermore, is there a nice possibility to do some automated
> benchmarking to get some measure of how big the performance impact of
> this modification is?

As Evan said, regress.pike provides such features. In order to run it
you need to have Pike installed. If it's not packaged with your Linux
distribution you can download it from http://pike.ida.liu.se.

In this case the performance impact is quite big. The number of
reading nodes used by reading.tst increases by 50%, which simply is
too much for a minor improvement. My suggestion is that you instead
try to add a move generator for more specific bamboo joint moves.
Hopefully this would give some new passes at only a small performance
cost.

/Gunnar