Cursed win at TCEC

Discussion of anything and everything relating to chess playing software and machines.

Moderators: hgm, Harvey Williamson, bob

Lyudmil Tsvetkov
Posts: 6033
Joined: Tue Jun 12, 2012 10:41 am

Re: fortress_draw_rule

Post by Lyudmil Tsvetkov » Thu Nov 24, 2016 11:37 am

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.

User avatar
hgm
Posts: 22184
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Contact:

Re: fortress_draw_rule

Post by hgm » Thu Nov 24, 2016 11:56 am

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?

Henk
Posts: 5077
Joined: Mon May 27, 2013 8:31 am

Re: fortress_draw_rule

Post by Henk » Thu Nov 24, 2016 12:00 pm

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 ?

Lyudmil Tsvetkov
Posts: 6033
Joined: Tue Jun 12, 2012 10:41 am

Re: fortress_draw_rule

Post by Lyudmil Tsvetkov » Thu Nov 24, 2016 12:29 pm

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. :)

User avatar
Evert
Posts: 2895
Joined: Fri Jan 21, 2011 11:42 pm
Location: NL
Contact:

Re: fortress_draw_rule

Post by Evert » Thu Nov 24, 2016 1:33 pm

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.

User avatar
hgm
Posts: 22184
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Contact:

Re: fortress_draw_rule

Post by hgm » Thu Nov 24, 2016 4:59 pm

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.

syzygy
Posts: 4221
Joined: Tue Feb 28, 2012 10:56 pm

Re: fortress_draw_rule

Post by syzygy » Thu Nov 24, 2016 8:23 pm

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...

syzygy
Posts: 4221
Joined: Tue Feb 28, 2012 10:56 pm

Re: fortress_draw_rule

Post by syzygy » Thu Nov 24, 2016 8:29 pm

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.

syzygy
Posts: 4221
Joined: Tue Feb 28, 2012 10:56 pm

Re: fortress_draw_rule

Post by syzygy » Thu Nov 24, 2016 8:33 pm

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.

zenpawn
Posts: 260
Joined: Sat Aug 06, 2016 6:31 pm
Location: United States

Re: fortress_draw_rule

Post by zenpawn » Thu Nov 24, 2016 8:52 pm

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?).

Post Reply