Makruk engines and rating list

[Ferdy]

Created a page here, with bullet rating so far.

https://sites.google.com/view/makruks/home

[tmokonen]

I converted SamChess to play Makruk a few years ago, but never uploaded it to my site, thinking it was too weak for some reason. You can download it here:

http://tmokonen.net84.net/SamChess-MK.rar

There are three different executables, the only difference between the three being material values.

[IanO]

Thanks! I modified my Forth TSCP derivative to play Makruk, but it is too weak to mention. Since the endgame in Makruk is so important, any serious engine should have hash and mine doesn't work right yet.

[hgm]

Note that HaChu also plays Makruk. Very poorly, no doubt, because it was never tuned or even tested for it. But it was close enough to (dropless) Shogi variants to also program the rules in it. A Windows binary for HaChu can be found in the WinBoard Shogi Varinants package.

[Ferdy]

I converted SamChess to play Makruk a few years ago, but never uploaded it to my site, thinking it was too weak for some reason. You can download it here:

http://tmokonen.net84.net/SamChess-MK.rar

There are three different executables, the only difference between the three being material values.

Does it support the counting rules?
I am revising Bilis to fully understand the counting rules.

The tournament i run was not using the counting rule. But later i will use the counting rule. I hope HGM will implement it in winboard.

[Ferdy]

Thanks! I modified my Forth TSCP derivative to play Makruk, but it is too weak to mention. Since the endgame in Makruk is so important, any serious engine should have hash and mine doesn't work right yet.

Does it support counting rules?
This variant is drawish which is good for human in human vs engjne than human vs engine in chess.

[Ferdy]

Note that HaChu also plays Makruk. Very poorly, no doubt, because it was never tuned or even tested for it. But it was close enough to (dropless) Shogi variants to also program the rules in it. A Windows binary for HaChu can be found in the WinBoard Shogi Varinants package.

Does it upport counting rules?

[tmokonen]

No, sorry Ferdinand, there's no support for the counting rules as of yet.

[hgm]

Does it upport counting rules?

No it doesn't support counting rules. The counting rules are of little relevance to an engine, as it will always tries to achieve the fastest mate. As the counting doesn't reset on a capture, there are no issues similar to DTZ50 in chess, and if playing by shortest DTM isn't fast enough, there isn't anything you can do to avoid a draw (other than hoping the opponent blunders).

So the only occasion on which it matters is when you trade into an end-game that is made drawish by the counting rules, although it has a very favorable 'naive evaluation'. This is similar to trading into KBK or KNNK in chess. The solution would be to scale the naive evaluation in such end-games towards a draw.

But the affected end-games are all against bare King. So the effect of the scaling would be avoiding capture of the opponent's last piece. This can be programmed without detailed knowledge of counting rules.

A scenario I can imagine that would cause problems is in a K+2R+Pawns vs K+R position, that the Rook basically becomes a rabid Rook, because taking it wouldbare the King, and leave you too few moves because of your own 2R to win. But engines are of course notoriously bad at recognizing rabid Rook, even when they would recognize taking it means draw.

I can implement the counting rules in WinBoard.

[Ferdy]

Does it upport counting rules?

No it doesn't support counting rules. The counting rules are of little relevance to an engine, as it will always tries to achieve the fastest mate. As the counting doesn't reset on a capture, there are no issues similar to DTZ50 in chess, and if playing by shortest DTM isn't fast enough, there isn't anything you can do to avoid a draw (other than hoping the opponent blunders).

So the only occasion on which it matters is when you trade into an end-game that is made drawish by the counting rules, although it has a very favorable 'naive evaluation'. This is similar to trading into KBK or KNNK in chess. The solution would be to scale the naive evaluation in such end-games towards a draw.

But the affected end-games are all against bare King. So the effect of the scaling would be avoiding capture of the opponent's last piece. This can be programmed without detailed knowledge of counting rules.

A scenario I can imagine that would cause problems is in a K+2R+Pawns vs K+R position, that the Rook basically becomes a rabid Rook, because taking it wouldbare the King, and leave you too few moves because of your own 2R to win. But engines are of course notoriously bad at recognizing rabid Rook, even when they would recognize taking it means draw.

I can implement the counting rules in WinBoard.

There is a big difference between an engine that knows the counting rule and the engine that does not know it. There is also an art in capturing the last pawn of opponent and/or promoting your last pawn. The ending is also an art of minimal pieces remaining on the board with less number of moves to mate the opponent.
Example krqq vs k
required_moves_to_mate = 16 - (k+r+q+q+k) = 16-5 = 11.
This is difficult if queens and king are not positioned favorably or if both queens are of the same color.
Without rook say with bishop and queens or knights, the engine should be equipped with a knowledge on how to mate the weaker side quickly because of this counting rule.

I have tried Bilis vs human players and it is difficult to win against a human that knew very well this rule even if Bilis has some material advantages. Certain knowledge should be added.

It would be nice if you can implement the rule in winboard so that we can see the real variant at work. It seems to me that when both engines entered the ending (without pawns or bare king), the game would not last longer, but if both engines are clever trying to win by not exchanging their last pawns and avoiding repetitions too, it would be a lot longer as it seems this variant has no 50-move draw rule.