owl reading cutoff (was: Re: [gnugo-devel] vital owl defense)

[Arend Bayer]

I wrote:
> Gunnar wrote:
>
> > I'm currently seeing a huge and rather negative regression delta,
> > including
>
> > Backing out arend_3_12.5 all of these disappear. Did something go
> > wrong with this patch?
>
> Sorry. I installed a wrong version of the patch. Reverting the hunk
> below should fix it. I'll cross-check and put it in CVS tomorrow.

Maybe I should explain my motivation for trying the patch below.
Deep reading only performs well with adequate cutoff strategies, the
earlier we can declare victory for either side, the better.

While we have a fine-grained cutoff policy to declare the owl defender
alive, we don't do much way the other way round. When it is unlikely
for the defender to get two eyes, we try less (i.e. only reasonably
high valued) vital defense moves, but we don't do this for shape moves.
I.e. we keep reading as long as the defender can generate shape moves,
no matter how dead he is.

But unfortunately, the experiment below didn't work at all. It would be
worth trying to make eyemax more optimistic, so that eyemax == 0 really
means s.th. This could do wonders to owl performance.

I don't think I will do anything about this myself in the near future,
so if anyone more familiar with the optics code wants to look into
this...

Arend

> Index: engine/owl.c
> ===================================================================
> RCS file: /cvsroot/gnugo/gnugo/engine/owl.c,v
> retrieving revision 1.121
> diff -u -p -r1.121 owl.c
> --- engine/owl.c      15 Nov 2002 19:39:45 -0000      1.121
> +++ engine/owl.c      16 Nov 2002 19:39:49 -0000
> @@ -1984,6 +1988,12 @@ do_owl_defend(int str, int *move, int *w
>       READ_RETURN(read_result, move, shape_moves[0].pos, WIN);
>        }
>        moves = shape_moves;
> +
> +      if (eyemax == 0 && escape_route == 0)
> +     move_cutoff = 67;
> +      else if (eyemax <= 1 && escape_route <= 2)
> +     move_cutoff = 32;
> +
>        break;
>
>      case 0: