Cursed win at TCEC

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

Moderators: hgm, Harvey Williamson, bob

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
whereagles
Posts: 533
Joined: Thu Nov 13, 2014 11:03 am

Re: fortress_draw_rule

Post by whereagles » Thu Nov 24, 2016 4:51 am

Actually, if you check TCEC page at facebook, Anton says he's considering changing the score. Quite likely he's also reading our discussion.

Norm Pollock
Posts: 1011
Joined: Thu Mar 09, 2006 3:15 pm
Location: Long Island, NY, USA
Contact:

Re: fortress_draw_rule

Post by Norm Pollock » Thu Nov 24, 2016 5:19 am

I think this discussion transcends the actual tcec match between SF8 and H5.

It gets to the heart of a major difference between human and computer chess, namely that chess engines, especially with tbs, can see tactical consequences many, many more moves ahead. Hence, should rules be adjusted?

Here is a comparable, but highly hypothetical, situation. Suppose with scientific advances in nutrition, etc, basketball players grew to a height of 11 feet. Should the height of the basket be raised from 10 feet?

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

Re: fortress_draw_rule

Post by syzygy » Thu Nov 24, 2016 8:26 am

Norm Pollock wrote:I think this discussion transcends the actual tcec match between SF8 and H5.

It gets to the heart of a major difference between human and computer chess, namely that chess engines, especially with tbs, can see tactical consequences many, many more moves ahead. Hence, should rules be adjusted?
Why would we want to stop chess engines from finding a tactical escape 65 moves ahead into a draw by the fifty-move rule?

Anyway, there have also been many human games where the fifty-move rule cut short a victory that was in sight. Too bad for the "winning" human: he should have played moves that made progress faster (or he never had a win).

Note that TBs that know about the 50-move rule also allow the engine to play optimally according to that rule: where a DTM table may still squander a real win to the 50-move rule, with a TB aware of the 50-move rule such wins will be converted. This type of accuracy is of course way beyond human capabilities. But should we therefore ban it?

Your basketball analogy leads me to (computer) chess on a 16x16-board. Not to chess without a 50-move rule in selected situations.

whereagles
Posts: 533
Joined: Thu Nov 13, 2014 11:03 am

Re: fortress_draw_rule

Post by whereagles » Thu Nov 24, 2016 8:42 am

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.

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

Re: fortress_draw_rule

Post by Lyudmil Tsvetkov » Thu Nov 24, 2016 9:30 am

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.

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

Re: fortress_draw_rule

Post by Lyudmil Tsvetkov » Thu Nov 24, 2016 9:46 am

[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?

User avatar
hgm
Posts: 22516
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: fortress_draw_rule

Post by hgm » Thu Nov 24, 2016 10:35 am

Lyudmil Tsvetkov wrote:why instruct the engine above position is a draw, when SF finds mate very quickly even at bullet?
Because it is a draw?

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?

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

Re: fortress_draw_rule

Post by Evert » Thu Nov 24, 2016 10:50 am

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.

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

Re: fortress_draw_rule

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

hgm wrote:
Lyudmil Tsvetkov wrote:why instruct the engine above position is a draw, when SF finds mate very quickly even at bullet?
Because it is a draw?

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?
but there is no mate.

your engine is nuts.

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

Re: fortress_draw_rule

Post by Henk » Thu Nov 24, 2016 11:31 am

Bug in stalemate detection.

Post Reply