Rebel wrote:The best bugs are those who produce ELO.
Today my thoughts went back to a fun moment during the WCCC 1993 in Munich and the game I played against Chrilly, Rebel vs Nimzo. After xx moves the game went into an unclear but equal ending and here Chrilly started to comment about every move Nimzo played saying Nimzo had a bug and that's why it played that move. And in the end Nimzo won the game, Chrilly having big fun telling everybody he won because of a bug.
Now those who know Chrilly and his sense of humor will realize you never can be sure if he is not pulling your leg but if true that's the kind of bug you want to keep.
I have one of my own, I am aware of it since the 90's, eventually after a long debugging process found the bug, but in order to fix it would lose so much speed that Rebel would lose 30-40 elo points and thus I left it and it's still present until this day. Consider the diagram and its analysis.
[d]k7/8/8/4b3/8/5K2/7p/8 w - -
Rebel wrote:The best bugs are those who produce ELO.
Today my thoughts went back to a fun moment during the WCCC 1993 in Munich and the game I played against Chrilly, Rebel vs Nimzo. After xx moves the game went into an unclear but equal ending and here Chrilly started to comment about every move Nimzo played saying Nimzo had a bug and that's why it played that move. And in the end Nimzo won the game, Chrilly having big fun telling everybody he won because of a bug.
Now those who know Chrilly and his sense of humor will realize you never can be sure if he is not pulling your leg but if true that's the kind of bug you want to keep.
I have one of my own, I am aware of it since the 90's, eventually after a long debugging process found the bug, but in order to fix it would lose so much speed that Rebel would lose 30-40 elo points and thus I left it and it's still present until this day. Consider the diagram and its analysis.
[d]k7/8/8/4b3/8/5K2/7p/8 w - -
Because 'max' is a macro and not a function and I did not know that.
O I might have misread your question.. it did not help ELO
But I remember a blog from the Mediocre author where he discovered he used his _eg and _mg pcsq tables in the wrong order and after the "fix" his program played way worse.. hahaha ,, well if you have a bug for a longer time you tune the rest around it I suppose ?
Rebel wrote:The best bugs are those who produce ELO.
Today my thoughts went back to a fun moment during the WCCC 1993 in Munich and the game I played against Chrilly, Rebel vs Nimzo. After xx moves the game went into an unclear but equal ending and here Chrilly started to comment about every move Nimzo played saying Nimzo had a bug and that's why it played that move. And in the end Nimzo won the game, Chrilly having big fun telling everybody he won because of a bug.
Now those who know Chrilly and his sense of humor will realize you never can be sure if he is not pulling your leg but if true that's the kind of bug you want to keep.
I have one of my own, I am aware of it since the 90's, eventually after a long debugging process found the bug, but in order to fix it would lose so much speed that Rebel would lose 30-40 elo points and thus I left it and it's still present until this day. Consider the diagram and its analysis.
[d]k7/8/8/4b3/8/5K2/7p/8 w - -
Have you tried simply disabling razoring to see what happens ?
I've just recently implemented KBPK in DiscoCheck, and discovered the exact same bug independantly. Or rather the same end result with perhaps a different underlying cause because DiscoCheck is not Rebel.
The solution (for DiscoCheck) is quite simple: disable razoring when the side to move has only a king. At this point I only recognize as draws the KPK and KBPK, so this condition seems appropriate. As for slowing down, I doubt it would be significant. When we only have a lone king (no pawns and no piece) it is very likely that the game outcome is already decided, no matter how fast we search. And the calculation that determines that we have only a king left, is intself very fast (material count bitfield).
lucasart wrote: I've just recently implemented KBPK in DiscoCheck, and discovered the exact same bug independantly. Or rather the same end result with perhaps a different underlying cause because DiscoCheck is not Rebel.
Too funny.
The solution (for DiscoCheck) is quite simple: disable razoring when the side to move has only a king.
lucasart wrote:I've just recently implemented KBPK in DiscoCheck, and discovered the exact same bug independantly. Or rather the same end result with perhaps a different underlying cause because DiscoCheck is not Rebel.
The solution (for DiscoCheck) is quite simple: disable razoring when the side to move has only a king.
I am afraid I still don't get it. If the PV sees the opponent queening, so that the search window moves to a score of -1200 for the bare King... Why would you razor moves like Kh1 which keep the current eval at -400 (or perhaps -550 with 7th-rank passer bonus)? That is at alpha + 800. Usually one razors moves because they are far below alpha, and not when they tower beta.
lucasart wrote:I've just recently implemented KBPK in DiscoCheck, and discovered the exact same bug independantly. Or rather the same end result with perhaps a different underlying cause because DiscoCheck is not Rebel.
The solution (for DiscoCheck) is quite simple: disable razoring when the side to move has only a king.
I am afraid I still don't get it. If the PV sees the opponent queening, so that the search window moves to a score of -1200 for the bare King... Why would you razor moves like Kh1 which keep the current eval at -400 (or perhaps -550 with 7th-rank passer bonus)? That is at alpha + 800. Usually one razors moves because they are far below alpha, and not when they tower beta.
As I said: disable razoring when the side to move has only a king.
lucasart wrote:As I said: disable razoring when the side to move has only a king.
Indeed, that is what you said.
So from that I concluded that with razoring enabled you would see the bug Ed describes.
And that suggests there is something horribly wrong with your implementation of razoring... Because, as I explained above, normal razoring should not cause you to stop defending h1.
Looking at this position I actually found a bug in Jazz' evaluation function for wrong bishop+edge pawn. It would recognise as a draw a position where the defending king could reach the promotion square, but not positions where it was actually on the promotion square. Easily fixed, of course, but the issue was entirely cosmetic anyway: it still preferred to stop the pawn over letting the pawn promote, but the score jumped between a large negative value and 0. It now correctly stays on 0.
Which is a round-about way of saying that I don't see how incorrect razor margins would cause you to get this wrong either, especially if the evaluation function recognises the draw and returns a draw score...
Evert wrote:Looking at this position I actually found a bug in Jazz' evaluation function for wrong bishop+edge pawn. It would recognise as a draw a position where the defending king could reach the promotion square, but not positions where it was actually on the promotion square. Easily fixed, of course, but the issue was entirely cosmetic anyway: it still preferred to stop the pawn over letting the pawn promote, but the score jumped between a large negative value and 0. It now correctly stays on 0.
Which is a round-about way of saying that I don't see how incorrect razor margins would cause you to get this wrong either, especially if the evaluation function recognises the draw and returns a draw score...
,, well if you have a bug for a longer time you tune the rest around it I suppose ?
