this thread will never end...
why should an engine consider an endgame 2 bishops vs knight a draw?
it is not only the end position that influences the game, but, most importantly, the search decisions the engine takes, where the above tbs position would be encountered thousands of times and (ir)relevant pruning decisions taken on this un(knowledge).
is not that equivalent to purposefully not finding the best move? and is not the best move the essence of computer chess? why purposefully prevent the engines from finding the best move?
what if the answer to the question which is the best first move and whether the game is a white win or a draw depend on that tbs 2 bishops vs knigth position? (quite possible) what if d4 is the best move, in case above tbs is a draw, and e4 the best move, in case above tbs is a win for the 2 bishops? would not we be lying to the engines, ourselves and the world in such a case? does not that make us funny?
certainly, it is much easier to change the 50-move rule accordingly only in the case of pawnless endgames.
Cursed win at TCEC
Moderators: hgm, Rebel, chrisw
-
- Posts: 6052
- Joined: Tue Jun 12, 2012 12:41 pm
Re: fortress_draw_rule
[d]8/4n3/4k3/8/8/4K1B1/2B5/8 w - - 0 1
why instruct the engine above position is a draw, when SF finds mate very quickly even at bullet?
[pgn][Event "Blitz 1m"]
[Site "Microsoft"]
[Date "2016.11.24"]
[Round "?"]
[White "Stockfish 8 64 POPCNT"]
[Black "Stockfish 8 , owner"]
[Result "1-0"]
[Annotator "owner"]
[SetUp "1"]
[FEN "8/4n3/4k3/8/8/4K1B1/2B5/8 w - - 0 1"]
[PlyCount "11"]
[TimeControl "60"]
{512MB, OWNER-PC} 1. Ke4 {4.81/27 2} Nc8 {4.82/27 2} 2. Bb3+ {5.08/31 3} Kd7 {
5.31/36 2} 3. Kd5 {5.31/40 1} Ne7+ {5.31/43 2} 4. Ke5 {5.45/32 1} Nc6+ {47.14/
29 2} 5. Kf6 {47.22/29 1} Nb4 {47.30/35 2} 6. Ba4+ {47.30/41 1} 1-0
[/pgn]
score rises from 5 pawns to 48 pawns very quickly, SF has seen mate.
what if SF has pruned above position, because its counter says 50-moves threshold, draw, to the benefit of this one
[d]2k5/pn6/1p6/2n5/8/4K1B1/PPB5/8 w - - 0 1
where SF shows 130cps white edge, though actually an easy draw.
why lie to the engine all along?
why make it choose suboptimal moves?
why instruct the engine above position is a draw, when SF finds mate very quickly even at bullet?
[pgn][Event "Blitz 1m"]
[Site "Microsoft"]
[Date "2016.11.24"]
[Round "?"]
[White "Stockfish 8 64 POPCNT"]
[Black "Stockfish 8 , owner"]
[Result "1-0"]
[Annotator "owner"]
[SetUp "1"]
[FEN "8/4n3/4k3/8/8/4K1B1/2B5/8 w - - 0 1"]
[PlyCount "11"]
[TimeControl "60"]
{512MB, OWNER-PC} 1. Ke4 {4.81/27 2} Nc8 {4.82/27 2} 2. Bb3+ {5.08/31 3} Kd7 {
5.31/36 2} 3. Kd5 {5.31/40 1} Ne7+ {5.31/43 2} 4. Ke5 {5.45/32 1} Nc6+ {47.14/
29 2} 5. Kf6 {47.22/29 1} Nb4 {47.30/35 2} 6. Ba4+ {47.30/41 1} 1-0
[/pgn]
score rises from 5 pawns to 48 pawns very quickly, SF has seen mate.
what if SF has pruned above position, because its counter says 50-moves threshold, draw, to the benefit of this one
[d]2k5/pn6/1p6/2n5/8/4K1B1/PPB5/8 w - - 0 1
where SF shows 130cps white edge, though actually an easy draw.
why lie to the engine all along?
why make it choose suboptimal moves?
-
- Posts: 27808
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: fortress_draw_rule
Because it is a draw?Lyudmil Tsvetkov wrote:why instruct the engine above position is a draw, when SF finds mate very quickly even at bullet?
Why lie to the engine by telling it it is a win?
[d]k7/8/1PK5/8/8/8/8/8 w
My engine finds a mate in 5 within milliseconds in the above position (1.b7+ Ka7 (1... Kb8? Kb6#) 2. K2.Kc7 Ka6 3.b8=Q Ka5 4.Qb3 Ka6 5.Qa4#). Why lie to it by saying it can draw?
-
- Posts: 2929
- Joined: Sat Jan 22, 2011 12:42 am
- Location: NL
Re: fortress_draw_rule
I'm not sure what point you think you're making?Lyudmil Tsvetkov wrote:[d]8/4n3/4k3/8/8/4K1B1/2B5/8 w - - 0 1
why instruct the engine above position is a draw, when SF finds mate very quickly even at bullet?
The position is apparently mate in 43 moves (starting with 1. Bb3+), so the 50 move rule is irrelevant even if the knight is not captured (which I haven't checked). Source: Nalimov tables from http://www.k4it.de/?topic=egtb&lang=en.
If you're saying adjudicating a game deprives the engine of the ability to mishandle a position, or swindle it's opponent, sure. Different discussion though.
So why isn't it reporting a mate-score, then?score rises from 5 pawns to 48 pawns very quickly, SF has seen mate.
The position is not a 50 move draw, so if it had done that there's a bug to fix.what if SF has pruned above position, because its counter says 50-moves threshold, draw, to the benefit of this one
You also seem to confuse "pruning" with returning the known evaluation (and stopping the search) in tablebase positions.
-
- Posts: 6052
- Joined: Tue Jun 12, 2012 12:41 pm
Re: fortress_draw_rule
but there is no mate.hgm wrote:Because it is a draw?Lyudmil Tsvetkov wrote:why instruct the engine above position is a draw, when SF finds mate very quickly even at bullet?
Why lie to the engine by telling it it is a win?
[d]k7/8/1PK5/8/8/8/8/8 w
My engine finds a mate in 5 within milliseconds in the above position (1.b7+ Ka7 (1... Kb8? Kb6#) 2. K2.Kc7 Ka6 3.b8=Q Ka5 4.Qb3 Ka6 5.Qa4#). Why lie to it by saying it can draw?
your engine is nuts.
-
- Posts: 7220
- Joined: Mon May 27, 2013 10:31 am
Re: fortress_draw_rule
Bug in stalemate detection.
-
- Posts: 6052
- Joined: Tue Jun 12, 2012 12:41 pm
Re: fortress_draw_rule
I specifically said 'during the search', but you seem not to read.Evert wrote:I'm not sure what point you think you're making?Lyudmil Tsvetkov wrote:[d]8/4n3/4k3/8/8/4K1B1/2B5/8 w - - 0 1
why instruct the engine above position is a draw, when SF finds mate very quickly even at bullet?
The position is apparently mate in 43 moves (starting with 1. Bb3+), so the 50 move rule is irrelevant even if the knight is not captured (which I haven't checked). Source: Nalimov tables from http://www.k4it.de/?topic=egtb&lang=en.
If you're saying adjudicating a game deprives the engine of the ability to mishandle a position, or swindle it's opponent, sure. Different discussion though.
So why isn't it reporting a mate-score, then?score rises from 5 pawns to 48 pawns very quickly, SF has seen mate.
The position is not a 50 move draw, so if it had done that there's a bug to fix.what if SF has pruned above position, because its counter says 50-moves threshold, draw, to the benefit of this one
You also seem to confuse "pruning" with returning the known evaluation (and stopping the search) in tablebase positions.
above position could be encountered by the engine at depth 20 (43+10=53>50) during search, and the tbs will instruct it it needs 43 moves more to mate, going over the 50-move threshold, so it will conisder it as a draw.
as a result, the engine will lose half a point with no reason at all; by choosing the other node it goes for its 'best' move, which actually is suboptimal to the tbs position, and results only in a draw.
I guess you can do the maths such choices are also statistically relevant; they will always do a disservice to the stronger engine.
-
- Posts: 27808
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: fortress_draw_rule
Not a bug, of course, it perfectly detects the stalemate. But is scores it as a win. Why lie to the engine by telling it it is a draw?Henk wrote:Bug in stalemate detection.
-
- Posts: 7220
- Joined: Mon May 27, 2013 10:31 am
Re: fortress_draw_rule
I don't dare to lie to the FIDE. Do you ?hgm wrote:Not a bug, of course, it perfectly detects the stalemate. But is scores it as a win. Why lie to the engine by telling it it is a draw?Henk wrote:Bug in stalemate detection.
-
- Posts: 6052
- Joined: Tue Jun 12, 2012 12:41 pm
Re: fortress_draw_rule
movement of pieces is primordial. mate is delivered only when the king is in check.hgm wrote:Not a bug, of course, it perfectly detects the stalemate. But is scores it as a win. Why lie to the engine by telling it it is a draw?Henk wrote:Bug in stalemate detection.
no strong case for changing mate definition with the addition of a 'stalemate' mate, with stronger side having big material advantage, but the king still not in check.
on the other hand, the case for extending the 50-move rule in the case of pawnless endgames is very strong, and will become stronger in the future.
if the first attack does not topple the 50-move rule, the second and the third will.