Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: endgame database verification

Author: Angrim

Date: 22:27:18 01/28/02

Go up one level in this thread


On January 28, 2002 at 19:14:11, martin fierz wrote:

>aloha!
>
>i am wondering about endgame databases and their verification, maybe someone
>here can shed some light on the issue: it's regarding the 8-piece checkers
>endgame database, which was computed by jonathan schaeffer in about '95, and
>just now by different commercial checkers programmers. one team, world
>championship checkers, has verified it's database against that of schaeffer, and
>apparently this verification has found errors in both databases.
>i wrote a post on a checkers message board saying i believed that an independent
>verification would not be necessary, to which ed trice of WCC replied below,
>calling this statement ridiculous.
>since endgame database construction in checkers is the same as in chess:
>could somebody comment on the database verification process? how reliable is it?
>is ed trice right? eugene?

I would agree with the conclusion(independant verification is
a really good idea) but the logic used to support this conclusion
is just plain silly.
The actual need for independant verification is to detect errors in logic,
rather than hardware errors.  If the designer of the egtb generator made
a mistake in the move generator or accidentally scored stalemates as
wins or some such, there is some significant chance that they would
make the same mistake again when writing the verification program.
This can partly be avoided by useing a different board structure
and movegen in the verifier than in the generator, but for the highest
levels of certainty an indepentantly designed verification program is
needed.


>
>: Gentlemen,
>:
>: I have been directed to this page by a couple of ACF members who have
>: inundated me with emails.
>:
>: Verifying the 8-piece database was a difficult task. Gil Dodgen and
>: I found a mistake in the Chinook database which had been present for
>: 8 years, undetected by the most-tested database on the planet. Dr.

<humor> hardly surprising. I don't know what the most-tested
database on the planet is, but I can be quite sure that it has nothing
to do with checkers, and so would not be able to detect errors in the
Chinook database. </humor>

>: Schaeffer corrected his databases. As we continued to develope our
>: databases, Dr. Schaeffer's results and ours did not agree again, this
>: time it was tracked down to 1123 bits that did not copy properly on
>: *our end.*
>:

>: Anyone who states that their database computation does not need
>: independent verification is rather foolish. The process is very complex,
>: and hundreds of trillions (I guess a few hundred thousand million in the
>: English sense) of calculations are performed as your database is being built.
>:
>: If your chance of any error creeping in in one in 10,000,000,000 you
>: will most likely have 100 chances to encounter such an error. Should
>: one single integrated circuit dip to -0.5 Volts when it should have been
>: +0.5 Volts (the difference between a binary "0" and a binary "1") even for
>: a microsecond, your databases will be wrong.

The above is a fairly good explanation of why even a correctly coded
generator can result in files containing errors.  However, such an
error should be detected by "unilateral verification"

>:
>: Dr. Schaeffer will publish a paper on the topic wherein the notion
>: of "unilateral verification", that is "testing it yourself" once a
>: database has been computed, is no longer a valid means to assert
>: correctness. Gil and I will be participating in this paper as contributors.
>:
>: So, while you may use whatever rhetoric you wish on this forum, I suggest
>: you defer to the two teams who have correctly completed the result before
>: you make ridiculous statements such as I have already seen.
>:
>: Any doubts, send an email to Dr. Schaeffer yourself.

<humor> Even independant verification is not a complete defense
against hardware errors, since after you ship a copy of the database
off to be verified, your hardware could suddenly decide to make a few
changes to your origional. </humor>

Angrim
ps. My suicide chess egtb are now roughly 300GB uncompressed.  And I
am WAY behind on the verification process. maybe 40GB verified.  The
problem being that I can either use my cpu to build, or to verify.
I compromise by verifying the first file of each type generated after
I make any change to the movegen or the egtb generator.
"Each type" means "with no pawns" "with pawns" "with two pieces
of the same type and no pawns" "two pieces of the same type and pawn"



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.