Friday, July 18, 2008

CheckerBoard 1.651

I just published CheckerBoard 1.651 on my webpage. This release fixes four things:

1) a serious synchronization bug between the multiple threads of CheckerBoard, which could show up in autoplay and engine match mode; on my two newer machines that I usually use for development, this bug didn't show, but on my oldest machine it was very obvious. Even if the bug didn't show clearly on the newer machines, it is possible that it affects engine match outcomes - an upgrade is therefore strongly recommended if you run engine matches.

2) a small bug with graphics updating when changing the piece set (the board would update, the pieces only on the next window resizing).

3) export to HTML now also works from setup positions for Italian checkers (it always worked for English checkers)

4) I forgot to include the file 11man_FEN.txt which is used for 11-man engine matches. It contains 2400 of the 2500 possible 11-man starting positions. 100 of the positions are omitted, because they are likely wins for one side. The newest release includes this file, so that 11-man engine matches with 4800 games can be run (if you have the patience...) for better statistics than with standard engine matches.

If I get no negative feedback on this release, I will also publish the source code of CheckerBoard, since I find it increasingly difficult to find the time to work on CB - making the source public is a better alternative to stopping the development altogether.

But now, enjoy your bug-free 11-man matches!

5 comments:

Steve J said...

Hi Martin,

Thanks again for making the updates. Enabling an engine vs engine matches for all 3-moves openings will be a great tool (and time saver!) for debugging new engine releases.
The results with Rev 1.651 are significantly better than Rev 1.65!

I've started a total of five 3-move matches with CheckerBoard 1.651 with the following results:

On the weaker system (Windows XP Home Edition Version 2002 SP2, using a P4 with 1G RAM) two matches were ran. In both cases the every game ended after a few moves.
You had mentioned problems with older machines, and that was the case here. I do not care about this shortcoming for two reasons. First, 99% of my work is done on a Vista system. Secondly, and more important, after 5 years of faithful service, my older systems motherboard fried yesterday and I will need to upgrade :-(, :-)

Results on my second system (dual core 6700 at 2.67 GHz. I have 4.0G of memory, and use Windows Ultimate - 32 bit) is much better, although there still may be an issue or two. Most importantly, some of the 3-move matches are stopping before being completed. Also, some of the games are not playing out to a full win/loss/draw and returning a "*" instead. Not clear to me whether or not this is a problem. Can you tell me what this means?

One of the issues on Rev 1.65 was that illegal moves were may in matches that were not easily detectable my inspecting the PDN file, but, were obvious when the game was played out.
Co-incidently, I have a utility program that can verify whether or not legal moves are made. Since some file prep time is needed, results are not yet available on all matches.
All matches played were 2 sec per move with no user book. Opening books were used as available.
Here are the results on the Vista system:

First match:
KingsRow 1.16c Vs Cake Manchester 1.09d. 288 Games played. Illegal move utility confirmed all moves correct.
All games were either win, loss, or draw.

Second match:
Cake Manchester 1.09d Vs Boozer582. Match stopped after game ACF #46. CheckerBoard did not abort. (Legal move verification pending). I noticed in three of the games that the results were "*" instead of win/loss/draw. What does this mean?

Third match:
Cake Manchester 1.09d Vs Simple Checkers 1.14. Match stopped after ACF #87. CheckerBoard did abort. (Legal move verification pending). There were four games with "*" results.

I suspect that problems in the Third match may have been due to the heavy processing load on the system and it is being re-ran with only one core running full load. (game time changed to 1 sec per move).

Any thoughts on the rsults of match 2 and 3?

Please let me know if you need PDN files or anything else.

Best Regards,
Steve

Martin Fierz said...

Hi Steve,

thanks for your feedback. I ran 4 engine matches on each of my 3 machines, and in all 12 matches I saw no problems. Unlike you, I'm not happy at all that CB still seems to have some trouble with the engine match on an older machine, because that means something is still not right, and might show up again at some point.

The "*" in the engine match means the game was going on for too long: CheckerBoard aborts games after 100 moves, because some engines will not report results, and so games in drawn positions might continue indefinitely. For practical purposes, you can count the "*" as draws.

best regards
Martin

Steve J said...

Hi Martin,

FYI ... I've confirmed all moves were legal in the CakeM vs Simple Checkers match.
So far, no illegal moves have been found.

Also, after a match had stopped, it could be restarted by exiting the game, reloading CheckerBoard, and running an "engine match" again.
Once again, this will allow me to test new engines with hundreds of games in less than the number of man-hours it would take to do 10 games!

In the cases that Boozer is playing, the problem may be due to the program not returning W/L/D results. Can you tell me how to implement this?

You had said that you had ran 4 engine matches. If I have the engines, I can run them on my machines.

Regards,
Steve

Martin Fierz said...

Hi Steve,

I once wrote a guide to the CheckerBoard API: http://www.fierz.ch/cbdeveloper.php. It explains how to terminate games - see below.

cheers
Martin

Getmove should return a value between 0 and 3, defined as follows:
#define DRAW 0
#define WIN 1
#define LOSS 2
#define UNKNOWN 3
CheckerBoard uses the return value in automated engine matches to terminate a game when an engine claims a draw, win or loss. When CheckerBoard is in any other play mode, the return value of getmove is not used.

Steve J said...

Thanks Martin, it turns out it was in my code, but, the threshold was set too high! Working fine now.