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.
Cursed win at TCEC
Moderators: hgm, Rebel, chrisw
-
- Posts: 7220
- Joined: Mon May 27, 2013 10:31 am
Re: fortress_draw_rule
-
- 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.
-
- Posts: 2929
- Joined: Sat Jan 22, 2011 12:42 am
- Location: NL
Re: fortress_draw_rule
You don't understand.Lyudmil Tsvetkov wrote: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.
As soon as you capture into a 5-man position you access the tablebase. The capture, of course, reset the 50-move counter. The situation you scetch never occurs because the search never probes the tablebase excpt when the 50-move counter is 0.
-
- Posts: 27808
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: fortress_draw_rule
Interesting that you seem to know this concept. Now if you could only apply it to your own postings...Lyudmil Tsvetkov wrote:but there is no mate.hgm wrote: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.
But you don't seem to understand much about Chess. There is a mate: after 5.Qa4 the position is
[d]8/2K5/k7/8/Q7/8/8/8 b
and there is no placethe black King can go without being captured. So black definitely lost.
-
- Posts: 5566
- Joined: Tue Feb 28, 2012 11:56 pm
Re: fortress_draw_rule
Indeed, engines not using tablebases would need to be told to ignore the 50-move rule for 5-piece positions. Or maybe also for 6-piece positions. Depending on what... their opponent? What an utter mess...whereagles wrote:Right now TCEC can easily change cutechess adjudication to fully enforce the 50-moves rule. This is the simplest way out and does not require any action from engine programmers.
For the record, I support allowing cursed wins, but that would require engines to be programmed accordingly. Engines that use TBs where you can switch off the 50-moves rule would be easy to adjust. But engines without that switch or without tablebases would require more complex adjustments and I'm not sure TCEC would want that at this stage.
-
- Posts: 5566
- Joined: Tue Feb 28, 2012 11:56 pm
Re: fortress_draw_rule
Yes, one side to this discussion is rather unwilling to understand the stuff he's talking about.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.
https://syzygy-tables.info/?fen=8/4n3/4 ... _w_-_-_0_1
DTZ=59, so white can force a mate or winning capture in under 30 moves.
If this were impossible to win within the 50-move rule, SF would be expected not to find a mate in the first place. After all, SF knows about and accepts the 50-move rule.
-
- Posts: 5566
- Joined: Tue Feb 28, 2012 11:56 pm
Re: fortress_draw_rule
The only way to reach this position "during the search" is by a capture from 6 to 5 pieces. The capture resets the 50-move counter. So a probe during the search only needs to check whether the position is won with DTZ <= 100 ply.Lyudmil Tsvetkov wrote:I specifically said 'during the search', but you seem not to read.
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.
No, you are simply talking about a topic you don't understand very well.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.
-
- Posts: 349
- Joined: Sat Aug 06, 2016 8:31 pm
- Location: United States
Re: fortress_draw_rule
That's good news. In that post, he mentions: "Both engine authors have submitted their opinion to the TCEC team." Hearkening back to my question some pages ago, I'm glad to hear the devs did indeed write to the organizer, with presumably even the SF team in favor of it being a draw (yes?).whereagles wrote:Actually, if you check TCEC page at facebook, Anton says he's considering changing the score. Quite likely he's also reading our discussion.
-
- Posts: 6052
- Joined: Tue Jun 12, 2012 12:41 pm
Re: fortress_draw_rule
rigth, I missed the fact that, in order to arrive at a tbs position, the last move should be a capture.Evert wrote:You don't understand.Lyudmil Tsvetkov wrote: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.
As soon as you capture into a 5-man position you access the tablebase. The capture, of course, reset the 50-move counter. The situation you scetch never occurs because the search never probes the tablebase excpt when the 50-move counter is 0.
essentially this changes nothing though, you just have to use tbs mates that go over the 50-move counter.
looking at TCEC, SF shows frequently more than 30 000 000 tbs hits, if 1% of those are so called "cursed wins", this makes 300 000 cursed win hits. Imagine the impact on search decisions, gameplay and picking the best move.
-
- Posts: 6052
- Joined: Tue Jun 12, 2012 12:41 pm
Re: fortress_draw_rule
rigth, the last move must be a capture.syzygy wrote:The only way to reach this position "during the search" is by a capture from 6 to 5 pieces. The capture resets the 50-move counter. So a probe during the search only needs to check whether the position is won with DTZ <= 100 ply.Lyudmil Tsvetkov wrote:I specifically said 'during the search', but you seem not to read.
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.
No, you are simply talking about a topic you don't understand very well.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.
essentially, what changes this though? any tbs mate longer than 50 moves will be considered as a draw, this node will return a score of 0.0, while another node, with no tbs hits and a score of, say 40cps, objectively a draw in the eg, will be considered by the engine stronger than the 0.0 cursed win node.
this definitely has implications on choosing the best move. why consider a node that is draw with slightly positive score better than a node with 0.0 score, objectively though a win?
during search, an engine might hit hundreds of thousands similar cursed win nodes, and take decisions accordingly. the impact on game play should not be small.