[gnugo-devel] trying some OWL tuning

[Portela Fernand]

Hi again,

In order to exercize myself on GNU Go's source, I'm trying to look into
various regression failures. For most of them, I feel I'm yet not ready to
propose a hint or a solution. Here is a case where I have an analysis and
the beginning of a proposed solution.

[Sorry to be so noisy, with the time, the SNR of my posts will hopefully
improve :)]

The problem I'm looking into is 13x13.tst:20

At first sight (the Regression failure html views are just great!), it seems
that the moves connecting the F6 and G5 stones are largely overvalued. With
some tracing, it is possible to see that GNU Go considers the dragon L5 as
WEAKLY_ALIVE (?!) and hence appreciates greatly to connect it to a healthier
one.

Noticing the big lunch, I started looking at the code and found 2 spots in
dragon.c where I could make a small testing change in order to make the
engine more confident about this dragon.

[FYI only, this is NOT a patch. I didn't bother finding the best way to get
the size of the lunch for instance...]

- in make_dragons() :
#if 1
    else if ((2 * true_genus + dragon2[d].moyo_size_pre_owl
              + 2 * (dragon2[d].lunch != NO_MOVE ? 
                       (countstones(dragon2[d].lunch) > 4 ? 2 : 1) 
                       : 0) < 8
              && dragon2[d].escape_route < 10)
             || (dragon[origin].owl_threat_status == CAN_THREATEN_ATTACK)) {
#else
    else if ((2 * true_genus + dragon2[d].moyo_size_pre_owl
              + 2 * (dragon2[d].lunch != NO_MOVE) < 8
              && dragon2[d].escape_route < 10)
             || (dragon[origin].owl_threat_status == CAN_THREATEN_ATTACK)) {
#endif

- in compute_dragon_weakness_value()
#if 1
  float true_genus = (((float) dragon2[d].genus)
                      + 0.5 * ((float) dragon2[d].heyes
                               + (dragon2[d].lunch != NO_MOVE ? 
                                   (countstones(dragon2[d].lunch) > 4 ?
                                       2.0 : 1.0)
                                   : 0.0)));
#else
  float true_genus = (((float) dragon2[d].genus)
                      + 0.5 * ((float) dragon2[d].heyes
                               + (dragon2[d].lunch != NO_MOVE ? 1.0 :
0.0)));
#endif

This didn't change the returned move for this test, but at least the
valuation dropped by about 10 points for these connecting moves.

Busy elsewhere, I happened to let run the entire regression tests and when
I came back, I only discovered a deceptive single FAIL :
strategy3.tst:126

Interestingly, it's related, since the same signs appear here too :
- a group of connecting moves is strangely overvalued around H17
- there's a big lunch (well, this one isn't dead yet)

A short analysis showed that my small changes made the correct move (B19)
a little less urgent, since the dragon is considered more secure and the
valuation of that move dropped just enough to make H17 the top one.


Questions :
- am I on the right track ?
- any suggestions about where to look at for these connection valuations ?

/nando