move generation rank start

[gaintpd]

Hello ianfab, there is an issue that result from the disconsistent of rank start in different variant.

the rank of the move generation is starting from 1 in the supported variant grand chess in fairy-stockfish, while in Musketeer-stockfish the rank is starting from 0. This disconsistent behavior is a trouble for the implementation in the GUI to support both of the two variants mentioned at the same time.

[ianfab]

Hi. Musketeer chess is played on an 8x8 board, while grand is played on a 10x10 board, so I guess you are referring to the virtual 8x10 board representation that is used for Musketeer chess to describe the setup of gating pieces. Can you please explain in more detail what would need to change to ease the GUI implementation? Please also note that there is not really any standard yet how to describe the setup phase in the UCI protocol, so the representation like A@a0 is a more or less arbitrary choice as the setup phase is anyway not supported by any GUI yet, so it just needed to be self-consistent in Musketeer-Stockfish.

[gaintpd]

Hello ianfab. I think the problem has been understood by you. The trouble is that in the grand variant. the board is 10X10, i.e. the total number of the ranks is 10, the start rank is 1. In musketeer variant, though it is played on an 8X8 board, there still exist two additional Gating ranks, the one is on the bottom, the other one is on the top, there are still two pieces distributed in each of the two ranks at the beginning of the game. if the bottom rank is 0. The engine protocol for both grand and musketeer is UCI. At this time. for the GUI programmer, the tricky problems arises, the UCI implementation should be variant aware to handle this situation. if the bottom rank can be started from 1, the UCI implementation in cutechess is not needed to be variant aware. in fact, if we treat the height of the board in the same way as the XBoard Protocol in cutechess, the start rank is 0 for all the variants that the height is 10(this is a feature that was borrowed by UCCI and UCI-Cyclone for xiangqi variant, which I have implemented in cutechess, though not pushed to the official repo yet) which can void this problems too. As a GUI programmer what I need, in fact is the consistence across the variants.

[alwey]

I think it was a bad idea in CECP to shift ranks in case the board height equals 10. This does not work for 11 or 9 ranks. In cutechess tthere is a hook for CECP to shift up by one to decode and the shift down by one to encode. In UCI the problem does not occur.

[ianfab]

I agree, but gaintpd is mostly referring to the problem that even in the UCI protocol this fork counts ranks from 0 to 9 (actually it counts from 1 to 8, ranks 0 and 9 do not exist internally and are only used as labels during the setup phase). However, since this variant is actually played on an 8x8 board and only artificially represented as 8x10 (mainly in CECP), it would be rather awkward to shift the ranks just because of that, e.g., the first move could be e3e5 instead of e2e4. However, since there currently is no GUI that supports UCI Musketeer chess engines, I am open to doing changes for the UCI protocol for this fork if it simplifies GUI development.

[alwey]

Thank you for the clarification. If the two ranks are not used for moves then indeed there should be no problem and I guess the suggested transformation would be favourable.

[ianfab]

By the suggested transformation, do you mean the shift of the ranks, to count the regular ranks from 2-9?

[alwey]

I think counting ranks from 1 to 8 for the actual board and 0 to 9 for all of the board is favourable.

[alwey]

The notation should be e2e4 The engine interface should not be burdened. The UI has to adapt and find ways to show the board.

[ianfab]

Ok, thanks, I agree, although as mentioned changing it would not be that much of a burden as there anyway is no standard yet (for UCI. For CECP there kind of is now). Maybe you two can then sync on how it could be done in cutechess, but for now I assume that I do not need to change anything on the engine protocol level.

[alwey]

I think so. The GUI guys will have to do their work and the engine guys will have to deal with other concerns.

[alwey]

@ianfab: I was pondering ... what does the CECP interface transmit for the e-line opening move by pawn (in the Musketeer variant)?

Reason for my question: The relative use of coordinates between the protocols must be consistent, i.e. the moves must have the same meaning, be the same moves but with different notations. And if 10 ranks are used in CECP then it must be "CECP-quirk" (shift by 1 rank) consistent. And as @gaintpd said, the use in different variants should also be consitent.

[ianfab]

The notation currently is identical for UCI and CECP, and in CECP it is described as a 8x10 variant. Since counting from 1 to 8 on 8x8 and counting from 0 to 9 on 8x10 is the same, it is not entirely clear which convention is used, but I assume in Winboard/XBoard it is the latter, especially since the FEN also represents an 8x10 board.

The current conventions for UCI used in this fork are documented in https://github.com/ianfab/Musketeer-Stockfish/wiki/Interface. The conventions for CECP can only be put together from http://www.talkchess.com/forum3/viewtopic.php?f=7&t=72572, I think it is not clearly documented anywhere.

[alwey]

@ianfab Thank you. Reading the specs ...

[gaintpd]

I think it was a bad idea in CECP to shift ranks in case the board height equals 10. This does not work for 11 or 9 ranks. In cutechess tthere is a hook for CECP to shift up by one to decode and the shift down by one to encode. In UCI the problem does not occur.

@alwey I can not agree with you. As I have added UCCI and UCI-cyclone protocol support for cutechess, both of the two above protocols are used by xiangqi variant, and the xiangqi variant is played on the 9x10 board, i.e. the height of xiangqi board is 10, I think I can share my viewpoints with you. As we all know that if we notate the ranks of xiangqi board, we can do this from 1 to 10, we can also do this from 0 to 9. If we examine the difference of the two methods, we can find the last rank notation for the first method is 10, which has 2 digits, others has 1 digit, all the notation for the second method is only 1 digit. The difference between the two method may be very small, but this is not the case for both the engine programmer and the GUI programmer, which the second method can ease the programming life for xiangqi engine and xiangqi GUI programmer greatly, both of them are only needed to handle strings whose length is 4. And besides the benefit of reduced complexity, the most important aspect is the reduced amount of data transmittion between the GUI and engine, this method can also improve the play strength at a very very cheap price.

If you can realise the wisdom behind the shift of the ranks in case of the board height equals 10, I think that you may change your mind.

Besides xiangqi, the Korean chess janggi, if you have some knowledge of the janggi game notation, you will find that the korean people notate the rank 10 as 0, whose purpose is also to reduce the two digits ranks notation to one digit, and let the rank notation get a unified and simple processing method.

As to the case of 9 and 11, the first case is not needed as all the ranks notation is only one digit. the second case is that there are two ranks needed to be notated by two digits, the shift ranks fails to work.

[ianfab]

I think there is no doubt that using 0-9 (or 1-0) instead of 1-10 in internal representations and in specialized protocols (e.g., Janggi notation, UCCI protocol) can make sense, but for a general protocol like CECP handling variants of any board size it is a bad idea to introduce unnecessary special cases. But either way, that is nothing we can change anymore, so we should stick to the topic that we can still decide here.

[gaintpd]

I think that in cutechess, it is also feasible to take the musketeer as an 8x10 variant as the way in XBoard(GUI). If you agree with this way to treat the musketeer variant, the only problem left is that it is unclear to decide which convention to take. In my personal opinion, do not let the musketeer be different with other supported variants in Fairy-Stockfish whose height equals 10, such as xiangqi, janggi, and grand variant.

As far as now, I have created a new protocol that based on the UCI-cyclone, and name it as UMI(Universal Musketeer Interface) to let it work with the current musketeer-stockfish, and It has worked in the expected way to facilitate me to implement the musketeer variant in cutechess.

So this is not a problem of doability and undoability, this is a problem of a cooperation to find a best solution to add musketeer support to cutechess, the uci-based GUI.

[gaintpd]

I think there is no doubt that using 0-9 (or 1-0) instead of 1-10 in internal representations and in specialized protocols (e.g., Janggi notation, UCCI protocol) can make sense, but for a general protocol like CECP handling variants of any board size it is a bad idea to introduce unnecessary special cases. But either way, that is nothing we can change anymore, so we should stick to the topic that we can still decide here.

As far as now based on my own knowledge, I think the method that CECP(Xboard) adopt is a compromise to the purpose to broaden the XBoard(GUI) users' options to the UCCI engines via the UCI to CECP(Xboard) adapter. As there is no UCI-based xiangqi GUI in western world only exist the CECP(Xboard)-based GUI.

[alwey]

OK I am just considering the implications of the FEN and move notation in UCI .

@gaintpd : Just do not break the UCI and CECP interfaces for the grand variant and do not break other large board variants.

Grand Chess works great in cutechess as is. Fairy-Stockfish is one of the newest engines to support this variant. The use of the UCI protocol has been established before by other engines.

[alwey]

Output in PGN is a topic, too. PGN import as well.

[alwey]

If I started a MusketeerBoard today I would chose a 8x8 representation with reserves and a level 2 reserve.

[gaintpd]

OK I am just considering the implications of the FEN and move notation in UCI .

@gaintpd : Just do not break the UCI and CECP interfaces for the grand variant and do not break other large board variants.

Grand Chess works great in cutechess as is. Fairy-Stockfish is one of the newest engine to support this variant. The use of the UCI protocol has been established before by otherl engines.

I can't agree more, I do not want to break the UCI and XBoard interfaces for grand variant, this is the reason I file this issue to discuss this

[raphaeleliekakou]

Hello friends I will ask Zied to check your discussion here because it is of great importance.

Raphael

Le 14 juil. 2020 à 17:14, gaintpd notifications@github.com a écrit :

 I think that in cutechess, it is also feasible to take the musketeer as an 8x10 variant as the way in XBoard(GUI). If you agree with this way to treat the musketeer variant, the only problem left is that it is unclear to decide which convention to take. In my personal opinion, do not let the musketeer be different with other supported variants in Fairy-Stockfish whose height equals 10, such as xiangqi, janggi, and grand variant.

As far as now, I have created a new protocol that based on the UCI-cyclone, and name it as UMI(Universal Musketeer Interface) to let it work with the current musketeer-stockfish, and It has worked in the expected way to facilitate me to implement the musketeer variant in cutechess.

So this is not a problem of doability and undoability, this is a problem of a cooperation to find a best solution to add musketeer support to cutechess, the uci-based GUI.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[musketeerchess]

Hi friends, I think Musketeer Chess should remain as an 8x8 Board even if during the Gating Selection Phase there is need to chose a placement for the additional pieces on "virtual squares" outside the 8x8 board where these pieces are "waiting" to enter the Gate (the Square that will be left free when a piece from the first or last rank moves for the first time).

Once this particular phase is finished, the board is a classic chess board.