[gnugo-devel] persistent cache test ninestones:670

[Arend Bayer]

ninestones:670 is the following test:

reg_genmove black
play black A4
play white F6
reg_genmove black
play black F7
play white E6
reg_genmove black
play black C8
play white G7
670 reg_genmove black

   A B C D E F G H J K L M N O P Q R S T
19 . . . . . . . . . . . . . . . . . . . 19
18 . . . . . . . . . . . . . . . . . . . 18
17 . . . . O X O . . . . . O . . . . . . 17
16 . . . X X X O X . X . . . . X X . . . 16
15 . . X . . X X O . . . . X . . . . . . 15
14 . . . O O O . O O O . . . . . . . . . 14
13 . . . X X O . O X . . . . . . . . . . 13
12 . . . . . X . . . . . X . X . . . . . 12
11 . . . . O . X . . . . . . . . . . . . 11     WHITE (O) has captured 2 stones
10 . . . X . . . . . X . . . O . X . . . 10     BLACK (X) has captured 3 stones
 9 . . . . . . . . . . . . . . . . . . . 9
 8 . . X . . X . . O . . . . . . X . . . 8
 7 . . . . X X O . . . . . . . . . . . . 7
 6 . . O O O O X X O O . . O . . X . X . 6
 5 . . . X . X O O X O O O . . X . . . . 5
 4 X O O X X X O . X X X O O X . X . O . 4
 3 . X X X O O O X X O O O O O X O O . . 3
 2 . . X O . O X X X X X X O X X X O X O 2
 1 . . . . O X X X . X O O O O . . . O . 1
   A B C D E F G H J K L M N O P Q R S T

The rational is that this was a persistent cache problem, and the sequence
above was at the time sufficient to reproduce the problem.

I think this just doesn't work. There are too many random reasons why this
test could pass without the underlying problem being fixed. In fact, it passes
now, and I don't think anyone knows whether it has been fixed.


If someone wants to improve persistent caching (that would be a really good
thing!!), there is an easy measure by which to measure success: replay a
game (1), then replay it with a clear_cache between any two moves (2). A good
persistent cache can be measured by a good node reduction for (1), while
giving a high percentage of identical moves  between (1) and (2).

Arend