I've just discovered a fun bug in Minic.
As I use internal end-game heuristic for basic end-games, Minic knows that KNBK is a win and score it very high.
But it only scores KBQK the price of Q+B, KRBK as R+B and KBBK as 0 ...
So it tends to under promote to N in some circumstance, which look like some kind of "humiliation mode", but is just a bug
Here is an example (move 69) :
[pgn]
[Event "My Tournament"]
[Site "?"]
[Date "2020.03.07"]
[Round "21"]
[White "minic_1.50"]
[Black "minic_dev_linux_x64"]
[Result "0-1"]
[ECO "A40"]
[GameDuration "00:00:34"]
[GameEndTime "2020-03-07T20:55:17.803 CET"]
[GameStartTime "2020-03-07T20:54:43.408 CET"]
[Opening "Modern defense"]
[PlyCount "200"]
[TimeControl "10+0.1"]
1. d4 {book} g6 {book} 2. e4 {book} Bg7 {book} 3. Nf3 {+0.57/13 0.41s}
d6 {-0.52/12 0.58s} 4. Bd3 {+0.54/11 0.56s} Nf6 {-0.38/12 0.35s}
5. O-O {+0.43/11 0.37s} O-O {-0.37/11 0.54s} 6. Nbd2 {+0.49/12 0.29s}
Nc6 {-0.33/14 0.42s} 7. c3 {+0.37/13 0.44s} e5 {-0.22/14 0.28s}
8. Re1 {+0.40/13 0.49s} exd4 {-0.26/13 0.39s} 9. cxd4 {+0.64/13 0.34s}
a6 {-0.49/14 0.33s} 10. d5 {+0.64/16 0.45s} Ne7 {-0.65/13 0.27s}
11. a4 {+0.37/13 0.43s} c6 {-0.57/14 0.29s} 12. dxc6 {+0.25/14 0.28s}
bxc6 {-0.50/14 0.43s} 13. e5 {+0.48/14 0.34s} dxe5 {-0.27/15 0.41s}
14. Nxe5 {+0.36/13 0.25s} Nfd5 {-0.20/14 0.39s} 15. Ndc4 {+0.02/12 0.25s}
Rb8 {-0.18/11 0.38s} 16. Bd2 {+0.05/12 0.28s} Nb4 {-0.35/12 0.21s}
17. Be4 {-0.03/11 0.25s} Ned5 {-0.13/12 0.36s} 18. Rc1 {+0.11/12 0.35s}
Be6 {-0.29/13 0.31s} 19. Qb3 {+0.06/12 0.25s} Re8 {-0.19/13 0.33s}
20. Qa3 {0.00/13 0.24s} a5 {-0.05/13 0.21s} 21. Qg3 {-0.01/13 0.26s}
Qc7 {+0.03/12 0.29s} 22. Rcd1 {-0.01/12 0.31s} Nf6 {0.00/12 0.18s}
23. Bf3 {-0.07/12 0.20s} Nfd5 {+0.01/14 0.29s} 24. Be4 {-0.01/12 0.20s}
Nf6 {+0.01/14 0.25s} 25. Bf3 {-0.09/14 0.23s} Nfd5 {-0.10/14 0.24s}
26. Qh4 {-0.18/12 0.28s} Bf5 {+0.48/11 0.20s} 27. Bxb4 {-0.70/11 0.17s}
Rxb4 {+0.98/12 0.25s} 28. Nxc6 {+0.25/12 0.22s} Qxc6 {+1.35/12 0.25s}
29. Rxe8+ {+0.19/14 0.25s} Qxe8 {+1.40/16 0.13s} 30. Bxd5 {-0.80/13 0.24s}
Bc2 {+1.43/14 0.16s} 31. Rc1 {-0.92/15 0.24s} Bxb2 {+1.74/13 0.19s}
32. Bxf7+ {-1.16/14 0.23s} Qxf7 {+1.62/14 0.13s} 33. Qd8+ {-1.21/15 0.23s}
Kg7 {+1.76/14 0.15s} 34. Nxb2 {-1.08/15 0.22s} Rxb2 {+1.42/13 0.13s}
35. Qd4+ {-1.40/12 0.17s} Qf6 {+1.80/11 0.22s} 36. Qd7+ {-1.37/12 0.12s}
Kf8 {+1.27/11 0.21s} 37. Qc8+ {-1.38/13 0.16s} Kf7 {+1.09/10 0.21s}
38. h4 {-1.32/12 0.18s} Qd4 {+2.48/12 0.20s} 39. Qc7+ {-2.37/12 0.13s}
Kg8 {+2.19/10 0.20s} 40. Qxa5 {-2.31/14 0.17s} Bxa4 {+2.17/14 0.17s}
41. Qc5 {-2.37/14 0.17s} Qxc5 {+2.22/14 0.11s} 42. Rxc5 {-2.48/15 0.16s}
h6 {+2.33/13 0.19s} 43. h5 {-1.94/13 0.10s} g5 {+2.29/14 0.18s}
44. Rc8+ {-2.31/14 0.12s} Kf7 {+2.42/14 0.18s} 45. Rc7+ {-2.39/13 0.11s}
Kf8 {+2.36/13 0.17s} 46. Ra7 {-2.33/14 0.11s} Be8 {+2.65/15 0.14s}
47. Ra6 {-2.45/15 0.18s} Kg7 {+2.66/15 0.13s} 48. Ra7+ {-2.47/15 0.18s}
Bf7 {+2.49/13 0.11s} 49. f3 {-2.51/16 0.12s} Rb6 {+2.50/15 0.14s}
50. g4 {-2.71/12 0.13s} Kf6 {+2.68/15 0.13s} 51. Ra5 {-2.73/14 0.11s}
Rd6 {+2.71/13 0.090s} 52. Rf5+ {-2.49/14 0.17s} Kg7 {+2.69/12 0.10s}
53. Kf2 {-2.45/15 0.11s} Rd5 {+3.53/14 0.090s} 54. Rxd5 {-4.55/16 0.16s}
Bxd5 {+4.45/18 0.12s} 55. Kg3 {-5.37/17 0.16s} Kf7 {+5.61/17 0.11s}
56. f4 {-5.95/13 0.098s} Kf6 {+6.68/17 0.16s} 57. fxg5+ {-7.67/15 0.16s}
Kxg5 {+56.92/16 0.15s} 58. Kf2 {-56.93/14 0.15s} Kxg4 {+57.32/17 0.15s}
59. Ke3 {-57.63/20 0.44s} Kxh5 {+57.82/16 0.087s} 60. Kf4 {-57.63/20 0.13s}
Kh4 {+57.82/19 0.10s} 61. Kf5 {-57.63/15 0.081s} h5 {+57.82/16 0.11s}
62. Kf4 {-57.73/18 0.081s} Be4 {+57.82/18 0.091s} 63. Ke5 {-57.81/18 0.13s}
Kg4 {+57.82/19 0.11s} 64. Kf6 {-57.83/18 0.084s} h4 {+57.82/18 0.085s}
65. Ke7 {-57.83/17 0.078s} h3 {+57.82/17 0.091s} 66. Kd8 {-57.83/17 0.097s}
Kg5 {+57.82/17 0.12s} 67. Ke7 {-57.83/17 0.096s} h2 {+57.82/17 0.14s}
68. Kd6 {-57.83/18 0.12s} Kf5 {+57.82/17 0.10s} 69. Kc5 {-57.83/17 0.087s}
h1=N {+57.82/17 0.12s} 70. Kd6 {-57.83/18 0.075s} Nf2 {+57.82/17 0.10s}
71. Kc5 {-57.83/16 0.090s} Bg2 {+57.82/17 0.13s} 72. Kb4 {-57.83/17 0.092s}
Ke5 {+57.92/16 0.14s} 73. Ka3 {-57.93/16 0.080s} Kd4 {+58.02/16 0.094s}
74. Kb2 {-57.93/17 0.098s} Nd3+ {+58.02/16 0.095s} 75. Kb3 {-58.03/16 0.10s}
Ne1 {+58.02/16 0.091s} 76. Kb2 {-58.03/17 0.094s} Kc4 {+58.02/16 0.087s}
77. Kc1 {-58.03/18 0.10s} Kc3 {+58.02/16 0.083s} 78. Kb1 {-58.03/16 0.076s}
Nc2 {+58.02/16 0.088s} 79. Ka2 {-58.03/17 0.080s} Bd5+ {+58.02/16 0.12s}
80. Kb1 {-58.03/16 0.14s} Bg8 {+58.12/17 0.10s} 81. Kc1 {-58.13/17 0.087s}
Ba2 {+58.12/16 0.085s} 82. Kd1 {-58.23/17 0.10s} Nd4 {+58.12/17 0.11s}
83. Ke1 {-58.23/16 0.085s} Kd3 {+58.22/17 0.089s} 84. Kf2 {-58.33/16 0.11s}
Ke4 {+58.22/16 0.11s} 85. Ke1 {-58.03/15 0.088s} Nb3 {+58.22/16 0.083s}
86. Kf2 {-58.23/15 0.086s} Kf4 {+58.22/17 0.12s} 87. Ke2 {-58.23/17 0.099s}
Bb1 {+58.32/16 0.091s} 88. Kf2 {-58.33/17 0.11s} Nd4 {+58.32/17 0.11s}
89. Kg2 {-58.33/16 0.083s} Be4+ {+58.42/16 0.089s} 90. Kf2 {-58.33/16 0.10s}
Bf3 {+58.42/16 0.083s} 91. Kf1 {-58.43/16 0.086s} Ke3 {+58.42/16 0.084s}
92. Ke1 {-M20/20 0.31s} Nc2+ {+M17/17 0.10s} 93. Kf1 {-M16/17 0.073s}
Be4 {+M15/18 0.089s} 94. Kg1 {-M14/17 0.075s} Kf3 {+M13/19 0.099s}
95. Kf1 {-M12/17 0.082s} Bf5 {+M11/19 0.11s} 96. Kg1 {-M10/18 0.084s}
Ne3 {+M9/18 0.10s} 97. Kh2 {-M8/19 0.085s} Kf2 {+M7/20 0.094s}
98. Kh1 {-M6/49 0.075s} Be6 {+M5/58 0.083s} 99. Kh2 {-M4/121 0.018s}
Nf1+ {+M3/121 0.014s} 100. Kh1 {-M2/121 0.001s}
Bd5# {+M1/121 0.002s, Black mates} 0-1
[/pgn]
Very cool bug inside Minic
Moderators: hgm, Rebel, chrisw
-
- Posts: 1871
- Joined: Sat Nov 25, 2017 2:28 pm
- Location: France
-
- Posts: 550
- Joined: Tue Nov 19, 2019 8:48 pm
- Full name: Alayan Feh
Re: Very cool bug inside Minic
A win is a win, as some would say. I'd make it prefer KRBK and KQBK, but this is fun.
KBBK at 0... I assume this is only for same-colored bishops, right ? KBBK with one LSB and one DSB is a clear win.
KBBK at 0... I assume this is only for same-colored bishops, right ? KBBK with one LSB and one DSB is a clear win.
-
- Posts: 1871
- Joined: Sat Nov 25, 2017 2:28 pm
- Location: France
Re: Very cool bug inside Minic
of course KLL and KDD are draws but KLD has it's own end game heuristic.
-
- Posts: 27808
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Very cool bug inside Minic
The bug is arguably that you award a special score to KBNK in the first place. Its naive evaluation would already be +6, and if +6 doesn't mean 'certain win', what will? (Of course KNNK does deserve special treatment, as it is a certain draw, but that is another story.)
I usually treat end-games against a bare King only as 'special' by the fact that unlike all other end-games where the strong side is pawnless I do not discount the naive evaluation by 50%. And of course the dead draws KBKx and KNKx and KNNK are recognized as such.
In Pawn endings it can be justified to multiply the naive score by a factor 1.5 to 2.
Perhaps the following set of rules has some general validity:
* strong side Pawnless? score *= 0.5
* weak side bare? score *= 2
* weak side only Pawns? score *= 1.5
* strong side lacks mating potential? score *= 0.1
I usually treat end-games against a bare King only as 'special' by the fact that unlike all other end-games where the strong side is pawnless I do not discount the naive evaluation by 50%. And of course the dead draws KBKx and KNKx and KNNK are recognized as such.
In Pawn endings it can be justified to multiply the naive score by a factor 1.5 to 2.
Perhaps the following set of rules has some general validity:
* strong side Pawnless? score *= 0.5
* weak side bare? score *= 2
* weak side only Pawns? score *= 1.5
* strong side lacks mating potential? score *= 0.1
-
- Posts: 1871
- Joined: Sat Nov 25, 2017 2:28 pm
- Location: France
Re: Very cool bug inside Minic
In fact, I think this "winning bonus" comes from the same idea :
I have an enum, this way, to "sort" end game
And I apply those factor, also taking 50 moves rule into account.
I have an enum, this way, to "sort" end game
Code: Select all
enum Terminaison : unsigned char {
Ter_Unknown = 0,
Ter_WhiteWinWithHelper, // for KRK, or KPK, or KBNK, ...
Ter_WhiteWin, // for KRR, or KQR, or ...
Ter_BlackWinWithHelper,
Ter_BlackWin,
Ter_Draw, // 3reps, pat, 50 moves
Ter_MaterialDraw, // KBK, KNK, KNNK
Ter_LikelyDraw, // for things like KRKB or KDLKN
Ter_HardToWin }; // for KQKR or KRNKN, ...
Code: Select all
// end game knowledge (helper or scaling)
if ( safeMatEvaluator && (p.mat[Co_White][M_t]+p.mat[Co_Black][M_t]<6) ){
const Color winningSideEG = score[sc_Mat][EG]>0?Co_White:Co_Black;
if ( MEntry.t == MaterialHash::Ter_WhiteWinWithHelper || MEntry.t == MaterialHash::Ter_BlackWinWithHelper ) return (white2Play?+1:-1)*(MaterialHash::helperTable[matHash](p,winningSideEG,score[sc_Mat][EG]));
else if ( MEntry.t == MaterialHash::Ter_Draw) { if (!isAttacked(p, kingSquare(p))) return context.drawScore(); }
else if ( MEntry.t == MaterialHash::Ter_MaterialDraw) { if (!isAttacked(p, kingSquare(p))) return context.drawScore(); }
else if ( MEntry.t == MaterialHash::Ter_WhiteWin || MEntry.t == MaterialHash::Ter_BlackWin) score.scalingFactor = 5 - 5*p.fifty/100.f;
else if ( MEntry.t == MaterialHash::Ter_HardToWin) score.scalingFactor = 0.5f - 0.5f*(p.fifty/100.f);
else if ( MEntry.t == MaterialHash::Ter_LikelyDraw) score.scalingFactor = 0.3f - 0.3f*(p.fifty/100.f);
}
-
- Posts: 27808
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Very cool bug inside Minic
But what I described was not really a bonus for the mere fact that it should be a win. It would be applied to any position, also these that are not sure wins (e.g. not every KBNK position is won, even with white to move). The factor just corrects for the fact that in Pawn endings a much smaller naive advantage is on average decisive, and it is also awarded when there is no verified win. And that defending is much harder without any pieces.
The problem you mentioned is caused by artificially messing with the score for 'verified wins', as the almost unavoidable incompleteness of the list of those will then cause pathologic behavior. Usually end-games that would qualify as verified wins have high-enough score by themselves, and artificially upping the score by a large amount serves no purpose.
The problem you mentioned is caused by artificially messing with the score for 'verified wins', as the almost unavoidable incompleteness of the list of those will then cause pathologic behavior. Usually end-games that would qualify as verified wins have high-enough score by themselves, and artificially upping the score by a large amount serves no purpose.
-
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL
Re: Very cool bug inside Minic
I had one of those "moment" years ago. Was playing GM Dzhindi in a 4 computer vs 4 human round-robin tournament. Crafty had gotten into an easily won ending, and suddenly made two odd piece sacrifices to end up in a won KNN vs KP ending. Fortunately the Nalimov tables were active, which is what led to that set of moves. Looked ugly.