Re: [gnugo-devel] Strong non-linear behavior?

[Gunnar Farneback]

SP Lee wrote:
> I was using cygwin and run gnugo in gtp mode. The following gtp commands 
> were used
> [...]

Ok, with those I can reproduce it too.

> It's strange that if I saved the positions after white J1 to another sgf 
> file and load it again, gnugo CAN find the right black move F1.

It's enlightening to compare the move reasons in the two scenarios. In
the first one we have:

Move at F1 attacks D4
Move at F1 attacks F3
Move at F1 defends H3
Move at F1 owl-defends H3
Move at F1 connects D3 and H3
Move at F1 connects G4 and H3
Move at F1 cuts H4 and F3
Move at F1 cuts F3 and J1

and in the second one:

Move at F1 attacks D4
Move at F1 attacks F3
Move at F1 defends H3
Move at F1 owl-attacks F3
Move at F1 owl-defends H3
Move at F1 connects D3 and H3
Move at F1 connects G4 and H3
Move at F1 cuts H4 and F3
Move at F1 cuts F3 and J1
Move at F1 strategically defends C14

The significant difference is that the owl attack of F3 move reason is
missing in the first scenario. Running with -d0x1000 we can see that
no owl reading at all is performed for F3 in the first scenario, which
means that the result was fetched from the persistent cache. More
precisely the persistent cache must have had an owl attack but no owl
defense since F3 is actually considered dead already. Running with
-d0x200000 we see this entry:

 Stored result in cache (entry 33):
movenum         = 90
tactical_nodes  = 3518
routine         = OWL_DEFEND
(apos)          = F3
(bpos)          = PASS
(cpos)          = PASS
result          = 0
(move)          = PASS
(move2)         = PASS
   A B C D E F G H J K L M N O P Q R S T
19 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 19
18 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 18
17 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 17
16 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 16
15 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 15
14 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 14
13 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 13
12 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 12
11 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 11
10 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 10
 9 ? ? ? X ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 9
 8 ? ? ? X ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 8
 7 ? ? ? X ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 7
 6 ? ? ? X X . ? ? ? ? ? ? ? ? ? ? ? ? ? 6
 5 ? ? X . . x . ? ? ? ? ? ? ? ? ? ? ? ? 5
 4 ? X X o . . x ? ? ? ? ? ? ? ? ? ? ? ? 4
 3 ? X ? x .[o]o x x ? ? ? ? ? ? ? ? ? ? 3
 2 ? X ? x . o x x . ? ? ? ? ? ? ? ? ? ? 2
 1 ? ? . . . . x . ? ? ? ? ? ? ? ? ? ? ? 1
   A B C D E F G H J K L M N O P Q R S T

I think the conclusion is that we should either purge owl results
which have been overruled by semeai reading from the persistent owl
cache, or maybe better keep them but extend the active area to cover
the entire semeai.

In summary: This is not a valuation problem but a persistent caching
problem.

/Gunnar