Mate score handling in Arena, for XBoard protocol?

[mvanthoor]

Hi,

Does anyone know what Arena expects as a mate score when running an engine in the XBoard protocol?

I've implemented mate score reporting in Rustic's XBoard protocol this evening, and it seems to work fine in XBoard itself. When the engine analyzes a position in which it has mate in 4 moves (4 moves for its own side, not ply), it correctly reports +100004. If it is analyzing a position in which it will be mated by 3 moves of its opponent, it correctly reports -100003. XBoard displays #4 and #-3, which according to its changelog is correct. (It specifically mentions this.)

However, Arena displays +M500 if the engine is winning by mate (so it does seem to recognize something, from that +100004 value), and nothing when the engine is being mated.

Does someone know what Arena expects? I could add a command-line switch to make Rustic 4's XBoard-protocol Arena-compatible in this regard. (But that is as far as I'm willing to go to accommodate a specific user interface, and only because Arena is so often used.) I looked into XBoard's git-history to see what came before this mate reporting (added in 2015 according to the changelog), but there seems to be nothing; there were just three lines added to do the mate reporting with that 100000 score, and before those, the XBoard protocol seems to be doing nothing special to report mate.

[mar]

I've no idea what Arena interprets as a mate score, AFAIK there's no consensus on what a mate score should be in xboard protocol.
what I do in my engine is that I simply append ;mate n after xboard PV if the engine has found a mate, because I prefer xboard protocol when analyzing
from the command line. might work in general in any GUI

the most transparent way would be to tell the GUI the mate score range of the engine to the GUI, say via feature after protover 2, but it's probably too late to fix

[Ras]

When the engine analyzes a position in which it has mate in 4 moves (4 moves for its own side, not ply), it correctly reports +100004.

That doesn't make sense because mate in 4 should be scored lower, not higher, than mate in 3. So for positive mates, I'd expect the move number to be subtracted from +100000. That may be the reason why Arena displays M500 - as indication that the engine thinks it is going to deliver mate, but the mate score is borked so that no mate distance can be evaluated. Similarly for negative mates where being mated in 3 is worse than being mated in 4 so that the mate in 3 should receive a lower score.

Then again, the CECP spec describes it as you say, but CECP itself doesn't make sense, and each engine/GUI implements something else anyway.

[mvanthoor]

I've no idea what Arena interprets as a mate score, AFAIK there's no consensus on what a mate score should be in xboard protocol.
what I do in my engine is that I simply append ;mate n after xboard PV if the engine has found a mate, because I prefer xboard protocol when analyzing
from the command line. might work in general in any GUI

the most transparent way would be to tell the GUI the mate score range of the engine to the GUI, say via feature after protover 2, but it's probably too late to fix

It seems there's only a consensus since 2015; according to XBoard's changelog. It says that it implements a new mate score protocol, which is the one I described.

That doesn't make sense because mate in 4 should be scored lower, not higher, than mate in 3. So for positive mates, I'd expect the move number to be subtracted from +100000. That may be the reason why Arena displays M500 - as indication that the engine thinks it is going to deliver mate, but the mate score is borked so that no mate distance can be evaluated. Similarly for negative mates where being mated in 3 is worse than being mated in 4 so that the mate in 3 should receive a lower score.

But that's just it: this is not a score. In UCI, the engine reports "mate 3" or "mate 4" if it is finding a mate for the playing side. CECP specs say to report +100003 and +100004. In UCI, the engine reports "mate -3" if the side it is searching for is being mated, and in CECP this is -100003. The big number is just a way to lift it outside the range of normal evaluation values.

Then again, the CECP spec describes it as you say, but CECP itself doesn't make sense, and each engine/GUI implements something else anyway.

That's indeed the reason why I probably won't implement it in another engine anymore (if I ever create another engine that is); I'll probably support it in a GUI just for completeness sake. Compared to UCI however, the protocol and its states are a lot of work to get right.

[Ras]

(if I ever create another engine that is)

So, no specific plans for Zigic yet?

[mvanthoor]

(if I ever create another engine that is)

So, no specific plans for Zigic yet?

Blargh. Whenever I look into Zig to see where it's at, I see a pared-down version of Rust. I'd rather port Rustic to FreePascal, just because Pascal was my first language. (And I still think to this day that between C and Pascal, the latter is the better language. If it only had pointers and case-sensitivity in its first version in the 70's...) I've looked into some of Roland Chastain's Pascal engines, and they're REALLY easy to understand an read (with regard to program structure that is), and I haven't read Pascal code for over 20 years.

And I think having one engine is enough. I want to write a Rust-based replacement for PicoChess first (because PicoChess is written in Python, and it's a massive mess) and a GUI that I can actually use without wanting to run up the walls. (The only one I've found through the years is Fritz 11 to be honest.)