XBoard for Mac: draw non-recognition, feature or bug?

[hgm]

The problem here is that while XBoard tries to observe FIDE rules, there just isn't an easy way to test if a given position is a true draw by insufficient material. In a recent game with XBoard adjudication activated, Symbolic was forfeited after claiming a draw in KBKN -- and the draw was proven by the tablebases.

Only KK, KBK, KNK and KBKB with like Bishops (where XBoard in fact considers the possesion of many Bishops on the same square shade as if it is just a single one) can be claimed as a draw.

That a position is a draw according to tablebases (i.e. with best play) doesn't mean a thing. The opening position is almost certainly a draw with best play, but that doesn't mean you should be able to claim one. The whole idea of Chess is that the players should prove their worth on the board, not by proxy of a superior entity.

I agree that you have to be exceedingly stupid to lose end-games like KBKN, KNNK or KRKR, and that it is usually a waste of time to play those out. This is why XBoard has an adjudication option for "trivial draws", which adjudicates them. But adjudication is a GUI/referee thing, and the engine/player has no say in it, and cannot do anything special to prevent or force it.

Of course it is always possible to assign the engine also the role of referee. (In variants unknown to XBoard this even is a necessity.) To do that ou simply untick the "Verify engine claims" option, and XBoard would believe it at any time when the engine terminates the game by a RESULT command (i.e. 0-1, 1-0 or 1/2-1/2). E.g. when playing 'King of the Hill' the engine must be able to claim a win when his King has reached the center.

[sje]

In fact it is incredibly straightforward to test draw by insufficient material by FIDE's rules. If there's a helpmate, it's not insufficient material as there exists a sequence of legal moves to a checkmate position.

Please provide a C/C++/whatever routine which can read an arbitrary chess position and then quickly determine if it a helpmate. Recall some of the positions posted earlier in this thread, and you'll find that such a task is not as straightforward as it first might appear.

[hgm]

The point is that the protocol does not allow you to use the 1/2-1/2 command on any of those. This fall under "trying to outsmart the GUI". In general GUIs will not be smart enough to recognize positions where checkmate is impossible because of an unsolvable blockade. So claiming those as draws will unavoidably lead the GUI to qualify the claim as a false one.

In fact all of this trouble is cause by mixing inconsistent ideas. There is no need for engines to claim any insufficient-material draws if the GUI is aware of the rules for those. If the GUI is, and it is set to check engine claims. If the GUI isn't, the corresponding adjudication and claim verification should be switched off, so that the GUI will bow to whatever the engine claims.

Having both the engine and the GUI make such claims is just asking for trouble. The only thing that is guaranteed is that GUIs will recognize KK, KBK and KNK as insufficient material. So if you limit engine claims to those cases, any trouble you might run into is an obvious GUI error.

[sje]

What I've done is to change Symbolic's idea of insufficient material to be KK, KNK, and KBK only. To help test this, I've started another 100 game match vs tscp, but this time with XBoard adjudication verification activated. Hopefully there will be no false claims, no false forfeits, and no glitches.

[sje]

What I've done is to change Symbolic's idea of insufficient material to be KK, KNK, and KBK only. To help test this, I've started another 100 game match vs tscp, but this time with XBoard adjudication verification activated. Hopefully there will be no false claims, no false forfeits, and no glitches.

This has finished and everything looks okay. Still no stalemate results, however.

[JoshPettus]

I'm pretty sure stalemate would be a blunder on the engine's part, so that's a good thing.

It's funny how stalemate has become so synonymous with "draw" even though it's something specific.

[bob]

After a 100 game 1min/+1sec match Symbolic vs tscp run by XBoard, there were no glitches and all the scores were assigned properly. However, there were no stalemates, so not all paths were tested.

Match score was 73-17-13 giving Symbolic an Elo 220 points higher than tscp. Note that at this stage of the re-write, Symbolic is single threaded, does not ponder, does not have transposition score storage, and has only a very simple evaluation function. Its book works well, posting works well, and it probes the tablebases (residing on an SSD) at every node where there are five or fewer men.

Chess Elo Rating Difference Calculator: http://www.3dkingdoms.com/chess/elo.htm

I've now started a 100 game match Symbolic vs FairyMax, mostly to confirm XBoard interoperation.

You can always use gcc + gcov to be sure all statements are executed there.

[sje]

So far and with no gltiches:

Code: Select all

2015-08-20 100 1m+1s vs tscp 73-17-10 elo+220
2015-08-21 100 1m+1s vs tscp 71-21-08 elo+191

I let a match vs FairyMax run twenty games where Symbolic checkmated 18 times and won on the clock twice.

At present, XBoard is validating engine result claims, but doing nothing else listed on its Adjudication dialog. XBoard is also auto-flagging, but that's about it. This seems to work okay so far, including a 100 game match of Symbolic vs the day-old version of itself.

When XBoard is told to quit, it doesn't seem to send a quit directive to the engines, at least with protocol version one. I will soon upgrade the Symbolic re-write to version two, as this will be needed for ICS play. Perhaps I can run an instance connected to HGM's server for testing before returning to FICS/ICC after a long absence.

There is still much code to be added: decent time allocation, transposition table scores/flags, better move ordering, a real evaluation function, pondering, remaining UCI support, and a general multithreaded search.

[matthewlai]

What I've done is to change Symbolic's idea of insufficient material to be KK, KNK, and KBK only. To help test this, I've started another 100 game match vs tscp, but this time with XBoard adjudication verification activated. Hopefully there will be no false claims, no false forfeits, and no glitches.

I found an easier way is to still include helpmates in my engine's evaluation, that way it can evaluate those positions accurately in search, and just never claim draws.

In CECP there's really no need at all for an engine to send "1/2-1/2" at any point. If you think the position is draw, just send "offer draw", and continue as if nothing happened.

If the GUI agrees, it will treat the offer as a claim. If it doesn't, it's treated as an offer, and you play on.

There's no advantage to sending "1/2-1/2" in any situation.

[sje]

There's no advantage to sending "1/2-1/2" in any situation.

Symbolic handles all mates consistently. It sends 1/2-1/2 on stalemates, just as it sends 1-0 or 0-1 on checkmates.