> Some eye patterns seems not suitable to be applied on the board edge. > Following condition (3.7.10, recognize_eye() in optics.c, line 1301) > > if (neighbors[mv] != gv->neighbors > || marginal[mv] != gv->marginal > || edge[mv] < gv->edge) > > implies that GG hard code always take space on the edge as advantage, but it > may be the opposite.
No, it implies that edge patterns cannot be matched in the center and that corner patterns cannot be matched on the edge or in the center. Corner patterns always precede edge patterns which precede center patterns in eyes.db (partial ordering) and only the first match is used. The corner and edge specific patterns may have smaller or larger eye values as needed. > For example, Eye Pattern: 420, which yields 1-1-1-2, typically, > > ooooo > o...o > ooo.xx > xxxxxx > > > the following position can also matches unexpectedly, and, of course, > missing the vital point. > > -------------------------- > o...o > ooo.xx > xxxxxx > > > > I am not sure which solution is side-effect free, setup constraints or split > up those patterns? Have you tried this on an actual board position? The first case has the eye graph "...!" but in the second case the topological half/false eye analysis should detect both a false eyepoint and a halfeye on the edge, and the eyespace segmentation should find ".h!" which is translated to a graph matching eye pattern 448 for a 0011 value. An example where the same graph is found but the value is different on the edge is OOOOO O.X.O O..XO OOOOO and OOOOO O.X.O O..XO ----- which are matched by eye patterns 6513 and 6504 respectively. There are things that are tricky with the eyespace analysis though, and where we don't have very good solutions. These include marginal vertices of different quality, shortage of external liberties, and cutting points inside the eyespace. /Gunnar _______________________________________________ gnugo-devel mailing list gnugo-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gnugo-devel
