Winboard Alien algebraic notation on large boards

[Rein Halbersma]

I am looking for documentation on the conventions that Winboard Alien uses for algebraic notation on large boards. Specifically:

1) where to start numbering rows: 0 or 1? I.e. on 10x10 international draughts, does WB use 0...9 or 1...10 as row numbers? The former has equal width of 1 digit for each row. OTOH, for even larger boards (people play 12x12 draughts as well), this advantage disappears.

2) how to number columns beyond 26 columns: aa, ab,... zz, and then on towards 3 letters? This is a corner case, and there are no official game variants, so this question is for completeness sake.

[hgm]

I think Daniel and I discussed this once, and the conclusion was that it would be best to only use the '0-rank' convention when the number of ranks was exactly 10, but start counting at 1 for >10 ranks. (Because, as you mention, the 1-digit advantage disappears anyway.)

Unfortunately, neither of us actually followed up on this, and the current WinBoard Alien and Nebiyu start rank counting at 0 for all boards deeper than 9.

I am increasingly unhappy with this, especially since I am now implementing games that actually do use >10 ranks. (In particular, Chu Shogi (12x12) will be a supported variant in the XBoard 4.8.0 standard edition). I am not sure how we still could switch back. For boards with 10 ranks starting at 0 is almost mandatory, as it is official Xiangqi standard. So I don't plan to ever change that, which answers your question for international draughts.

I wonder if it is still possible to put the genie back into the bottle, and make starting counting at 1 for >10 ranks the official standard. It would require change of WinBoard (Alien and Standard), Nebiyu, HaChu, perhaps Sjaak. Not sure if it would be possible to do this without breaking backward compatibility. Perhaps I could make WinBoard recognize the few engines that exist now and support variants with more than 10 ranks by their 'myname' feature, and correct all rank numbers when ranks>10 for those only. That would still make it impossible to read games that were saved using the wrong standard. (I can live with that as far as HaChu's games are concerned.)

As for games with more than 26 files, I really had no plans for that yet. The only serious candidate is Taikyoku Shogi (36x36). Notation like aa, ab is not really a possibility, since it would make SAN file disambiguators ambiguous (Rab2 = Ra2-b2 or Rc2-ab2???). In fact 'x' is already interfering with SAN, because it can be confused with the capture symbol. The next-biggest board I am aware of is 25x25 for Tai Shogi, and it would be nice if it could be handled with single-letter ranks. This could be done by skipping the x. For larger boards we could use underscore prefixes (_a following z), but perhaps readibility would be better if we used a'-z' for 26-50 and a"-z" for 51-75. I guess I would prefer the latter, unless a better idea came up. I don't mind if the system would break beyond 75-wide boards; that is purely hypothetical.

[Rein Halbersma]

For boards with 10 ranks starting at 0 is almost mandatory, as it is official Xiangqi standard. So I don't plan to ever change that, which answers your question for international draughts.

In 10x10 international draughts as well as 8x8 US/English checkers, people use a numerical notation with Upper Left Origin coordinates running from 1 through 50 (or 1 through 32), rather than the Lower Left Origin chess algebraic coordinates (in 8x8 Russian draughts they do use algebraic notation however). My program can display both numeric and algebraic notation, but I assume that Winboard only accepts algebraic commands from the engine? As long as I can still display numeric moves in the PV window.

I thought that the official Go notation was [a-t] with excluded, and rows numbered 1-19. Does WB Alien also use that?

As for games with more than 26 files, I really had no plans for that yet. The only serious candidate is Taikyoku Shogi (36x36). Notation like aa, ab is not really a possibility, since it would make SAN file disambiguators ambiguous (Rab2 = Ra2-b2 or Rc2-ab2???). In fact 'x' is already interfering with SAN, because it can be confused with the capture symbol. The next-biggest board I am aware of is 25x25 for Tai Shogi, and it would be nice if it could be handled with single-letter ranks. This could be done by skipping the x. For larger boards we could use underscore prefixes (_a following z), but perhaps readibility would be better if we used a'-z' for 26-50 and a"-z" for 51-75. I guess I would prefer the latter, unless a better idea came up. I don't mind if the system would break beyond 75-wide boards; that is purely hypothetical.

My template library nominally supports unlimited board size, although any draughts game beyond 12x12 is essentially unplayable (too long). I can limit support to dimensions equal to at most ~20 (there is an interesting 10x19 board with peculiar endgame properties).

[hgm]

WinBoard currently has no provisions for game formats other than PGN. It would be difficult to support thuse without enormously bloating the code, as there exist many games, each having their own game-specific notation formats. I thought about allowing 'plugins' for conversion between the internally used coordinate notation and a game-specific 'formal' format, but I am not sure how this could be implemented. A quite large bandwidth is required here, when an engine spits out 20 PVs in the first 0.1 sec, and letting a 'referee engine' connected through pipes handle this would probably too slow. DLLs could be a solution, but are a 'high-threshold' solution for someone that wants to use WinBoard for a novel game. While the whole idea of the Alien Edition is that it should be trivial to use for any game.

Ideal would be if there was some way to describe a move format in text form, and WinBoard would sort of compile that itself to an internal code that could be efficianly interpreted to do the conversions.

WinBoard doesn't exclude the i, like Go notation does. In Capablanca Chess the extra files are commonly called i-file and j-file.

The Engine Output is normally displayed literally as the engine sends it. If it is in a format that WinBoard's parser doen't understand, some functions (such as variation board for walking the PV) would not work, however.

[Evert]

I am increasingly unhappy with this, especially since I am now implementing games that actually do use >10 ranks. (In particular, Chu Shogi (12x12) will be a supported variant in the XBoard 4.8.0 standard edition). I am not sure how we still could switch back. For boards with 10 ranks starting at 0 is almost mandatory, as it is official Xiangqi standard. So I don't plan to ever change that, which answers your question for international draughts.

I wonder if it is still possible to put the genie back into the bottle, and make starting counting at 1 for >10 ranks the official standard. It would require change of WinBoard (Alien and Standard), Nebiyu, HaChu, perhaps Sjaak. Not sure if it would be possible to do this without breaking backward compatibility. Perhaps I could make WinBoard recognize the few engines that exist now and support variants with more than 10 ranks by their 'myname' feature, and correct all rank numbers when ranks>10 for those only. That would still make it impossible to read games that were saved using the wrong standard. (I can live with that as far as HaChu's games are concerned.)

I think whether the run is 0-9 or 1-10 should depend on the variant rather than the board size. As you say, 0-9 makes sense for Xiangqi (although I guess standard notation for Xiangqi is descriptive rather than algebraic), but 1-10 makes more sense for grand chess.

Would it be possible to somehow use the XBoard "feature" command in reverse to switch engine options on/off? Say the GUI sends something like "feature start_rank_at_0", or even "feature first_rank = integer" and the engine can accept it (it relabels the ranks) or reject it (in which case we need a sensible default, probably to start at 0, and the GUI deals with the issues).

Alternatively, just make the change now and make the few engines that it affects (which are all maintained, as far as I know) deal with it. Better to suffer the pain once and fix it rather than having to live with the issue for ever.

As for Sjaak, when it runs as a console chess program, it actually starts at rank 1 for large boards (which, come to think of it, probably means that it gets Xiangqi wrong) and when it is switched to XBoard mode it relabels all squares on the board. So it wouldn't be hard to fix. Having said that, I don't think it's pre-configured for any games with more than 10 ranks (and I'm not sure I ever tested whether it works correctly, but I see no reason it shouldn't as long as the total size of the board is not too large).

I have a testing/development version that can use boards of (almost) arbitrary size, so it'd be more relevant for that when I get back to it (I will at some point).

[hgm]

Indeed, solving this with a feature could be a solution. I don't in general like it to have features merely to choose between different standards, though. For backward compatibility you would still have to make the standard you want to abandon the default, forcing every newer engine to use the feature. (Compare setboard.) To allow the old standard by a feature would solve nothing, as old engines would still have to be changed to emit the feature, so they could as well be changed to use the new counting. This is why I would prefer to (ab)use the myname feature for implying rankstart=0 on engines from before the standard change (since there only are so few, to date).

Making things depend on the variant is in general a very bad idea. I have had this discussion in the context of Shogi, where people were pushing to use alpharank notation when communicating with Shogi engines. It would break multi-variant engines like Nebiyu, which are not specifically designed for Shogi, but can be configured to play it. The same applies to rank counting. You don't want one 10-rank game using another standard as other 10-rank games. Especially when they are engine-defined variants, for which no central standard can be announced. Note that in XBoard protocol the variants are chosen independntly on every game, while the features are only emitted at startup of the engine, before it knows what variant it will be asked to play. So a feature could never be used to change the standard on a variant-by variant basis. Only a setup command would be able to do that.

Perhaps backward compatibility should be weekened by providing a non-default option for it. Then people could still use old engines in the new GUI. A practical problem (which really pollutes this discussion) is that WinBoard is designed in such a way that the move parser has no idea at all whether it is working on data supplied by an engine (and if so, which one), or from a PGN file. That makes it very hard to allow one engine to count ranks differently from another.

I don't agree that starting at 1 would be better for Grand Chess, btw. That game adds one rank behind the normal setup, so calling it rank 0 is very natural. Then e2e4 would remain a normal opening move. Much more awful is the problem of Omega Chess. Due to the wizard squares the board is really 12x12. If the lower-left wizard square is a1, the board will start at b2, which looks very weird. But starting ranks at 0 still would not solve the problem for the files. To have the board start at a1, you would need something like _0 for the wizard square, where _ would be the 'letter' preceding a.

[Rein Halbersma]

Perhaps it's feasible to put a square mappings array into the .ini file of an engine that give the square labels for a0...j0, a1..j1, ... a9,...j9. E.g. for international draughts one could imagine to have

Code: Select all

square_labels = [46,_,47_,48_,49_,50,_, _,41,_,42,_,43,_,44,_,45, ... ,_,1,_,2,_,3,_4,_,5]

For 19x19 Go, one could have (... means omitted here for brevity, they should be present in the real .ini file)

Code: Select all

column_labels = [a,...,h,j,...,t]
row_labels = [1,...,19] 

Engines that do not have such lines in their .ini, simply conform to the current convention, so there should be no backward compatibility issue.

Parsing a displayed PV is then also feasible: if e.g. an international draughts engine uses a square mapping in the .ini, then the PV parsing translates the squares to conventional internal algebraic coordinates before playing the move.

Another issue is that Russian draughts uses ":" as the capture separator, and it would be nice if that could be configured through the .ini file as well. (Thai draughts uses "-" for moves and captures).

[Evert]

Indeed, solving this with a feature could be a solution. I don't in general like it to have features merely to choose between different standards, though. For backward compatibility you would still have to make the standard you want to abandon the default, forcing every newer engine to use the feature. (Compare setboard.) To allow the old standard by a feature would solve nothing, as old engines would still have to be changed to emit the feature, so they could as well be changed to use the new counting. This is why I would prefer to (ab)use the myname feature for implying rankstart=0 on engines from before the standard change (since there only are so few, to date).

Fair enough.

Making things depend on the variant is in general a very bad idea. I have had this discussion in the context of Shogi, where people were pushing to use alpharank notation when communicating with Shogi engines. It would break multi-variant engines like Nebiyu, which are not specifically designed for Shogi, but can be configured to play it. The same applies to rank counting. You don't want one 10-rank game using another standard as other 10-rank games.

I would argue that it depends on the game. Afterall, the setup and details of the rules already depend on the game that is played and one could argue that the notation is a part of the game description. Especially for established games with an established notation, like Shogi and Xiangqi.

For me it would be very easy to configure Sjaak to any arbitrary notation standard, because the names of the squares are stored in an array, and mapping of square names to numbers is done using the same array. It doesn't matter if squares are called "a1", "b1", "c3" or "aap", "noot", "mies".

Having said all that, I have very little desire to ever use anything other than chess-like algebraic notation.

Especially when they are engine-defined variants, for which no central standard can be announced.

Yes, that is an issue.

Note that in XBoard protocol the variants are chosen independntly on every game, while the features are only emitted at startup of the engine, before it knows what variant it will be asked to play. So a feature could never be used to change the standard on a variant-by variant basis. Only a setup command would be able to do that.

Well, it would be an extension/change to how the feature command works.

A practical problem (which really pollutes this discussion) is that WinBoard is designed in such a way that the move parser has no idea at all whether it is working on data supplied by an engine (and if so, which one), or from a PGN file. That makes it very hard to allow one engine to count ranks differently from another.

Ok, fair enough.
It may not really be worth it anyway.

I don't agree that starting at 1 would be better for Grand Chess, btw. That game adds one rank behind the normal setup, so calling it rank 0 is very natural. Then e2e4 would remain a normal opening move.

I actually don't have much of a preference. The reason Sjaak starts counting at 1 if used on its own is because of a feature request from a user (who was running it as a console program, obviously).

Much more awful is the problem of Omega Chess. Due to the wizard squares the board is really 12x12. If the lower-left wizard square is a1, the board will start at b2, which looks very weird. But starting ranks at 0 still would not solve the problem for the files. To have the board start at a1, you would need something like _0 for the wizard square, where _ would be the 'letter' preceding a.

Omega is pretty awful in that sense. I had an experimental version of Sjaak that sortof supported it (never worked properly though), and I used the "official" names for the extra squares (which are w1-w4, if I recall correctly) even though they were really a10-d10 in terms of square numbering.

[hgm]

I would argue that it depends on the game. Afterall, the setup and details of the rules already depend on the game that is played and one could argue that the notation is a part of the game description. Especially for established games with an established notation, like Shogi and Xiangqi.

But the idea of the Alien Edition is that the GUI would not even have to be aware of these other rule details too. The engine would do the legality checking and move highlighting, specify the initial position, etc. I am even thinking of adding protocol commands that would allow the engine to specify piece types, so that the GUI can again recognize checkmates, make a decent promotion popup, do accurate SAN parsing and generation, etc. Like

piece A Archbishop BN

where the BN is the Betza notation of the piece move. The engine would just have to send them after the setup command for all unorthodox pieces.

But it is very hard to make a formal definition of move-notation systems, which the engine could send to the GUI in a similar way.