Makruk engines and rating list

[Evert]

About 88.6% of all KBQK positions with white to move is a (possibly cursed) win. This is quite low for a generally won end-game. The reason is that there are many positions where B or Q can be chased by the bare K to an edge, where it is then captured, if they start next to each other, and the B or Q cannot seek shelter with its own King. The average DTM is 32 moves, the max DTM is 57. The counting rule gives you only 40 moves to win, only about 7% of the won positions requires a longer win.

KBBK is another matter, though. 90.8% of the wtm positions is a (cursed) win. But the average DTM is 25.2, and the counting rule gives you only 18 moves. Only a minor fraction of the positions is a real win now.

Just what this game needs: a higher draw rate. Either way, I need to keep track of this in my tablebase code (it detects cursed wins where the DTM is larger than the remaining 50-move rule; should not be hard to adapt).

[Ferdy]

There is a big difference between an engine that knows the counting rule and the engine that does not know it.

I don't see how knowing the counts could help other than in a very approximate way. Unless in tablebases, of course, where you know the exact DTM in all positions. E.g. if you can convert into KBQK from KBPKP, knowing that you get 44 - 4 = 40 moves to win it is no help if you don't know whether the position has DTM = 39 or 41. There is no way the engine would be able to calculate upto the checkmate, at such DTM (where in addition the conversion might occur close to the leaves). There is no heuristic that can give you the DTM accurate to a single move; if there was, tablebases would never be needed. At best you can hope for a quite inaccurate estimate of the DTM, and this would already be pretty complex. And even then knowing it is likely a won position is not worth much if the engine is not capable of DTM-perfect play. So the estimate of the likelihood that a given position can in practice be won must be extracted from empirically determined game length (against perfect play?) when the engine tries to win the game under its own power. Which likely is TC dependent.

E.g. in the first game against Alisa 98. b6=M+ is probably a blunder, because with two 'Bishops' you only get 22-7 = 15 moves to win KBBQQKR, while the latter (if it is won at all) probably takes far longer. If the engine would have recognized KBBQQKR as drawish, it would probably have refrained from promoting, and thus as long as it wants to first corner the enemy King in KBBQPKR as much as it can, and only promote when it gets the mate within the horizon.

BTW, for computer Makruk we really need an equivalent to the 50-move rule, or some games could take thousands of years. I propose to supplemet the counting rules with the rule that 64 reversible moves make a draw even when there still are Pawns.

The counting rule that I am talking about also includes a knowledge of a position without pawn and bare king. This is a big difference for an engine that does not know it.
See here.
http://talkchess.com/forum/viewtopic.ph ... 99&t=63178

with two 'Bishops' you only get 22-7 = 15 moves to win KBBQQKR,

That is a wrong calculation because black has still a rook.

If there is no rook for example, like kbbqqk, it would be 22-6=16.

I don't agree with that proposal. Just let the repetition ends the game if there is no progress.
If you are talking about a gui, better provide a user with adjudication options.

[hgm]

Ah, OK. Because it is not a bare King, you get 64 - 7 = 57 moves. The end-game could be drawn anyway; even when I play white by hand to what I consider a favorable position (black King cofined to the 8th rank) the Rook can harrass me so much that I could not find a checkmate.

The problem is that with multiple pieces engines can postpone draws forever, if they both think they are ahead. E.g. KBNKBQQ is nearly equal, and who considers himself ahead depends critically on the piece values. The white side alone can go through 256K positions before a first repeat.

[Evert]

Ah, OK. Because it is not a bare King, you get 64 - 7 = 57 moves. The end-game could be drawn anyway; even when I play white by hand to what I consider a favorable position (black King cofined to the 8th rank) the Rook can harrass me so much that I could not find a checkmate.

Because the count does not reset on capture (unless the disadvantaged side decides otherwise), it's even worse: all black has to do is delay the inevitable long enough, that is 15 moves. Then he just sacrifices his rook for a Ferz, declares his unwillingness to restart the count, and claims a draw because the count has reached the target.
It's a shame, because the ending is actually quite interesting.

The problem is that with multiple pieces engines can postpone draws forever, if they both think they are ahead. E.g. KBNKBQQ is nearly equal, and who considers himself ahead depends critically on the piece values. The white side alone can go through 256K positions before a first repeat.

Agreed.

[hgm]

The counting rule that I am talking about also includes a knowledge of a position without pawn and bare king. This is a big difference for an engine that does not know it.
See here.
http://talkchess.com/forum/viewtopic.ph ... 99&t=63178

I am not completely sure what you are arguing there, but it seems more a plea for end-game tables than for counting rules. And indeed, many of the end-games are very difficult, and Fairy-Max could not win them at all on its own search. I had to give it some knowledge in the form of DTM of a few (48) key positions to allow it to win KNQQK with like Q and KBQK. These are loaded from the file makruk.hash into the hash table at the start of a makruk game, and act as a "poor man's tablebase". If perfect play is required, a full DTM tablebase seems the only feasible way. KBBQQKR is 7-men, though. At long TC generating 5-men EGT on the fly is feasible, but 6-men would already be a problem.

[Ferdy]

Ah, OK. Because it is not a bare King, you get 64 - 7 = 57 moves.

That is correct.

The problem is that with multiple pieces engines can postpone draws forever, if they both think they are ahead. E.g. KBNKBQQ is nearly equal, and who considers himself ahead depends critically on the piece values. The white side alone can go through 256K positions before a first repeat.

This ending is subject to 64-7 = 57 move draw.
I have observed ending like this played by Bilis tests. Each engine would try to centralize their king (or avoid being sent to the corner), in doing so pieces get exchanged because they would defend their comfort zones, if not they would go for repetitions.

[Ferdy]

The counting rule that I am talking about also includes a knowledge of a position without pawn and bare king. This is a big difference for an engine that does not know it.
See here.
http://talkchess.com/forum/viewtopic.ph ... 99&t=63178

I am not completely sure what you are arguing there

I am trying to show you that your statement below is not fully right.

Code: Select all

The counting rules are of little relevance to an engine, as it will always tries to achieve the fastest mate.

[hgm]

Well, I still don't see how what you say has any bearing on that. Having EGTs does help, for sure. But then the cursed wins can be indicated in the table, without the engine knowing the counting rules (E.g. they could be tabulated with DTM > 64, and the probing code could return DTM/100 in those cases rather than INF-DTM). And without EGT I don't see how you could use knowledge about the counting in any way. Other than by scaling the evaluation of known drawish end-games (where non-naturally drawish end-games such as KBQK) might become drawish by the counting rules) towards zero in the usual way.

[Ferdy]

Well, I still don't see how what you say has any bearing on that.

Here is an example.
Engine1 does not know the rule of counting. Engine2 knows the rule of counting. A position arises where promoting the last pawn would limit the number of moves to be finished by move 64. If none is get mated it would be declared as draw after 64 moves. Engine2 would not promote such pawn instead it would maximize its position driving its opp king and pieces into unfavorable positions first.
For engine1 it might promote so it would now be limited to a 64 move draw. Can't you see the difference?

[hgm]

I see the difference. But for this engine 1 only has to know that the end-game after Pawn trading is drawish. It does not have to know that it is drawish because of the counting rule, or intrinsically drawish such as KNNK. And it would not help to know how much the exact count is. If it sees a mate, it will convert, if not, the eval score will be scaled so much that converting will probably be unattractive. If it does see a mate, it will be within the count limit, because it will in general not be able to search upto that limit. (An exception could be baring the King when it has two Rooks, where the count could be very small or negative.)