Page 21 of 30
Re: fortress_draw_rule
Posted: Thu Nov 24, 2016 12:37 pm
by Lyudmil Tsvetkov
Evert wrote: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?
I'm not sure what point you think you're making?
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.
score rises from 5 pawns to 48 pawns very quickly, SF has seen mate.
So why isn't it reporting a mate-score, then?
what if SF has pruned above position, because its counter says 50-moves threshold, draw, to the benefit of this one
The position is not a 50 move draw, so if it had done that there's a bug to fix.
You also seem to confuse "pruning" with returning the known evaluation (and stopping the search) in tablebase positions.
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.
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.
Re: fortress_draw_rule
Posted: Thu Nov 24, 2016 12:56 pm
by hgm
Henk wrote:Bug in stalemate detection.
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?
Re: fortress_draw_rule
Posted: Thu Nov 24, 2016 1:00 pm
by Henk
hgm wrote:Henk wrote:Bug in stalemate detection.
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?
I don't dare to lie to the FIDE. Do you ?
Re: fortress_draw_rule
Posted: Thu Nov 24, 2016 1:29 pm
by Lyudmil Tsvetkov
hgm wrote:Henk wrote:Bug in stalemate detection.
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?
movement of pieces is primordial. mate is delivered only when the king is in check.
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.
Re: fortress_draw_rule
Posted: Thu Nov 24, 2016 2:33 pm
by Evert
Lyudmil Tsvetkov wrote:Evert wrote: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?
I'm not sure what point you think you're making?
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.
score rises from 5 pawns to 48 pawns very quickly, SF has seen mate.
So why isn't it reporting a mate-score, then?
what if SF has pruned above position, because its counter says 50-moves threshold, draw, to the benefit of this one
The position is not a 50 move draw, so if it had done that there's a bug to fix.
You also seem to confuse "pruning" with returning the known evaluation (and stopping the search) in tablebase positions.
I specifically said 'during the search', but you seem not to read.
You don't understand.
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.
Re: fortress_draw_rule
Posted: Thu Nov 24, 2016 5:59 pm
by hgm
Lyudmil Tsvetkov wrote: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?
but there is no mate.
your engine is nuts.
Interesting that you seem to know this concept. Now if you could only apply it to your own postings...
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.
Re: fortress_draw_rule
Posted: Thu Nov 24, 2016 9:23 pm
by syzygy
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.
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...
Re: fortress_draw_rule
Posted: Thu Nov 24, 2016 9:29 pm
by syzygy
Evert wrote: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?
I'm not sure what point you think you're making?
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.
Yes, one side to this discussion is rather unwilling to understand the stuff he's talking about.
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.
Re: fortress_draw_rule
Posted: Thu Nov 24, 2016 9:33 pm
by syzygy
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.
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.
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.
No, you are simply talking about a topic you don't understand very well.
Re: fortress_draw_rule
Posted: Thu Nov 24, 2016 9:52 pm
by zenpawn
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.
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?).