Re: [gnugo-devel] auto generated regression tests

[Evan Berggren Daniel]

> I have looked through the tests and I think they are pretty useful.
>
> As a general comment, "dragon_status" takes a lot more time than
> "owl_defend/attack". I am all in favour of adding a lot more of
> these semi-automatic tests to the regression, but we don't want the
> regressions run to take unnecessariyl longer, so I'd suggest to use the
> latter. (I.e., instead of
> X dragon_status XX
> #? [!dead]
>
> we can use
>
> X owl_defend XX
> #? [!0]
>
> or even better
>
> X owl_defend XX
> #? [1 (list of working defense moves)]
>
> There were two or three tests where I came to a different conclusion.
> These changes, plus the conversion away from using dragon_status, are
> in the attached .tgz-file as well as in the patch below.

Sounds good.  I was hoping a better player than I would take a look at it
:)

> As you have already pointed out in another e-mail, this type of self-play
> catches a particular type of owl mistake. I would think that analyzing
> games against humans in the same manner would be extremely useful, too,
> and possibly catch a bigger variety of mistakes.

perhaps so.  I'll go ahead and write a simple hack to walk through sgf
files at some point.

> > Also, has anyone tried running the matcher_status script?  does gnugo
> > finish games completely when you do?
>
> Did GNU Go play the passes at the "end" of auto010.sgf?? That would be
> very weird, and it doesn't happen when I let GNU Go generate a move
> there. Would be quite a bug.

Yes, it did play both those passes.  it actually seemed to fail to play
out the end game fairly frequently in my auto generation games.  All the
auto_gen .sgf's are exactly as GNU Go finished them.  It happened
frequently enough, I was inclined to think it was a bug in matcher_check
or twogtp, but I didn't see how that would work.  It just now occured to
me maybe it's a bug in the gtp interface code?

Thanks

Evan Daniel