Re: [gnugo-devel] arend_1_26.3 tested

[Arend Bayer]

Thanks for the test results.

On Thu, 21 Feb 2002, Daniel Bump wrote:
> One would expect a greater speedup with owl.tst than
> with all_batches but I found the reverse.  The speedup
That agrees with my results. I think the patch is most useful for
big dragons (=> many patterns matching), and the ones in owl.tst might
be smaller as they were chosen so that GNU Go should be able to read
everything out.

> for all_batches was 4.45 % and the speedup for owl.tst
> was 2.29 %. There could be some randomness in the timing
> results but I'm convinced this patch is a good speedup.
Hmm. I measured 16% for nngs.tst with gprof. I think gprof's accuracy
should be quite good; also, this agrees with the save of reading nodes.
However, gprof doesn't measure time spent in system calls. Maybe my
handling of the pattern list memory is inefficient. I will do some more
tests about this.

> On the down side there was a net loss of eight tests.
> 
> My conclusion is that we want this patch but we should look
> a little harder at the failures.
For gnugo-3.1.25 + patch, I got 15 FAILs and 20 PASSes. (A few of them
platform dependencies.) I don't know whether that is about the amount
to be expected from the owl indeterminacy.

I compared the regression results of the patch with a preliminary version
of it that only differed in the sorting algorithm used (where the
indeterminacy comes in). I looked at all the common fails and found one
bug, attack patterns of value 99 got handled incorrectly. This is fixed
with the patch coming in the next email. All other FAILs were caused by
the "indeterminacy".

I don't think I should try to fix these with e.g. a differnt sorting
algorithm (they would probably reappear with a different orientation);
however, I think we should reduce this indeterminacy. E.g., 10% of
the patterns in owl_defendpats have value 70, this seems a bit too many.


Arend