Few small bugs on version 4.4.3

Discussions about the WinBoard protocol. Here you can also report bugs and request new features.

Moderators: hgm, Andres Valverde

Re: Few small bugs on version 4.4.3

Postby H.G.Muller » 01 Jul 2010, 19:08

OK, I tried your EON tablebase viewer. Very nice!

So it can take upto 18 moves before you can force a winning conversion in KRKEEAA. Definitely non-trivial, and comparable to KQKQ in Chess. I did group KQKQ under the trivial draws, btw, but I have always had my doubts about it.

You report that 84% of the positions are won. I assume this is of the positions with red to move. This is a lot, but I know such numbers can be very misleading. In Chess, tablebases of end-games that are dead draws usually contain 50-60% wins, while truly won end-games contain typically >95% wins when the winning side has the move. Most of these 'wins' are trivial conversions in a single move (capturing a hanging piece), in tactically non-quiet positions. I don't know how the typical numbers are in Xiangqi.

Ideally the GUI would be in possession of a W/D/L bitbase for these end-games, and use that info for adjudication (if the user selected that option).
User avatar
H.G.Muller
 
Posts: 3453
Joined: 16 Nov 2005, 12:02
Location: Diemen, NL

Re: Few small bugs on version 4.4.3

Postby Nguyen Pham » 04 Jul 2010, 08:47

I start to list all trivial draw of Xiangqi here so we can discuss one by one. List all cases is a hard and boring job - I do it with the help from a simple program.
I divide all cases into three big groups:

I. Draw in any situation: none can win, none can lose the game event he wants to suicide

II. Draw if none is being mated in 1 moves (1-2 ply) and none wants to suicide

III. Draw if none is being mated in n moves (n>1) and all knows basic skill to draw
Nguyen Pham
 
Posts: 36
Joined: 27 Jun 2010, 08:40

Re: Few small bugs on version 4.4.3

Postby Nguyen Pham » 04 Jul 2010, 09:03

I. Draw in any situation

1) Draw when two sides have defenders left only (no attacking pieces) - 81 cases
KK; KKA; KKAA; KKE; KKEE; KKAE; KKAAE; KKAEE; KKAAEE; KAK; KAKA; KAKAA; KAKE; KAKEE; KAKAE; KAKAAE; KAKAEE; KAKAAEE; KAAK; KAAKA; KAAKAA; KAAKE; KAAKEE; KAAKAE; KAAKAAE; KAAKAEE; KAAKAAEE; KEK; KEKA; KEKAA; KEKE; KEKEE; KEKAE; KEKAAE; KEKAEE; KEKAAEE; KEEK; KEEKA; KEEKAA; KEEKE; KEEKEE; KEEKAE; KEEKAAE; KEEKAEE; KEEKAAEE; KAEK; KAEKA; KAEKAA; KAEKE; KAEKEE; KAEKAE; KAEKAAE; KAEKAEE; KAEKAAEE; KAAEK; KAAEKA; KAAEKAA; KAAEKE; KAAEKEE; KAAEKAE; KAAEKAAE; KAAEKAEE; KAAEKAAEE; KAEEK; KAEEKA; KAEEKAA; KAEEKE; KAEEKEE; KAEEKAE; KAEEKAAE; KAEEKAEE; KAEEKAAEE; KAAEEK; KAAEEKA; KAAEEKAA; KAAEEKE; KAAEEKEE; KAAEEKAE; KAAEEKAAE; KAAEEKAEE; KAAEEKAAEE;
Count = 81

2) Draw when one side has only one or few old Pawns left (pawns in the last rank)
I remove cases when one Pawn can win 2 Advisors or 2-5 Pawns win 1 Advisors and store them in group 2

KPK; KPKA; KPKE; KPKEE; KPKAE; KPKAAE; KPKAEE; KPKAAEE; KPAK; KPAKA; KPAKE; KPAKEE; KPAKAE; KPAKAAE; KPAKAEE; KPAKAAEE; KPAAK; KPAAKA; KPAAKE; KPAAKEE; KPAAKAE; KPAAKAAE; KPAAKAEE; KPAAKAAEE; KPEK; KPEKA; KPEKE; KPEKEE; KPEKAE; KPEKAAE; KPEKAEE; KPEKAAEE; KPEEK; KPEEKA; KPEEKE; KPEEKEE; KPEEKAE; KPEEKAAE; KPEEKAEE; KPEEKAAEE; KPAEK; KPAEKA; KPAEKE; KPAEKEE; KPAEKAE; KPAEKAAE; KPAEKAEE; KPAEKAAEE; KPAAEK; KPAAEKA; KPAAEKE; KPAAEKEE; KPAAEKAE; KPAAEKAAE; KPAAEKAEE; KPAAEKAAEE; KPAEEK; KPAEEKA; KPAEEKE; KPAEEKEE; KPAEEKAE; KPAEEKAAE; KPAEEKAEE; KPAEEKAAEE; KPAAEEK; KPAAEEKA; KPAAEEKE; KPAAEEKEE; KPAAEEKAE; KPAAEEKAAE; KPAAEEKAEE; KPAAEEKAAEE;
Count=72

KPPK; KPPKE; KPPKEE; KPPKAE; KPPKAAE; KPPKAEE; KPPKAAEE; KPPAK; KPPAKE; KPPAKEE; KPPAKAE; KPPAKAAE; KPPAKAEE; KPPAKAAEE; KPPAAK; KPPAAKE; KPPAAKEE; KPPAAKAE; KPPAAKAAE; KPPAAKAEE; KPPAAKAAEE; KPPEK; KPPEKE; KPPEKEE; KPPEKAE; KPPEKAAE; KPPEKAEE; KPPEKAAEE; KPPEEK; KPPEEKE; KPPEEKEE; KPPEEKAE; KPPEEKAAE; KPPEEKAEE; KPPEEKAAEE; KPPAEK; KPPAEKE; KPPAEKEE; KPPAEKAE; KPPAEKAAE; KPPAEKAEE; KPPAEKAAEE; KPPAAEK; KPPAAEKE; KPPAAEKEE; KPPAAEKAE; KPPAAEKAAE; KPPAAEKAEE; KPPAAEKAAEE; KPPAEEK; KPPAEEKE; KPPAEEKEE; KPPAEEKAE; KPPAEEKAAE; KPPAEEKAEE; KPPAEEKAAEE; KPPAAEEK; KPPAAEEKE; KPPAAEEKEE; KPPAAEEKAE; KPPAAEEKAAE; KPPAAEEKAEE; KPPAAEEKAAEE;
Count=63

KPPPK; KPPPKE; KPPPKEE; KPPPKAE; KPPPKAAE; KPPPKAEE; KPPPKAAEE; KPPPAK; KPPPAKE; KPPPAKEE; KPPPAKAE; KPPPAKAAE; KPPPAKAEE; KPPPAKAAEE; KPPPAAK; KPPPAAKE; KPPPAAKEE; KPPPAAKAE; KPPPAAKAAE; KPPPAAKAEE; KPPPAAKAAEE; KPPPEK; KPPPEKE; KPPPEKEE; KPPPEKAE; KPPPEKAAE; KPPPEKAEE; KPPPEKAAEE; KPPPEEK; KPPPEEKE; KPPPEEKEE; KPPPEEKAE; KPPPEEKAAE; KPPPEEKAEE; KPPPEEKAAEE; KPPPAEK; KPPPAEKE; KPPPAEKEE; KPPPAEKAE; KPPPAEKAAE; KPPPAEKAEE; KPPPAEKAAEE; KPPPAAEK; KPPPAAEKE; KPPPAAEKEE; KPPPAAEKAE; KPPPAAEKAAE; KPPPAAEKAEE; KPPPAAEKAAEE; KPPPAEEK; KPPPAEEKE; KPPPAEEKEE; KPPPAEEKAE; KPPPAEEKAAE; KPPPAEEKAEE; KPPPAEEKAAEE; KPPPAAEEK; KPPPAAEEKE; KPPPAAEEKEE; KPPPAAEEKAE; KPPPAAEEKAAE; KPPPAAEEKAEE; KPPPAAEEKAAEE;
Count=63

KPPPPK; KPPPPKE; KPPPPKEE; KPPPPKAE; KPPPPKAAE; KPPPPKAEE; KPPPPKAAEE; KPPPPAK; KPPPPAKE; KPPPPAKEE; KPPPPAKAE; KPPPPAKAAE; KPPPPAKAEE; KPPPPAKAAEE; KPPPPAAK; KPPPPAAKE; KPPPPAAKEE; KPPPPAAKAE; KPPPPAAKAAE; KPPPPAAKAEE; KPPPPAAKAAEE; KPPPPEK; KPPPPEKE; KPPPPEKEE; KPPPPEKAE; KPPPPEKAAE; KPPPPEKAEE; KPPPPEKAAEE; KPPPPEEK; KPPPPEEKE; KPPPPEEKEE; KPPPPEEKAE; KPPPPEEKAAE; KPPPPEEKAEE; KPPPPEEKAAEE; KPPPPAEK; KPPPPAEKE; KPPPPAEKEE; KPPPPAEKAE; KPPPPAEKAAE; KPPPPAEKAEE; KPPPPAEKAAEE; KPPPPAAEK; KPPPPAAEKE; KPPPPAAEKEE; KPPPPAAEKAE; KPPPPAAEKAAE; KPPPPAAEKAEE; KPPPPAAEKAAEE; KPPPPAEEK; KPPPPAEEKE; KPPPPAEEKEE; KPPPPAEEKAE; KPPPPAEEKAAE; KPPPPAEEKAEE; KPPPPAEEKAAEE; KPPPPAAEEK; KPPPPAAEEKE; KPPPPAAEEKEE; KPPPPAAEEKAE; KPPPPAAEEKAAE; KPPPPAAEEKAEE; KPPPPAAEEKAAEE;
Count=63

KPPPPPK; KPPPPPKE; KPPPPPKEE; KPPPPPKAE; KPPPPPKAAE; KPPPPPKAEE; KPPPPPKAAEE; KPPPPPAK; KPPPPPAKE; KPPPPPAKEE; KPPPPPAKAE; KPPPPPAKAAE; KPPPPPAKAEE; KPPPPPAKAAEE; KPPPPPAAK; KPPPPPAAKE; KPPPPPAAKEE; KPPPPPAAKAE; KPPPPPAAKAAE; KPPPPPAAKAEE; KPPPPPAAKAAEE; KPPPPPEK; KPPPPPEKE; KPPPPPEKEE; KPPPPPEKAE; KPPPPPEKAAE; KPPPPPEKAEE; KPPPPPEKAAEE; KPPPPPEEK; KPPPPPEEKE; KPPPPPEEKEE; KPPPPPEEKAE; KPPPPPEEKAAE; KPPPPPEEKAEE; KPPPPPEEKAAEE; KPPPPPAEK; KPPPPPAEKE; KPPPPPAEKEE; KPPPPPAEKAE; KPPPPPAEKAAE; KPPPPPAEKAEE; KPPPPPAEKAAEE; KPPPPPAAEK; KPPPPPAAEKE; KPPPPPAAEKEE; KPPPPPAAEKAE; KPPPPPAAEKAAE; KPPPPPAAEKAEE; KPPPPPAAEKAAEE; KPPPPPAEEK; KPPPPPAEEKE; KPPPPPAEEKEE; KPPPPPAEEKAE; KPPPPPAEEKAAE; KPPPPPAEEKAEE; KPPPPPAEEKAAEE; KPPPPPAAEEK; KPPPPPAAEEKE; KPPPPPAAEEKEE; KPPPPPAAEEKAE; KPPPPPAAEEKAAE; KPPPPPAAEEKAEE; KPPPPPAAEEKAAEE;
Count=63

3. The same situation if two sides have only old pawns
KPKP; KPKPA; KPKPE; KPKPEE; KPKPAE; KPKPAAE; KPKPAEE; KPKPAAEE; KPAKP; KPAKPA; KPAKPE; KPAKPEE; KPAKPAE; KPAKPAAE; KPAKPAEE; KPAKPAAEE; KPEKP; KPEKPA; KPEKPE; KPEKPEE; KPEKPAE; KPEKPAAE; KPEKPAEE; KPEKPAAEE; KPEEKP; KPEEKPA; KPEEKPE; KPEEKPEE; KPEEKPAE; KPEEKPAAE; KPEEKPAEE; KPEEKPAAEE; KPAEKP; KPAEKPA; KPAEKPE; KPAEKPEE; KPAEKPAE; KPAEKPAAE; KPAEKPAEE; KPAEKPAAEE; KPAAEKP; KPAAEKPA; KPAAEKPE; KPAAEKPEE; KPAAEKPAE; KPAAEKPAAE; KPAAEKPAEE; KPAAEKPAAEE; KPAEEKP; KPAEEKPA; KPAEEKPE; KPAEEKPEE; KPAEEKPAE; KPAEEKPAAE; KPAEEKPAEE; KPAEEKPAAEE; KPAAEEKP; KPAAEEKPA; KPAAEEKPE; KPAAEEKPEE; KPAAEEKPAE; KPAAEEKPAAE; KPAAEEKPAEE; KPAAEEKPAAEE;
Count=64

KPPKPP; KPPKPPE; KPPKPPEE; KPPKPPAE; KPPKPPAAE; KPPKPPAEE; KPPKPPAAEE; KPPEKPP; KPPEKPPE; KPPEKPPEE; KPPEKPPAE; KPPEKPPAAE; KPPEKPPAEE; KPPEKPPAAEE; KPPEEKPP; KPPEEKPPE; KPPEEKPPEE; KPPEEKPPAE; KPPEEKPPAAE; KPPEEKPPAEE; KPPEEKPPAAEE; KPPAEKPP; KPPAEKPPE; KPPAEKPPEE; KPPAEKPPAE; KPPAEKPPAAE; KPPAEKPPAEE; KPPAEKPPAAEE; KPPAAEKPP; KPPAAEKPPE; KPPAAEKPPEE; KPPAAEKPPAE; KPPAAEKPPAAE; KPPAAEKPPAEE; KPPAAEKPPAAEE; KPPAEEKPP; KPPAEEKPPE; KPPAEEKPPEE; KPPAEEKPPAE; KPPAEEKPPAAE; KPPAEEKPPAEE; KPPAEEKPPAAEE; KPPAAEEKPP; KPPAAEEKPPE; KPPAAEEKPPEE; KPPAAEEKPPAE; KPPAAEEKPPAAE; KPPAAEEKPPAEE; KPPAAEEKPPAAEE;
Count=49

KPPPKPPP; KPPPKPPPE; KPPPKPPPEE; KPPPKPPPAE; KPPPKPPPAAE; KPPPKPPPAEE; KPPPKPPPAAEE; KPPPEKPPP; KPPPEKPPPE; KPPPEKPPPEE; KPPPEKPPPAE; KPPPEKPPPAAE; KPPPEKPPPAEE; KPPPEKPPPAAEE; KPPPEEKPPP; KPPPEEKPPPE; KPPPEEKPPPEE; KPPPEEKPPPAE; KPPPEEKPPPAAE; KPPPEEKPPPAEE; KPPPEEKPPPAAEE; KPPPAEKPPP; KPPPAEKPPPE; KPPPAEKPPPEE; KPPPAEKPPPAE; KPPPAEKPPPAAE; KPPPAEKPPPAEE; KPPPAEKPPPAAEE; KPPPAAEKPPP; KPPPAAEKPPPE; KPPPAAEKPPPEE; KPPPAAEKPPPAE; KPPPAAEKPPPAAE; KPPPAAEKPPPAEE; KPPPAAEKPPPAAEE; KPPPAEEKPPP; KPPPAEEKPPPE; KPPPAEEKPPPEE; KPPPAEEKPPPAE; KPPPAEEKPPPAAE; KPPPAEEKPPPAEE; KPPPAEEKPPPAAEE; KPPPAAEEKPPP; KPPPAAEEKPPPE; KPPPAAEEKPPPEE; KPPPAAEEKPPPAE; KPPPAAEEKPPPAAE; KPPPAAEEKPPPAEE; KPPPAAEEKPPPAAEE;
Count=49

KPPPPKPPPP; KPPPPKPPPPE; KPPPPKPPPPEE; KPPPPKPPPPAE; KPPPPKPPPPAAE; KPPPPKPPPPAEE; KPPPPKPPPPAAEE; KPPPPEKPPPP; KPPPPEKPPPPE; KPPPPEKPPPPEE; KPPPPEKPPPPAE; KPPPPEKPPPPAAE; KPPPPEKPPPPAEE; KPPPPEKPPPPAAEE; KPPPPEEKPPPP; KPPPPEEKPPPPE; KPPPPEEKPPPPEE; KPPPPEEKPPPPAE; KPPPPEEKPPPPAAE; KPPPPEEKPPPPAEE; KPPPPEEKPPPPAAEE; KPPPPAEKPPPP; KPPPPAEKPPPPE; KPPPPAEKPPPPEE; KPPPPAEKPPPPAE; KPPPPAEKPPPPAAE; KPPPPAEKPPPPAEE; KPPPPAEKPPPPAAEE; KPPPPAAEKPPPP; KPPPPAAEKPPPPE; KPPPPAAEKPPPPEE; KPPPPAAEKPPPPAE; KPPPPAAEKPPPPAAE; KPPPPAAEKPPPPAEE; KPPPPAAEKPPPPAAEE; KPPPPAEEKPPPP; KPPPPAEEKPPPPE; KPPPPAEEKPPPPEE; KPPPPAEEKPPPPAE; KPPPPAEEKPPPPAAE; KPPPPAEEKPPPPAEE; KPPPPAEEKPPPPAAEE; KPPPPAAEEKPPPP; KPPPPAAEEKPPPPE; KPPPPAAEEKPPPPEE; KPPPPAAEEKPPPPAE; KPPPPAAEEKPPPPAAE; KPPPPAAEEKPPPPAEE; KPPPPAAEEKPPPPAAEE;
Count=49

KPPPPPKPPPPP; KPPPPPKPPPPPE; KPPPPPKPPPPPEE; KPPPPPKPPPPPAE; KPPPPPKPPPPPAAE; KPPPPPKPPPPPAEE; KPPPPPKPPPPPAAEE; KPPPPPEKPPPPP; KPPPPPEKPPPPPE; KPPPPPEKPPPPPEE; KPPPPPEKPPPPPAE; KPPPPPEKPPPPPAAE; KPPPPPEKPPPPPAEE; KPPPPPEKPPPPPAAEE; KPPPPPEEKPPPPP; KPPPPPEEKPPPPPE; KPPPPPEEKPPPPPEE; KPPPPPEEKPPPPPAE; KPPPPPEEKPPPPPAAE; KPPPPPEEKPPPPPAEE; KPPPPPEEKPPPPPAAEE; KPPPPPAEKPPPPP; KPPPPPAEKPPPPPE; KPPPPPAEKPPPPPEE; KPPPPPAEKPPPPPAE; KPPPPPAEKPPPPPAAE; KPPPPPAEKPPPPPAEE; KPPPPPAEKPPPPPAAEE; KPPPPPAAEKPPPPP; KPPPPPAAEKPPPPPE; KPPPPPAAEKPPPPPEE; KPPPPPAAEKPPPPPAE; KPPPPPAAEKPPPPPAAE; KPPPPPAAEKPPPPPAEE; KPPPPPAAEKPPPPPAAEE; KPPPPPAEEKPPPPP; KPPPPPAEEKPPPPPE; KPPPPPAEEKPPPPPEE; KPPPPPAEEKPPPPPAE; KPPPPPAEEKPPPPPAAE; KPPPPPAEEKPPPPPAEE; KPPPPPAEEKPPPPPAAEE; KPPPPPAAEEKPPPPP; KPPPPPAAEEKPPPPPE; KPPPPPAAEEKPPPPPEE; KPPPPPAAEEKPPPPPAE; KPPPPPAAEEKPPPPPAAE; KPPPPPAAEEKPPPPPAEE; KPPPPPAAEEKPPPPPAAEE;
Count=49
Nguyen Pham
 
Posts: 36
Joined: 27 Jun 2010, 08:40

Re: Few small bugs on version 4.4.3

Postby Nguyen Pham » 04 Jul 2010, 09:31

4. Cannon without same color Advisor can't win (except one case mate in 1 when opposite has two Advisors)

KCK; KCKA; KCKE; KCKEE; KCKAE; KCKAEE; KCEK; KCEKA; KCEKE; KCEKEE; KCEKAE; KCEKAEE; KCEEK; KCEEKA; KCEEKE; KCEEKEE; KCEEKAE; KCEEKAEE;
Count=18

5. The same situation when two sides have Cannons without supporting from Advisor

KCKC; KCKCE; KCKCEE; KCEKC; KCEKCE; KCEKCEE; KCEEKC; KCEEKCE; KCEEKCEE;
Count=9
Nguyen Pham
 
Posts: 36
Joined: 27 Jun 2010, 08:40

Re: Few small bugs on version 4.4.3

Postby H.G.Muller » 04 Jul 2010, 14:16

I think cases like KPKAAEE should also be transferred to group 2, as black could blunder away his Elephants to convert to KPKAA. So in stead of scratching 9, we would have to scratch 27, as for each KP...KAA there will be versions with 1 and 2 Elephants as well. (Leaving 54.)

Similarly, KPP...KA can occur with 1 or two extra Elephants, possibly in combination with one extra Advisor, so 6x9=54 variations, leaving only 27 that are certain draws.

I guess we could use regular expressions, where X* means any number of X, to compactify the notation. (Any number meaning upto the maximu that XQ allows for that piece type.)

Theoretical draws:

No Advisors (each side can have any number of stale Pawns):
KP*E*KP*E* (6x6x3x3=324)
One Advisor (the opponent can have at most one Pawn):
KP*AE*KE* (6x3x3=54)
KP*AE*KPE* (6x3x3=54)
Two advisors on one side (opponent cannot have Pawns):
KP*AAE*KE* (6x3x3=54)
One Advisor each (both can have 0 or 1 Pawn):
KAE*KAE* (3x3=9)
KPAE*KAE* (3x3=9)
KAE*KPAE* (3x3=9)
KPAE*KPAE* (3x3=9)
Two against one Advisor (can have at most one Pawn, opponent none):
KAAE*KAE* (3x3=9)
KPAAE*KAE* (3x3=9)
Two against two Advisors (no Pawns allowed):
KAAE*KAAE* (3x3=9)

Note that the cases with unequal number of Advisors can also occur with reversed colors.
Total count:
324 + 2x108 + 2x54 + 36 + 2x18 + 9 = 729

I guess there are also cases where you have a Cannon plus old Pawns, and no Advisors. E.g. KCPE*KE*. The other side cannot have Advisors then.

It would be good to split the problem into two, so one can independently test if either side has mating potential. If only one side lacks it, this is still relevant, as in this case time losses for his opponent should be corrected to draws. The theoretical-draw case then simply occurs when both sides lack mating potential. The following rules seem to cover that:

You have no mating potential (for one side) if you have
1) A*E*
2) (old)PA*E*:
the opponent has at most one A, and no H, C or R (which could trap his King so even the old P can mate it).
3) PPP*A*E*:
the opponent has no A, H, C or R
4) CE*:
the opponent does not have A + (A,C or R)
5) (old)P*CE*:
the opponent has no A, H, C or R

Case (4) is actually a bit tricky. It is conceivable that the opponent has so much material that one of his pieces could get trapped on the back-rank, and act as non-retractable platform for the Cannon. E.g. if he would have two Cannons (on g9 and g8) and a Rook (on e8) his King could get mated on e9 by Ch9. In such cases the opponent wil always have mating potential, though. So for determining theoretical draws this will not matter.
User avatar
H.G.Muller
 
Posts: 3453
Joined: 16 Nov 2005, 12:02
Location: Diemen, NL

Re: Few small bugs on version 4.4.3

Postby H.G.Muller » 05 Jul 2010, 10:33

Umm, it occurred to me that you can actually win with KCKCEE against a cooperating opponent:

5keC1/5c3/8e/9/9/9/9/9/9/3K5 b
User avatar
H.G.Muller
 
Posts: 3453
Joined: 16 Nov 2005, 12:02
Location: Diemen, NL

Re: Few small bugs on version 4.4.3

Postby H.G.Muller » 05 Jul 2010, 12:23

Even an unpromoted f-Pawn can be a liability, in the C + old P case:

2P1k1P2/9/9/4p4/9/9/9/9/4C4/4K4 b

[edit] I was wrong about the case where both have C too. Only KCKC is draw, there can be no Elephants with it (4kc3/9/9/9/9/9/9/4E4/9/3KC4). And against C+E, a single A can already be fatal (9/9/4ka3/9/9/9/9/4E4/9/3KC4). I edited the followingaccordingly.

This is really getting complicated... Let me try to summarize. (All mentioned P are old.) One side has no mating potential if he has:

0) KA*E*
1) KPA*E*, except when the opponent has AA or H, C or R (always possibly plus other stuff)
2) KPPP*A*E*, except when the opponent has at least one A, H, C or R
3) KC, except when the opponent has A+(A,H,C or R) or EE+(H,C or R)
4) KCEE*, except when the opponent has at least one (A,C, or R) or HEE
5) KCPP*, except when the opponent has at least one (A,H,C or R)

KCPE has mating potential all by itself (4k1p2/9/9/9/9/9/9/4E4/9/3KC4). In case (5) there is one other exception, KCPPKP with the unpromoted f-Pawn. This is not a very important exception for determination of theoretical draw, as the unpromoted f-Pawn will equip the opponent with mating potential. The same could be said for most non-A exceptions to (1)-(5). Of practical importance are the cases where the opponent has an A-less C, though, as this will not always equip him with mating potential. This affects the cases KPP*KCE*, KCEKC and KCPP*KC, which are not draw, while KPP*KE*, KCEK and KCPP*K are draw.
User avatar
H.G.Muller
 
Posts: 3453
Joined: 16 Nov 2005, 12:02
Location: Diemen, NL

Re: Few small bugs on version 4.4.3

Postby Nguyen Pham » 09 Jul 2010, 05:34

Your last summary is excellent!!!

I have been thinking for few days to check them and if we can add some more (no more so far). Every thing seems be perfect!

Of course we may always ignore some "crazy" positions - otherwise we can't continue nor do anything. I have listed one of them (crazy positions) here as a fun for this weekend. You also need to know it in case of future debates. It is an amazing answer for "can KA*E* side win?". The KA*E* side actually can win in few moves in the following position:

3aka3/4h4/9/2p6/9/9/9/E4A2E/4Kcppp/3Ahrrcp w - - - 1

Perhaps will we move to group 2 (mate in 1)?
Nguyen Pham
 
Posts: 36
Joined: 27 Jun 2010, 08:40

Re: Few small bugs on version 4.4.3

Postby Nguyen Pham » 09 Jul 2010, 07:23

You may include an exception for the case A*E* (as well as all others) when opponent has AAH + none E + some others:

3aka3/4h4/9/9/9/9/9/9/9/4K4 w - - - 1
3aka3/4h4/9/9/9/9/9/4K4/9/3AcA3 w - - - 1
3aka3/4h4/9/9/9/9/9/4K4/9/3AhA3 w - - - 1
3aka3/4h4/9/9/9/9/9/3K5/9/3AcA3 w - - - 1
Nguyen Pham
 
Posts: 36
Joined: 27 Jun 2010, 08:40

Re: Few small bugs on version 4.4.3

Postby H.G.Muller » 09 Jul 2010, 10:10

OK, so even a bare King can still win, against KHAA. I never realized that.

The following code might capture everything:

Code: Select all
int MatingPotential(int n[NR_COLORS][NR_PIECE_TYPES], int side, int myPHCR, int myOldP)
{
  int my = side, his = WHITE+BLACK - side;
  int majors = 5*n[his][H] + 7*n[his][C] + 7*n[his][R];
  myPHCR -= n[my][A] + n[my][E] + myOldP; // discount defenders and old Pawns
  if(myPHCR + myOldP == 1) // KA*E*
    return n[his][A] == 2 && n[his][H] > 0; // covers the crazy KKHAA positions above
  if(myPHCR > 2) return TRUE // if we have no P, H or R here, we must have CC
  if(myPHCR == 2 && n[my][C] == 0) return TRUE; // has exactly one H, R or fresh P.
  // if we get here, we have either KC... or KP..., with only additional A, E or old P
  if(myOldP) // we have old Pawns
    return
            majors // KPKX
        || n[his][A] && myOldP + n[my][C] + n[his][A] > 2 // KPKAA, KPPKA, and KCPKA
        || n[my][C] && UnpromotedCentralPawn(his); // KCPKP
  else // we have KCA*E*
    return
           n[my][A] // KCAK
        || n[my][E] && n[his][A] + n[his][C] + n[his][R] > 0 // KCEKX (X != H)
        || majors + (12*n[his][A] | 6*n[his][E]) > 16 // KCKAX, KCKEEX, KCKEXX (XX != HH), KCKXXX
        || majors + n[his][A] && UnpromotedCentralPawn(his); // KCKPX
}

if(!MatingPotential(pieceCounts, WHITE, totalW, oldW) &&
   !MatingPotential(pieceCounts, BLACK, totalB, oldB)   ) GameEnds(DRAW); // theoretical draw
User avatar
H.G.Muller
 
Posts: 3453
Joined: 16 Nov 2005, 12:02
Location: Diemen, NL

Re: Few small bugs on version 4.4.3

Postby H.G.Muller » 09 Jul 2010, 16:36

I am moving to the 'trivial draws' now. Only cases not captured by the "insufficient mating material" test would get to this stage. I am thinking mainly for cases where one or both sides still have some attacking material, but the opponent has overwhelmingly strong defense compared to that material. (As this seems to be the most common case by far.And it is quite annoying when one of the engines insists continuing in, say, KHAAEEKHAEE because he is an A ahead.)

I am not sure what should be considered "sufficient defense", though. My initial thoughts on this were

Against R: AAEE
Against H: AA or E
Against P: A or E
Against HP: AAEE
Against PP: AAE or AEE

You already made clear that there are quite some exceptions to this. I am not striving for 100% accuracy, though; people that want 100% accuracy should simply swicth off this type of adjudication. In Chess I currently adjudicate KQKQ as a trivial draw, which is also not entirely correct.

I have looked at the KRKAAEE end-game with EON, and it seems that in most lost positions you need a pretty scattered fortress to begin with. Would there be a simple heuristic to exclude these? (E.g., can I be save to assume draw with K on the back rank, and both A on that Rank or the one before it, if the opponent cannot gain material within 3 moves?)

For KHKAA and KHKE I am not even sure if there really are no slow wins (> 3 moves), just like KPKA. Is an AAEE fortress in good shape sufficient defense against KHP? How about against KHH or KHPP? (I had some indication KHHKAAEE is always won.) Is AEE or AAE already good enough against KHP?

What defense is sufficient against C+A? I noticed KCAKAA is usually won, but KCAKEE not.

For cases where both have attacking material, my initial thoughts were to adjudicate:

- KRKR with any number of As or Es on either side. I noticed that KHPKR is usually won, but how much defensive material would be needed to neutralize the Pawn? Are KHPKRA and KHPKRE safe?

- Similarly KHKH, but the 6-move win you mentioned makes me doubt the wisdom of this. But would it be safe to adjudicate it if each side has at least one additional defender? How much defense would be needed if one side was ahead an extra Pawn?
User avatar
H.G.Muller
 
Posts: 3453
Joined: 16 Nov 2005, 12:02
Location: Diemen, NL

Ambiguous moves?

Postby Nguyen Pham » 10 Jul 2010, 12:12

When checking Xiangqi games saved by WB, I found a game with the first part as the following. All cases dealing with Pawns. Not sure if there is any extra PNG rule for Pawns. Can you check?
1) The move 32 of Black ab4 is unique, thus may b4 be enough?
2) The move 33 of Black c4 is not unique. There are two Pawns can also move to that square. Should be P5c4?

[Event "Computer Chess Game"]
1. Hc2 c5 2. Ra1 Hg7 3. Ce2 Cc7 4. Ea2 Rh9 5. Hg2 Ha7 6. Rh0 Rb9 7. Rh4 Rb3
8. Rd1 Rxc3 9. Hce1 Ade8 10. Rd8 Ch8 11. Rd5 g5 12. g4 gxg4 13. Rxg4 Ege7
14. Rh4 Rxa3 15. Cbd2 a5 16. Hc2 Cxc2 17. Cxc2 Rc3 18. Rh7 Rxc2 19. Ce2 Hb5
20. Rxg7 Hc3 21. Ec4 Hxe2 22. Ecxe2 Ch1 23. Ade1 Rb2 24. Rg6 Rh3 25. i4 Rb4
26. Rxe6 Rxi4 27. Re4 Rxe4 28. exe4 Rg3 29. Rh5 Cg1 30. Hi1 Rb3 31. Ec0 a4
32. Ege2 ab4 33. Rh4 c4
Nguyen Pham
 
Posts: 36
Joined: 27 Jun 2010, 08:40

Re: Few small bugs on version 4.4.3

Postby H.G.Muller » 10 Jul 2010, 14:27

I am not sure if there are any official rules for Xiangqi PGN. The system I use in WB was made up by myself. It works in analogy with Chess. Pawn moves there are treated special. For one, there is no piece identifier used on them. But on captures, there is always something before the 'x' in SAN. You write exd5 when e4 captures d5, even if the move is ambiguous, and xd5 would have been sufficient.

I interpreted this as this as always indicating the from-file when you change file (captures in Chess), and hence omission of the from-file on a Pawn move as implying that you stay in the same file (non-captures in Chess). I kept this system for Xiangqi, except that it also always writes the from-file on captures to the same file (e.g. exe5).

So 33. c4 implies c5-c4 (same file), and in 32. ... ab4 the from-file was (superfluously) written to indicate a file change.

This system is unambiguous, but it might be non-standard. It might indeed be more logical to only write unnecessary from-file identifiers in the case of a capture, and reserve them on non-captures for cases where there is true ambiguity. I can still easily change to that system, as it only affects writing of the PGN, and WB would remain able to read either format. (Provided I keep the rule that in case of ambiguity in a Pawn move the move that stays in the same file is chosen rather than generating an ambiguous-move error.)
User avatar
H.G.Muller
 
Posts: 3453
Joined: 16 Nov 2005, 12:02
Location: Diemen, NL

Problems when editing Xiangqi position

Postby Nguyen Pham » 12 Jul 2010, 16:48

Few problems/confusing when I have started editing a Xiangqi position:
- Bishop, Archbishop, Chancellor creates not Bishop/Advisor pieces. To create a correct Advisor, I have to use Queen (big confusion, isn't it?)
- Knight of course is OK for us, but Horse may be a better choice for normal Asian understanding. Similar, Advisor is better than others
- It seems that you do not check legal positions for pieces? For Western chess, only Pawn may be wrongly located in 8 of 64 positions so it is not a big problem. But for Xiangqi, K, A, E, P need to check seriously.
Nguyen Pham
 
Posts: 36
Joined: 27 Jun 2010, 08:40

Re: Few small bugs on version 4.4.3

Postby H.G.Muller » 12 Jul 2010, 18:10

Indeed, the piece-setup menu is one of the ill-developed parts of WinBoard. Ideally every variant should have its own menu, listing only the pieces allowed in that variant, under the names commonly used for them in that variant. At the time I was adding the variants to WinBoard I did not know enough about Windows programming to change menu items. And I did not consider the Edit-Position menu very important, becasue I almost always loaded positions myself by pasting a FEN (or typing it in the move-input popup). So I did compromise a lot there. Queen was already used for a piece moving as Advisor in someother variants (notably Shatranj), and in WinBoard 4.2.7 it was actually represented by a Queen symbol on the board as well. So it seemed a natural choice.

By now I know more about Windows programming, and would easily be able to fix it. But what is stopping me is that we actually want to deprecate this menu altogether, and change to a pictorial representation of the available pieces. (And similarly for promotions, but that does not concern Xiangqi.) There already exists an experimental XBoard version where this works. (But not in the main line):

Image

Image

As to legality checking: there are some pros and cons there. Very strict enforcement of the rules would decrease the usefulness of WB for variants. There is for instance a Xiangqi variant where under some conditions Elephants and Advisors on the back-rank are allowed to promote to Pawns, leading to Pawns in places they cannot occur in orthodox XQ. And some UCCI engines actually are able to play that variant. I wan WinBoard to be usable as GUI for that variant too.

Another concern is to allow some flexibility during the setting up, when changing one crowded position into another. (This is what the edit-Position mode is most useful for.) There it often occurs that you have to swap pieces, so you cannot move every piece immediately to where it should go. So it could be a legitimite desire to temporarily "park" a piece on a square where it could never go (just because it is nearby and empty), to make room for another one, so that you can later move it back to its final position. (Which is in general faster than invoking the menu to create the piece.) To keep this possible, the legality checking should only be done after you re done setting up the position, and want to swicth to another mode. This would also prevent problems with temporarily going through illegal in-check positions (e.g. starting to put Kings on e0 and e9 might be refused, while my intention would be to put still many pieces in between.

Note that leaving the final responsibility to check the legality of the position could be left to the engine. Historically, WB always as been able to act as a GUI for variants that it did not really know the rules for, by switching legality-testing off. In that case it just follows the engine in deciding which moves are illegal, and which not. An example I encountered in practice was playing Chess from a starting position where both sides have 8 Pawns in the normal starting position, but white has 7 Knights, and black 3 Queens. Now this is a position that cannot be reached from the orthodox opening position of Chess, because from there the number of Pawns+Knights can never be larger than 10 (and Q+N<=9). But many engines have no difficulty playing it, and I don't want to be forced to play it with legality testing off, as all pieces move as usual, and many things (like checkmate adjudication!) do not work with legality-testing off. It would be very annoying if it was not possible to do these kind of things.
User avatar
H.G.Muller
 
Posts: 3453
Joined: 16 Nov 2005, 12:02
Location: Diemen, NL

How to save setting for Xiangqi board?

Postby Nguyen Pham » 17 Jul 2010, 03:33

I have tried to use Option/Save setting now and/or modify the line /saveSettingsOnExit=false to true in the file xq.init, but all my settings (windows' positions, sizes, on/off panels) will be lost on the next time I run WB.
How can I auto save my settings? Thanks.

PS: Almost all my problems of using WB actually are not really my problems - I can use WB in anyway. However I have reported them here because I have known that normal users are very lazy to report their problems and I hope that WB will be widely used by Asian (usually they are not good at both English and computer) as a standard program for Xiangqi.
Nguyen Pham
 
Posts: 36
Joined: 27 Jun 2010, 08:40

Re: Few small bugs on version 4.4.3

Postby Josh Pettus » 17 Jul 2010, 04:50

Some one correct me if I'm wrong, but I think you can just add to your Winboard Xiangqi shortcut
Code: Select all
Winboard @XQ.ini -saveSettingsFile"XQ.ini" -SettingsFile"XQ.ini"


If that doesn't work, then you add those later two commands to your XQ.ini creating another one upon saving to save all your fluid settings like window locations, which is what I did.
Josh Pettus
 
Posts: 317
Joined: 11 Mar 2009, 01:11

Re: How to save setting for Xiangqi board?

Postby H.G.Muller » 17 Jul 2010, 08:39

Nguyen Pham wrote:I have tried to use Option/Save setting now and/or modify the line /saveSettingsOnExit=false to true in the file xq.init, but all my settings (windows' positions, sizes, on/off panels) will be lost on the next time I run WB.
How can I auto save my settings? Thanks.

PS: Almost all my problems of using WB actually are not really my problems - I can use WB in anyway. However I have reported them here because I have known that normal users are very lazy to report their problems and I hope that WB will be widely used by Asian (usually they are not good at both English and computer) as a standard program for Xiangqi.


Indeed, this is very much appreciated.

The problem is in the method I used to configure WB in this disribution. It uses the xq.ini file as an @xq.ini argument to WinBoard in the menu shortcut. A settingsfile given this way will be read, but not written. It will be read after the default winboard.ini, (like all options on the command line) so it will overrule the saved settings in the winboard.ini, making the saving ineffective for every option that is given there. Basically any option that you specify in such an indirection file (@settings.ini) will be turned into a 'volatile' option with a new default.

In the distributed xq.ini file the window parameters are specified in the xq.ini. The solution to the problem you mention would be to simply delete them from there (/moveHistoryX etc.). Then the values saved in the winboard.ini will be used, and the option will behave like it is 'persistent' again. Disadvantage is that those settings would be shared between different variants.

An alternative would be to use a separate settings file for Xiangqi not as @xq.ini, but as /settingsFile xq.ini. Specified like that, it would also be used for saving. This would keep the settings for Xiangqi complete separate from those of other variants. Disadvantage is that the xq.ini would be completely overwritten on every save, so you would lose all volatile options, including the /variant=xiangqi. So you either would have to specify those explicitly on the command line in the (menu) shortcut, like

winboard /ini=xq.ini /variant=xiangqi

(/ini is short for /settingsFile), or, if there are many volatile options that do not have a suitable default value for XQ, collect them in a second settings file:

winboard /ini=XQ_persistent.ini @XQ_volatile.ini

If neither of these would contain /saveSettingsOnExit=false, this would completely ignore what is in the normal winboard.ini (when you start through this XQ shortcut) and not touch it, but you would still have full persistence between XQ runs. The XQ_volatile.ini can be used to specify volatile options that do not have the desired default value, or to make selected persistant options volatile.

Perhaps in the future we should distribute WinBoard with such a dual settings file for each of the menu items. (I guess some menu items could share the persistence file: shortcuts that start a specific Xiangqi engine could all share the persistence file with the oriental startup dialog. They would just have their own indirection file for the volatile settings (which include the engine specification).

It might even be possible to specify the persistent settings file from the volatile one, by including the /ini=XQ_persistent.ini as first line in the volatile settings files, rather than in the shortcut command lines. (It would have to be the first line, because it will overrule anything specified before it.) I am not sure if this works in WB 4.4.3, though.
User avatar
H.G.Muller
 
Posts: 3453
Joined: 16 Nov 2005, 12:02
Location: Diemen, NL

Re: Few small bugs on version 4.4.3

Postby Nguyen Pham » 17 Jul 2010, 13:20

Thank you all. For me the command line /ini=xq.ini /variant=xiangqi seems work well.

Just a my silly and out of topic question: when I open Properties of the original shortcut "WinBoard XQ Startup (oriental)", I found that the content of Target is only "C:\WinBoard\WinBoard\winboard.exe", without anything to say about Xiangqi variant. How can Winboard know that I want to play Xiangqi game? What did I miss here? Thanks.
Nguyen Pham
 
Posts: 36
Joined: 27 Jun 2010, 08:40

Re: Few small bugs on version 4.4.3

Postby Josh Pettus » 17 Jul 2010, 15:47

The shortcut that came with Winboard 4.4.3 actually had the line
Winboard @XQ.ini
where the XQ.ini had the /variant=xiangqi setting

Thing is windows, for whatever reason, doesn't display the @ symbol in the target box of Shortcuts, so the command disappears. If you edit that line at all, windows will forget that it is suppose to use that command altogether.
Josh Pettus
 
Posts: 317
Joined: 11 Mar 2009, 01:11

PreviousNext

Return to WinBoard development and bugfixing

Who is online

Users browsing this forum: No registered users and 0 guests