Author: Robert Hyatt
Date: 12:22:07 05/16/98
I've just copied the source files for Crafty v15.7 to the ftp machine ftp.cis.uab.edu/pub/hyatt/v15 Since the signal to noise ratio is going up here in r.g.c.c, here's a short story about fixing/breaking/fixing/breaking something: A couple of years ago, I reported that I had encountered a serious bug that was null-move related. Specifically, what I was seeing was a fail-high on the PVS search (already got the score for the first move at the root, now searching the remainder with alpha,alpha+1 window). Researching this fail-high would, on occasion produce a fail-low. After a lot of debugging, I finally understood the problem and la- beled it "the null-move fail high/low anomoly". As a general rule, a fail high move should be played, but on several occasions this was causing problems, because the fail high was being caused by a null-move failure that would not recur on the research. As a result, I saw crafty make an occasional move that was gross. Bruce and I chatted about this quite often. We both (either independently or after discussing it, I don't recall) decid- ed that if the move fails high, then fails low, we would pretend that it never failed high. This got rid of the ugly moves. Somewhere over the past year, I reintroduced this bug "silently". In Crafty, the PVS fail-high is *not* reported to the operator with a ++ indicator. Rather, I wait until the research also fails high or produces a score < beta but > alpha+1 before I tell the operator. However, It turns out that a modification a long time back would allow this "silent fail high" to store the failhigh move in the PV. And crafty would actually play this move without it ever having shown up in the search output. I found this by two different ways: 1. someone noticed that on occasion, crafty would "whisper" that it was playing move "X" with the score and so forth, but on the board, a different move "Y" was actually played. That should *never* happen of course. 2. I got an error message every now and then about the PV being invalid when I try to stuff it into the hash table be- fore starting a search (I check each move for validity, just as a "sanity check" on the engine. The last PV displayed might survive, but the first move could be changed. Which *could* invalidate the moves further down the PV of course. In any case, this is now fixed in 15.7, and it was a SMP/non-SMP problem that affected everyone. There were a few other bugs, such as the black king piece/square table that centralizes the king in the endgame, was missing one row of initialization... so that a black king on the first rank looked *very* good. And it lost games because of this... The source files are ready... the executables will follow once I let Jason know that this version has been released. Let me know of *any* bugs as old problems should be cured by now... (except for the NT makefile which I will try to get repaired).
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.