		     REVIEW OF THE READING TESTS

The purpose of this review is to collect comments about the
reading related tests in the test suites reading.tst, owl.tst, and
ld_owl.tst.

2.7.195 fails the following tests:

reading.tst # 12, 27, 28, 30, 32, 37, 38, 52, 53, 54, 55, 58, 59, 60,
              64, 65, 88, 92, 94, 95, 96, 118, 119, 122, 123, 124,
              130, 131, 134
owl.tst     # 4, 57, 58, 65, 111, 114, 115, 117, 132, 135, 138, 140,
              141, 142, 147, 149, 156, 157, 164
ld_owl.tst  # 52, 64

2.7.205 fails the following tests:

reading.tst # 27, 28, 30, 32, 37, 38, 52, 53, 54, 55, 58, 59, 60,
              64, 65, 88, 92, 94, 95, 96, 118, 119, 122, 124,
              130, 131, 134, 135
owl.tst     # 4, 57, 65, 80!, 111, 114, 115, 117, 132, 140, 141, 142,
              156, 166
ld_owl.tst  # 26, 64, 159, 179, 182, 183, 186, 188, 190, 193, 196, 197


			     READING.TST

# 27 LOW PRIORITY; DEFER

     Solve test case 28 first.

     2.7.207: This test passes.

# 28 LOW PRIORITY; DEFER
gnugo -l incident42.sgf --quiet -L89 --decidestring P16 -o vars.sgf

     Solve test case 92 first.

     Since the move at S15 was actually played, this test could be written:
        loadsgf games/incident42.sgf 89
        28 defend P16
     except that there is a depth difference of one, which may or may
     not matter. This is test case 92.

     2.7.207: This test passes.

# 30 LOW PRIORITY; MODERATE DIFFICULTY
gnugo -l incident118.sgf --quiet -L252 --decidestring J10 -o vars.sgf

     This can probably be fixed using superstring technology but
     it	may not be worth the nodes to do so. GNU Go 2.7.204 finds
     the attack at J1 on H1 but does not find the defense of J10.
     Still it makes the correct move.

# 37 LOW PRIORITY; DIFFICULTY UNKNOWN; Superstring moves

     Indirect moves at superstring liberties are needed, but at a too
     large depth

# 38 LOW PRIORITY; DIFFICULTY UNKNOWN; Superstring moves

     Superstring moves should be able to solve this.

     2.7.210: The variation B L9, W N4 ought to be generated by the
              superstring code, but isn't.

# 64 LOW PRIORITY; MODERATE DIFFICULTY; depth limit reached
gnugo -l nicklas/nicklas11.sgf -L 244 --quiet --decidestring P8 -o vars.sgf

     The ineffective chain breaking move at R3 succeeds (after
     followups on S3 and T2) in pushing stackp beyond backfill2_depth
     when the time comes for the relevant variation starting with N1.
     Increasing backfill2_depth to 7 solves this test, but is very
     expensive.

# 65 LOW PRIORITY; MODERATE DIFFICULTY; depth limit reached
gnugo -l reading06.sgf --quiet --decidestring S5 -o vars.sgf

     This is solved simply by increasing backfill_depth to 13.

# 92 LOW PRIORITY; MODERATE DIFFICULTY
gnugo -l incident42.sgf --quiet -L89 --decidestring P16 -o vars.sgf

     The correct move at T15 is actually tried in the course of
     attacking S17. This variation leads to seki, and the reading
     code does not notice that seki is good enough to save P16.

     2.7.207: This test passes.

# 131 LOW PRIORITY; DEFER

     Solve test case 138 first.

     2.7.207: This test passes.

# 134 LOW PRIORITY; DEFER

     Solve test case 137 first.

     2.7.207: This test still fails although 137 has been solved. This
              is probably a problem with depth limits.

# 137 LOW PRIORITY; HARD

     Critical back-capturing moves are neglected.

     2.7.207: This test passes but requires about 12000 nodes,
              although the position is very tidy. There is much to win
              from an improved move ordering.


# 138 MEDIUM PRIORITY; EASY

     Defending edge connection neglected. This could be solved by a
     new special_rescue3 type function, looking for the pattern

     ---
     .*.
     OXO

     where the left O belongs to the attacked string and where a
     subsequent X move to the left of * wouldn't get more than two
     liberties.

     2.7.207: This test passes.

# 139 HIGH PRIORITY; DIFFICULTY UNKNOWN

     Requires backfilling in break_chain2. The difficulty lies in
     implementing this without a combinatorial explosion.


			       OWL.TST

# 4 MEDIUM PRIORITY; DIFFICULTY UNKNOWN; Tuning

The variations become quite tricky and hard to follow when black
destroys the eyespace at A12 and white tries to break out.

# 57 LOW PRIORITY; HARD; Semeai
# 58 LOW PRIORITY; HARD; Semeai

These should be reclassified as semeais.

# 65 LOW PRIORITY; HARD

This is impossible to solve without redoing the connection analysis
at each variation.

# 80

Not yet analyzed

# 111 LOW PRIORITY; HARD

There are several problems here. One is that the owl code would need
to analyze connections at every move to see if some part gets
disconnected. The other problem is that there are too many separate
places to try moves, so that the node limit is reached much too fast.

# 114 LOW PRIORITY; EASY OR HARD

This might be possible to solve by tuning, but it seems more proper to
reclassify it as a semeai problem.

# 115 ACCEPTABLE

It's open for discussion whether this should have result code 2 or
3. Nominally it would be 2 since black has to find the first ko
threat, but having multiple internal threats it turns out that white
must find the first external ko threat.

# 117 LOW PRIORITY; HARD

The dragon falls to a sequence of ataris. This is very hard to do
right, since routinely trying every atari around would consume far too
many nodes.

# 132 

Not yet reviewed.

# 135 HIGH PRIORITY; EASY; Tuning

    2.7.205: This test passes

# 138 ACCEPTABLE

The difference between J5 and E2 is not important at this time.

    2.7.205: This test passes

# 140 LOW PRIORITY; HARD; Eyespace evaluation

After G9, it looks like black has one secure eye at G8 and a
completely enclosed eyespace in the rest of the corner which should be
worth at least one eye. In practice, however, these eyespaces are
highly dependent and are only worth 1.5 eyes.

It's possible to workaround this problem with tuning, but this doesn't
seem very productive.

# 141 LOW PRIORITY; HARD; Eyespace evaluation
# 142 LOW PRIORITY; HARD; Eyespace evaluation

This is exactly the same problem as in 140. Here it's not possible to
tune around it.

# 147 HIGH PRIORITY; EASY OR HARD; Tuning or eyespace creation

The vital move at A5 is missed because make_domains() produces a
useless eye shape. To fix this is hard but can be worked around by
tuning.

    2.7.205: This test passes, but probably not for the right reason.

# 149 HIGH PRIORITY; MODERATE DIFFICULTY; Tuning

The problem here is that too many moves are tested, leading to the
node limit being hit. The reading tree needs to be pruned. Also
someone who is strong at reading should verify that there is indeed no
defense.

    2.7.205: This test passes.

# 154 HIGH PRIORITY; HARD
# 155 HIGH PRIORITY; HARD

Since P15 is considered inessential, the eyespace around it is assumed
to be a secure eye and the whole dragon to be alive with two safe
eyes. The owl code doesn't get a chance to get to work.

    2.7.212: This test passes.

# 156 LOW PRIORITY; UNKNOWN DIFFICULTY
# 157 LOW PRIORITY; UNKNOWN DIFFICULTY

Because the initial goal only includes the M19 string, the owl code
doesn't realize that O15 is a relevant lunch. This might require a
dynamic recomputation of the goal before it can be solved properly.

    157: 2.7.205: This test passes, but probably not for the right reason.

# 164 HIGH PRIORITY; EASY; Tuning

    2.7.212: This test passes.

# 171 HIGH PRIORITY; HARD; Seki misevaluated
# 172 HIGH PRIORITY; HARD; Seki misevaluated

Seki positions are being misevaluated as genus 0 because the opponent
stones involved in the seki are tactically safe.

# 173 LOW PRIORITY; HARD; Eyespace misevaluated

The edge eyespace

.XX.
X.X
---

is never more than one eye, but the optics code knows nothing about
edges and thinks it is worth two eyes.

    2.7.213: The optics code now knows about edges. Test case solved.

# 181 HIGH PRIORITY; UNKNOWN DIFFICULTY; Tuning + semeai

Correctly reading this out requires finding a threat to cut off stones
and winning the resulting semeai. It's also necessary to add relevant
patterns to set up various kos.


			      LD_OWL.TST

# 26 HIGH PRIORITY; UNKNOWN DIFFICULTY; Life code mistake.

The life code gets the seki eyespace .XXX. wrong.

    2.7.213: This test was solved when the life code was disabled.

# 64 HIGH PRIORITY; HARD; Seki mistake

The eyespace generation tends to go wrong when the defender has a move
to make a gote seki and there are enemy stones within the eyespace.
