Author: Christophe Theron
Date: 10:51:00 05/25/00
Go up one level in this thread
On May 24, 2000 at 12:57:47, Bruce Moreland wrote:
>On May 23, 2000 at 23:40:50, Christophe Theron wrote:
>
>>Yes, I have this too. When I change something, even a single line, I run a test
>>and look at the total number of positions seen. If it is different, either I
>>know why (the change in tree size was expected) and it's OK, or I don't know why
>>and it's likely a bug.
>>
>>The next step in this case is to use my tree dump utility. It allows me to
>>compare the trees searched by two different versions, and to point me exactly
>>where the searches forked. Then it is very easy to find what the problem is.
>>
>>It has been especially useful when I ported my code from GCC to VC. The number
>>of nodes computed by the 2 versions were different, and without this tool it
>>would have taken me several days to find what the problem was. With the tool I
>>have been able to fix it in 1 hour.
>
>My tree dumper is crappy, but I make up for this by having a good version
>comparison program.
>
>I can track and compare node counts for every completed ply in every problem.
>If there is a bug, it will probably make several of the LCTI positions report a
>difference in some ply. I can look through the differences and figure out which
>one happened closest to the root, so the amount of tree mess I have to deal with
>is smaller.
>
>Just something to consider. I should make my tree dumper better, it would be
>nice if it could show me only the parts that are different, and the paths taken
>to get to those places.
>
>bruce
Actually my dumper does both the "first iteration that is different" and "path
to difference", but it stops at the first difference found. Because as soon as
there is a difference I have to launch the debugger and find what's wrong.
I simply dump every move the engine makes, together with the ply depth (distance
from the root) and the static score of the resulting position. That makes 6
bytes per move. I also send a signal when the iteration number changes.
Then the dump analyser rebuilds the full path for every move generated, and
outputs a text file that looks like:
01 18 g1f3
01 18 b1c3
01 10 e2e3
01 10 d2d3
01 6 e2e4
01 6 d2d4
...
...
01 -32 f2f4
01 -48 h2h4
01 -70 g2g4
02 18 g1f3
02 0 g1f3 g8f6
...
...
(iteration, score, path)
The line number in this text file is simply the number of the position searched.
When I want to set a breakpoint on the offending move, I insert this code
snippet inside my search loop:
if (nbpos==2493)
printf("Stop here, stupid");
and I set a breakpoint on the printf line. nbpos is my node counter. 2493 would
be the number of the position where the new and old version forked (as found by
my dump compare utility).
It's rather crude, but more than enough, even for the worst cases I have found
so far.
Christophe
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.