Glaurung BFP
Posted: 24 Jun 2005, 10:07
Hi all,
The source code for Glaurung BFP, a new and very experimental Glaurung version, is now available from my Scatha and Glaurung page. This version should not replace Glaurung 0.2.3 in serious tournaments, but of course I would be happy if somebody wants to run some tests with it.
Compared to 0.2.3, there are a number of minor changes, mostly small code simplifications which should have little or no influence on the playing strength. There is only one really important change: I have intentionally introduced an ugly and serious-looking bug in the futility pruning (BFP stands for "buggy futility pruning"). I'll explain this bug below.
One of the biggest jumps in playing strength for Gothmog (my old chess engine) came when I increased the evaluation grain size by dividing the return value of the evaluation function by 2. At the time, I was very surprised that this little change seemed to be so effective. Much later, I discovered that the increased strength was not caused by the increased eval grain size, but by a bug introduced at the same time: I forgot to divide the return value of my approximate_eval_after_move() function (used for futility pruning) by 2. In Gothmog, this bug seems to be worth about 50-100 rating points. All attempts to fix it were disastrous. I never understood why this bug improved the playing strength.
In Glaurung BFP, I have copied Gothmog's old bug to Glaurung. The futility pruning in Glaurung 0.2.3 and previous versions looks like this (somewhat simplified for the sake of readability):
The approx_eval_after_move() function adds the approximate change in eval when the move is made to the static eval of the current position.
In Glaurung BFP, the first line of code above is changed:
This, of course, makes no sense at all. The program will make wildly inaccurate futility pruning decisions everywhere in the tree, and I would have expected to see lots of horrible blunders. For some reason which I still don't understand, this does not seem to happen. On the contrary, Glaurung BFP performs better than 0.2.3 in tactical test suites. I also played a Noomen match between the two versions, and BFP won by 54-46. Of course the winning margin is not sufficiently big to be sure that BFP is really stronger, but I think just the fact that BFP does not lose by a big margin is truly astonishing.
My hope is that if I some day manage to understand why this bug works, I will be able to use this understanding to invent some really cool new search tricks.
Tord
The source code for Glaurung BFP, a new and very experimental Glaurung version, is now available from my Scatha and Glaurung page. This version should not replace Glaurung 0.2.3 in serious tournaments, but of course I would be happy if somebody wants to run some tests with it.
Compared to 0.2.3, there are a number of minor changes, mostly small code simplifications which should have little or no influence on the playing strength. There is only one really important change: I have intentionally introduced an ugly and serious-looking bug in the futility pruning (BFP stands for "buggy futility pruning"). I'll explain this bug below.
One of the biggest jumps in playing strength for Gothmog (my old chess engine) came when I increased the evaluation grain size by dividing the return value of the evaluation function by 2. At the time, I was very surprised that this little change seemed to be so effective. Much later, I discovered that the increased strength was not caused by the increased eval grain size, but by a bug introduced at the same time: I forgot to divide the return value of my approximate_eval_after_move() function (used for futility pruning) by 2. In Gothmog, this bug seems to be worth about 50-100 rating points. All attempts to fix it were disastrous. I never understood why this bug improved the playing strength.
In Glaurung BFP, I have copied Gothmog's old bug to Glaurung. The futility pruning in Glaurung 0.2.3 and previous versions looks like this (somewhat simplified for the sake of readability):
- Code: Select all
int futility_value = approx_eval_after_move(move);
if(futility_value < alpha-futility_margin)
continue; /* Don't search this move */
The approx_eval_after_move() function adds the approximate change in eval when the move is made to the static eval of the current position.
In Glaurung BFP, the first line of code above is changed:
- Code: Select all
int futility_value = approx_eval_after_move(move) * 2;
This, of course, makes no sense at all. The program will make wildly inaccurate futility pruning decisions everywhere in the tree, and I would have expected to see lots of horrible blunders. For some reason which I still don't understand, this does not seem to happen. On the contrary, Glaurung BFP performs better than 0.2.3 in tactical test suites. I also played a Noomen match between the two versions, and BFP won by 54-46. Of course the winning margin is not sufficiently big to be sure that BFP is really stronger, but I think just the fact that BFP does not lose by a big margin is truly astonishing.
My hope is that if I some day manage to understand why this bug works, I will be able to use this understanding to invent some really cool new search tricks.
Tord