Shogi engine invalid moves (Dan and HGM)

[hgm]

No, this is correct. The 22 WinBoard piece types come in two series of 11, the basic series and the promoted series. So each basic piece has a unique promoted form, 11 places further in the table. If the pieceToCharTable defines a + for a piece, it means the piece does participate, but only as the unique promoted form of the corresponding basic piece. Meaning it doesn't have an ID letter of its own, but shoud be notated with a + prefix to the basic piece, and that the basic piece can promote to it on entering the promotion zone, and that is should be demoted to the basic piece on capture.

If you would define a letter for a piece in the promoted series, WinBoard would consider it just another piece, with no relation to the corresponding basic piece. Thus the corresponding basic piece would not be considered promotable, and the piece would remain itself on capture (provided there is space for it in the holdings).

When played as variant alien nothing of that matters, as the engine sends board updates anyway, and thus decides how things promote and how things would go into the holdings. The only thing is that you would get nonstandard SAN and FEN. But the letter form would not have worked at all in the standard edition, when played as variant shogi. Fortunately upto 4.7.2 all standard editions ignored the setup command.

With

Code: Select all

#PNBRQFEACWMOHIJGDVLSUKpnbrqfeacwmohijgdvlsuk
 P.BR.S...G++..++..L..Kp.br.s...g++..++..l..k

there would be a + defined for M, which is meaningless, as it is a base type, and demoting it in an attempt to find its base type would bring you outside the table. B would not be able to promote, as its promoted partner, I (the flattened mitre) would be defined as . in stead of +. Similar with S. OTOH, a + is defined for G (the 'Narrow Queen', used for Grasshopper in variant fairy), while the demoted version (the ordinary Queen) does not participate. This is also meaningless, and would lead to +. being used for that piece if SAN and FEN (which makes it impossible to read those back).

One thing that further complicates matters is that in Shogi the Queen is displayed as Lance symbol, so what looks like a Lance is internally really a Queen. This is a legacy from before the invention of the pieceToCharTable and flexible mapping into the holdings (compacting out all the unused pieces), when it was mandatory that the pieces participating in Shogi were consecutive encodings. That there also is a Lance in the promoted series was to be able to use that pictogram also in non-Shogi variants (e.g. for the Spartan Hoplit Pawn). Shogi had to mess with the way pieces are displayed anyway, as I want the promoted partners of P, N, S and Q (=L) to all look like the Wazir W used to represent Gold, as these all move as Gold.

[Daniel Shawul]

I understand what you are saying but Nebiyu's set_board() uses the PieceToChar tables to construct a FEN and send to Winboard. My understanding was that I can use any letter internally as long as , i specify how they are interpreted with the setup command. So I use the piece_char[]

.*PpKkGgSsRrBbUuOoHhIi

So I have to map U,O,H and I to a '+' so that when the FEN contains them they will automatically be replaced by a '+'. That is how I understood it. I can do it your way but piece_char[] should have O,I,J,D instead of the U,O,H,I that I am currently using. So something like

.*PpKkGgSsRrBbDdOoIiJj
D 600 wgoldgeneral
d 600 bgoldgeneral
O 900 dragon
o 900 dragon
I 900 dragonhorse
i 900 dragonhorse
J 600 wgoldgeneral
j 600 bgoldgeneral

I am not sure of the proper order but all mapped letters should be defined. The FEN Nebiyu receives from Winboard do not have these letters but a '+' which I interpret correctly, but Nebiyu sends a FEN constructed from the internal letters it uses. So either I have to change that in code (like I did manually for promotion moves by attaching a + instead of internal letters) or Winboard has to reinterpret the promotion letters on Nebiyu's behalf according to the mapping it provided at start up. There seems to be a lack of consistency here because because Nebiyu doesn't know about piece chars such as 'D' which you mapped along with O,I,J

Code: Select all

#PNBRQFEACWMOHIJGDVLSUKpnbrqfeacwmohijgdvlsuk 
 P.BR.S...G.+.++.+....Kp.br.s...g.+.++.+....k 

[Daniel Shawul]

Afterall it seems that the automatic setup of FEN is not necessary since shogi is standard in Winboard and doesn't need setup. For that to work properly, I will have to explicitly replace internal piece chars with their unpromoted piece letter plus '+' before sending FENs to winboard, just like I replaced them in the promotion moves I send to winboard. If winboard could interpreted internal characters both in FENs and MOVEs it would help the programmer.

The way it is right now with all the '+' looks to be working, because standard shogi doesn't need it, so anything goes. Nebiyu plays the same which ever pieces I mark as '+' but for the alien edition there should be a one to one mapping.

[hgm]

So I have to map U,O,H and I to a '+' so that when the FEN contains them they will automatically be replaced by a '+'.

No, Shogi FENs (and Crazyhouse/Bughouse FENs) are different: the promoted pieces are represented there by a PAIR of characters, the letter for the demoted piece, prefixed by a + sign. Similarly, a piece that is a promoted Pawn in Crazyhouse will be represented in FEN by a pair of characters: that for the piece it is now, suffixed by a tilde ~. In WinBoard's pieceToCharTable this is implemented by defining a piece from the promoted series as ~. WinBoard will then use the letter of its demoted (i.e. 11 places earlier) version in SAN, a tilde suffix in FEN, and will demote it to Pawn on capture. (Unlike pieces defined as +, which will be demoted to their fixed partner in the unpromoted series.)

That is how I understood it. I can do it your way but piece_char[] should have O,I,J,D instead of the U,O,H,I that I am currently using. So something like

.*PpKkGgSsRrBbDdOoIiJj
D 600 wgoldgeneral
d 600 bgoldgeneral
O 900 dragon
o 900 dragon
I 900 dragonhorse
i 900 dragonhorse
J 600 wgoldgeneral
j 600 bgoldgeneral

I am not sure of the proper order but all mapped letters should be defined. The FEN Nebiyu receives from Winboard do not have these letters but a '+' which I interpret correctly,

It has a + and a letter. To interpret it you should look up the piece of the letter, and then look to which letter it promotes in the piece definitions, because +X in the FEN means the promoted form of piece X.

but Nebiyu sends a FEN constructed from the internal letters it uses. So either I have to change that in code (like I did manually for promotion moves by attaching a + instead of internal letters) or Winboard has to reinterpret the promotion letters on Nebiyu's behalf according to the mapping it provided at start up. There seems to be a lack of consistency here because because Nebiyu doesn't know about piece chars such as 'D' which you mapped along with O,I,J

Indeed, it should have code to interpret the letter combination +X and X~ in input FEN. For +X it should have all the information needed to do that, because in the piece definitions you give letters for the piece types, and for each type also the letters to which they promote. If X promotes to Y (and only to Y; this whole mechanism can only be used on unique promotions), then the FEN parser should interpret +X as Y. And the FEN creator should expand Y to +X if it finds a + in the pieceToChar table for the promoted form of the piece that promotest to Y.

[Daniel Shawul]

HG, we are mis-communicating. I know it is a PAIR but for the PieceToChar table our assumption was that winboard will interpret it correctly to the appropriate promoted piece. This can not work because conversion is from single char to double char, and was completely unnecessary to change alien.ini by replacing internal piece char with '+'s. It serves no purpose when standard winboard edition is used. The proof is that I have been using the original alien.ine without any pluses which worked without problems. So that is that.

Now for the alien edition, we thought putting the '+' would help to map (identify) the promoted piece chars that I use internally to a '+', which winboard will then interpret correctly but this does not work. Again because the engine has to do the work of appending the unpromoted char with a '+', which I do not do right now. Without using '+'s it works for the most part even in alien edition, except that Winboard does not display the correct list of promotion letters as it would consider all pieces unpromoted. For that you wanted to replace the promoted pieces with a '+' but then the mapping is broken because now I have internal chars that are un-mapped. To avoid that, again the engine has to do conversion of internal chars by itself before sending to winboard. This is not flexible at all and, is also a hack that assumes one promotion piece. The alien setup I have allows for promoting to a list of chars.

So in both cases, standard and alien, chaning to '+'s does not serve any purpose right now.

[hgm]

It serves no purpose when standard winboard edition is used. The proof is that I have been using the original alien.ine without any pluses which worked without problems. So that is that.

Not really, because this situation will not last. I am converging the standard edition to the alian edition, and I think the current development version of the standard edition (4.8.pre0, as it were), the one that supports the engine-defined variant names, would already break on it. Because it will pay attention to received setup commands in more cases than 4.7.2, which only did it when legality testing was off. But the new one also accepts it at game start whenever the board width is non-standard, even with legality testing on. (As the alternative used in 4.7.2, to start with an empty board in those case, would certainly not be what you want.) And mini-Shogi does have non-standard board width. And of course it is always necessary to accept the setup on an engine-defined variant name. So mini-Shogi will not work on the latest WinBoard standard edition. Which is exactly the reason why I changed the pieceToChar table, I remember now.

Now for the alien edition, we thought putting the '+' would help to map (identify) the promoted piece chars that I use internally to a '+', which winboard will then interpret correctly but this does not work. Again because the engine has to do the work of appending the unpromoted char with a '+', which I do not do right now. Without using '+'s it works for the most part even in alien edition, except that Winboard does not display the correct list of promotion letters as it would consider all pieces unpromoted. For that you wanted to replace the promoted pieces with a '+' but then the mapping is broken because now I have internal chars that are un-mapped. To avoid that, again the engine has to do conversion of internal chars by itself before sending to winboard. This is not flexible at all and, is also a hack that assumes one promotion piece.

Well, with the old pieceToChar it might have worked in the Alien Edition in Human-Engine games, but you would most certainly not have been able to play against other mini-Shogi engines. For one, the setup command would always be ignored if it comes from the second engine.

Only a single promotion piece is an intrinsic (I would almost say, defining) property of all Shogi variants. (It cannot be otherwise, as the promote pieces by flipping them.) This whole business with the + is only intended for Shogi. I agree that it is a pain. OTOH, it saves letters, such that I don't have a problem yet in Chu Shogi (which has 21 unpromoted and 18 promoted piece types, far exceeding the alphabet. Even by using +X for the promoted types there were barely enough letters).

The alien setup I have allows for promoting to a list of chars.

So in both cases, standard and alien, chaning to '+'s does not serve any purpose right now.

Indeed. I did it purely for the version that supported the engine-defined variant names. But remember that the alien.ini file that originally came with 1.45 did use such names, minishogi in stead of 5x5+5_shogi. With user-defined variant names WinBoard has to obey the setup command, or it would not know what to do at all.