FEEN?

[Gerd Isenberg]

Cyril Wack has proposed the so called "Forsyth-Edwards Expanded Notation" for cross-board and cross-style computer chess applications, that is for Shogi, Western, Xiangqi and for more than two dimensions, e.g. 3D chess. So far there are no programs or protocols supporting it.

https://en.wikipedia.org/wiki/FEEN
https://chessprogramming.wikispaces.com ... d+Notation

After asking him in cpw, Cyril mentioned neither Steven Edwards nor HGM were involved in FEEN. Any opinions appreciated, e.g. objections about the name FEEN rather than CWEN.

Gerd

[hgm]

I can confirm that I was not involved. After glancing to the proposal, my first impression is that it is rather absurd. I am not sure what problem the inventor is trying to solve with this.

Especially putting a 'style' prefix on every piece name seems a very counter-productive way of doing things. In a FEEN for Chess all pieces would need a w: or W: prefix to indicate the following piece ID refers to orthodox Chess ('western style'). As one almost never deals with games that mix pieces of different games (and if they do, usually have many original new piece types which would not exist in any style), this seems extremely wasteful. If some clarification would be needed as to what the letters in a FEN-like notation mean, it would be much better to express that in a single prefix to the entire FEN, naming the variant. Like xiangqi: or xq:.

In WinBoard I use ordinary FEN syntax, extended with a field for pieces in hand for all variants, and it suits me well. The only problem occurs in games with more than 26 piece types (of which the large Shogi variants are the only examples I am aware of). This seems to be a real problem, in the sense that going to two-letter piece ID would force you to introduce a separator character (like a comma) to preserve readability, which largely destroys the compactness that made FEN such an attractive representation.

I have not addressed this problem yet in WinBoard; I am now inclined to solve it in GUI-engine communication by reviving the old-fashioned edit command of WB protocol, which did not use FEN, but simply sends <pieceID><squareCoords> on separate lines, where I then would allow multi-byte <pieceID>. That leaves the problem of how to export positions from the GUI (with commands like Save Position, Load Position), though.

[sje]

I can confirm that I was not involved. After glancing to the proposal, my first impression is that it is rather absurd. I am not sure what problem the inventor is trying to solve with this.

Especially putting a 'style' prefix on every piece name seems a very counter-productive way of doing things. In a FEEN for Chess all pieces would need a w: or W: prefix to indicate the following piece ID refers to orthodox Chess ('western style'). As one almost never deals with games that mix pieces of different games (and if they do, usually have many original new piece types which would not exist in any style), this seems extremely wasteful. If some clarification would be needed as to what the letters in a FEN-like notation mean, it would be much better to express that in a single prefix to the entire FEN, naming the variant. Like xiangqi: or xq:.

In WinBoard I use ordinary FEN syntax, extended with a field for pieces in hand for all variants, and it suits me well. The only problem occurs in games with more than 26 piece types (of which the large Shogi variants are the only examples I am aware of). This seems to be a real problem, in the sense that going to two-letter piece ID would force you to introduce a separator character (like a comma) to preserve readability, which largely destroys the compactness that made FEN such an attractive representation.

My comments are much the same.

I discussed some of this in a recent post about taikyoku shogi and how the one-line, cut+paste, human-tractable traits of FEN were just not possible with the Latin glyph set. Also, games with a dominant Asian tradition should be using Asian language glyphs. For many years the Sons of Asia have learned and used a non-native character set; shouldn't the Sons of Europe now act reciprocally?

[sje]

QR Coding

See: http://en.wikipedia.org/wiki/QR_code

Also, Open Bar Codes: http://code.google.com/p/zxing/

[sje]

As a commercial laxative

See: http://web.pdx.edu/~sujata/FruitEzeWeb/ ... _mint.html

[hgm]

Also, games with a dominant Asian tradition should be using Asian language glyphs. For many years the Sons of Asia have learned and used a non-native character set; shouldn't the Sons of Europe now act reciprocally?

Using kanji glyphs (encoded in UTF-8, say) for representing board positions of the large Shogi variants is in itself a good idea, which would immediately enjoy wide support from people currently playing these games. There is one real problem, though: unlike latin characters, kanji don't come in an upper-case and lower-case variety that could be used to distinguish the sides. A popular format for Shogi diagrams is simply bare kanji written in a table representing the board:



in this case the sides are distinguished by writing thekanji for one of the players upside down, which is a very natural representation for Shogi players, because in over-the-board play the orientation of the pieces similarly decides which side they are on. But unfortunately, there are no UTF-8 encodings for upside-down kanji...

Also, in games like Tai Shogi (25x25) it is not really possible to make unique single-kanji names for all the pieces with kanji that occur in their multi-kanji name. This because the same kanji occur in the names of many pieces. E.g. there are Gold, Silver, Copper, Left, Right and Great Generals, but also a Great, White and Drunk Elephant and a Great Dragon, a Flying Dragon and a Blue Dragon, a Dragon Horse and a Dragon King, a Honorable and a White Horse, a Left, Right and Flying Chariot, a Chariot Soldier, a Vertical and a Side Soldier, Vertical and Side Movers, etc., all with 2-kanji names. So although there are enough kanji in the Chinese/Japanese alphabet, there would not be an obvious mapping of single kanji to pieces.

Another problem is that even though such a representation would be applauded by (the quite small number of) existing players of these variants, it would be a great obstacle to a wider popularity.

[hgm]

Note that WinBoard uses an extension of the FEN standard which I call U-FEN, which is loosely inspired by the bFEN standard for Bughouse and the SFEN defined by Tord for Shogi. The U-FEN standard is an 'asymmetric' standard, which puts tighter requirements on writing a position than on reading one. (Based on the philosophy "write according to the standard, but understand as much as possible on reading".)

The extensions I use are:

In between the board position there can be an extra field to indicate the pieces in hand. These should be written in square brackets, and separated from the board position by a space. Multiple pieces of the same type should be written by writing their ID letter multiple times. If both hands are empty the field should not be written. When reading, you should also understand an extra board rank as pieces in hand (like in bFEN). [-] or [] should be understood as empty hands. Thus is not only used in drop games, but also in games where you can promote only to pieces that were previously captured (which you then hold in the hand).

Pieces in the FEN for a drop game can be suffixed with a tilde ~, meaning that they really are promoted Pawns, which will revert to Pawn when transferred to the hand on capture.

Similarly, pieces prefixed with a plus sign + are the promoted version of the mentioned piece, and will revert to the latter when transferred to the hand on capture.

The e.p. field must contain the full previous move in long algebraic notation rather than just the to-square, in games where the latter does not in general uniquely identify the e.p. capture that is possible (such as in Berolina Chess, where Pawns move diagonal and capture straight ahead).

The castling field is generalized to a 'virginity field', which mentions all back-rank pieces that have not moved and for which this has consequences. The pieces are indicated by the file they are on (as in Shredder FEN). On reading K and k should be interpreted as a shortcut for a virgin King and outermost h-side Rook, while Q and q are similar shortcuts for a virgin King and outermost A-side Rook. This is currently only used in Seirawan Chess, where 'gating' of pieces from the hand onto the board can only happen with the aid of a virgin non-Pawn. As soon as there are no pieces left to gate in the hand, virginity only has consequences for castling, and the virginity field would revert to the castling field in a backward-compatible way.

[sje]

How often is chess/shogi/xiangqi data originated by hand via a keyboard compared to being generated by an application? Ease of keyboard entry should be a minor consideration at best.

Trying to fit board data for tan shogi or taikyoku shogi or my GatChess (more on this later) on a single line of text is a hopeless task. Forcing the use of non-Asian glyphs for Asian games is chauvinistic to the point of cultural arrogance.

Here's what I propose:

[Part 0]

For each kind of chess/shogi/xiangqi, produce a Well-Formed-Object specification for position state representation. Each WFO specification is a bijective map to a conceptual diagram. However, the actual colors, fonts, and display attributes used to present the diagram are under application control. Application examples: a chess program, a shogi GUI, or a xiangqi document editor. The actual binary data is realized as a stream of Unicode so that it be readable by developers.

[Part 1]

For purposes of cut+paste, each WFO instance as needed gets its own hyperlink. The link will usually, but not always, point to some locally stored data. To cut+paste the position state, just cut+paste the link.

Example:

Say that there is a TalkTaikyokuShogi.com discussion board hosted in Tokyo, and on my computer is my own taikyoku shogi program. To communicate a diagram, I first have my program produce a position state snapshot which is presented to me as a short URL to local data. I then use my mouse to select and copy the URL and then paste it into the text box browser page from the TalkTaikyokuShogi.com site. A little JavaScript eats the paste which copies the local snapshot data and sends it on its way to be reproduced on the site's host machine. For the reverse, the reverse. No muss, no fuss, and no errors. Everyone gets to use the diagram style of their choice.

[Don]

Also, games with a dominant Asian tradition should be using Asian language glyphs. For many years the Sons of Asia have learned and used a non-native character set; shouldn't the Sons of Europe now act reciprocally?

Using kanji glyphs (encoded in UTF-8, say) for representing board positions of the large Shogi variants is in itself a good idea, which would immediately enjoy wide support from people currently playing these games. There is one real problem, though: unlike latin characters, kanji don't come in an upper-case and lower-case variety that could be used to distinguish the sides. A popular format for Shogi diagrams is simply bare kanji written in a table representing the board:



in this case the sides are distinguished by writing thekanji for one of the players upside down, which is a very natural representation for Shogi players, because in over-the-board play the orientation of the pieces similarly decides which side they are on. But unfortunately, there are no UTF-8 encodings for upside-down kanji...

Also, in games like Tai Shogi (25x25) it is not really possible to make unique single-kanji names for all the pieces with kanji that occur in their multi-kanji name. This because the same kanji occur in the names of many pieces. E.g. there are Gold, Silver, Copper, Left, Right and Great Generals, but also a Great, White and Drunk Elephant and a Great Dragon, a Flying Dragon and a Blue Dragon, a Dragon Horse and a Dragon King, a Honorable and a White Horse, a Left, Right and Flying Chariot, a Chariot Soldier, a Vertical and a Side Soldier, Vertical and Side Movers, etc., all with 2-kanji names. So although there are enough kanji in the Chinese/Japanese alphabet, there would not be an obvious mapping of single kanji to pieces.

Another problem is that even though such a representation would be applauded by (the quite small number of) existing players of these variants, it would be a great obstacle to a wider popularity.

In the absence of lowercase one could have 2 position fields - one for each side. It would make the fen string itself larger but presumably that is going to happen no matter what you do.

[Don]

How often is chess/shogi/xiangqi data originated by hand via a keyboard compared to being generated by an application? Ease of keyboard entry should be a minor consideration at best.

Trying to fit board data for tan shogi or taikyoku shogi or my GatChess (more on this later) on a single line of text is a hopeless task. Forcing the use of non-Asian glyphs for Asian games is chauvinistic to the point of cultural arrogance.

I wouldn't go that far - English has become a universal standard. Air traffic controllers for example must all know English and the entire world has been taught English as a second language. If you want good international communication it is necessary to have such a language and the entire world is accustomed to using English for this and especially in computing systems. All the mainstream programming language are based on English keywords. So this is not chauvinistic, it is just good sense. It's the only way to accommodate almost everyone without leaving entire groups of people out.

Having said that, UTF-8 characters are not a big deal and I don't see a problem with using them to describe the position. Also, I don't like it when they "americaninze" pieces for the GUI display, for example converting the classical Shogi pieces to a different form to make Western users happier. That would be like drawing Chinese characters on tokens to accommodate Chinese users for western chess - it would seem rather silly to us.

If we up to me we would all learn Esperanto as a second language and that would become the international standard. It's a very nice little language that can be quickly learned. But that would leave just about EVERYONE out in the dark!

Here's what I propose:

[Part 0]

For each kind of chess/shogi/xiangqi, produce a Well-Formed-Object specification for position state representation. Each WFO specification is a bijective map to a conceptual diagram. However, the actual colors, fonts, and display attributes used to present the diagram are under application control. Application examples: a chess program, a shogi GUI, or a xiangqi document editor. The actual binary data is realized as a stream of Unicode so that it be readable by developers.

[Part 1]

For purposes of cut+paste, each WFO instance as needed gets its own hyperlink. The link will usually, but not always, point to some locally stored data. To cut+paste the position state, just cut+paste the link.

Example:

Say that there is a TalkTaikyokuShogi.com discussion board hosted in Tokyo, and on my computer is my own taikyoku shogi program. To communicate a diagram, I first have my program produce a position state snapshot which is presented to me as a short URL to local data. I then use my mouse to select and copy the URL and then paste it into the text box browser page from the TalkTaikyokuShogi.com site. A little JavaScript eats the paste which copies the local snapshot data and sends it on its way to be reproduced on the site's host machine. For the reverse, the reverse. No muss, no fuss, and no errors. Everyone gets to use the diagram style of their choice.