WinBoard Xiangqi package

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

Moderator: Ras

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

WinBoard Xiangqi package

Post by hgm »

I put a package for download on my website which contains the executable of an experimental WinBoard version, which implements Xiangqi rules for perpetual chasing when adjudicatng 3-fold repetitions.

It also contains a bitmap for an oriental-style Xiangqi board, and the true-type font needed to render oriental-style Xiangqi pieces. And the UCCI2WB.exe adapter that can be used to run any UCCI engine under WinBoard. And a shortcut to start it up as a viewer for PGN XQ games.

The link is:
http://home.hccnet.nl/h.g.muller/XQgui.zip
TonyJH
Posts: 183
Joined: Tue Jun 20, 2006 4:41 am
Location: USA

Re: WinBoard Xiangqi package

Post by TonyJH »

What algorithm or method does this version of WinBoard use to detect perpetual chase and perpetual check? Maybe this could be implemented in your variant ICS, too. Of course perpetual check applies to shogi, too (but I think shogi requires 4-fold repetition).
I like the Xiangqi font and board.
User avatar
hgm
Posts: 28405
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: WinBoard Xiangqi package

Post by hgm »

The algorithm I currently use is described here:

http://www.open-aurec.com/wbforum/viewt ... =4&t=50167

I already discovered that this does not fully coincide with Asia rules. The problem with Asia rules is that they are totally ambiguous and self-contradictory. For instance, in the definition of terms it says:

"Chase - A piece moves to a position where it can capture an opponent's piece, which is not the King, in the next move."

This seems clear enough. But then, from the zillions of examples they provide, it turns out that they also consider moving a piece in such a way that another piece can capture an opponent's piece. (Discovered threat, or Cannon activation). And from diagram 105 it even follows that chases include cases where you don't create the capture at all by moving the piece or unblocking it, but that captures that were already possible before might be considered chases when the 'protected' status of the victim is changed (by blocking an opponentpiece that was defending it). So now what if I would pin the protector of a piece that was and remains attacked, through unblocking one of my own pieces so that it pins it? Anybody's guess...

One problem with Asia rules is that some rules define cases that are allowed, rather than forbidden. Like it is not implied that anything that is not forbidden would be automatically allowed. As the rules don't nearly cover everything, the lack of such a default assumption is of course totally fatal, and renders them useless.

So far, an unambiguous rule that seems to cover all given examples would be:
hgm Asia rules wrote:If, after his move, side A, when he were allowed to play again, can capture with any piece X different from King or Pawn an unprotected opponent piece Y other than King or unpromoted Pawn, which he could not capture before his move, or which was protected before his move, A's move is considered to be chasing Y. Unless Y is of equal type as X, and can legally capture X with Y on the subsequent move, in which case we call it a sacrifice of X, rather than a chase of Y. A piece is considered unprotected if and only if, after it would be captured, the opponent has not a single legal move that recaptures on the same square, or if it was a Rook attacked by a Horse or Cannon. If one side chases the same piece for all moves in a repeat loop, he forfeits. If both or neither side does it, it is draw.
What I have implemented now enforces the above rule with omission of the italicised "or which was protected before his move". This addition makes the testing of the rule even more nasty: currently I just generate captures before and after the move, to get the new ones, and then look only for these new ones if the victim was protected or not (by performing the new capture, and generate opponent captures). But apparently I should also try and generate replies for pre-existing captures (i.e. for all captures possible after the move, in stead of just the new ones), and then similar look for captures on unprotected targets before the move, and remove these from the set.

I will certainly equip the ICS with a perpetual-chase test too. Once I have the ultimate one...