FEN表記以外に、よりコンパクトなチェス位置表記が他にもありますか？もちろん、キャスティングの権利と、それに伴う可能性も伴います。FENで本当に欠けているのは、ポジションがチェックメイトに対応しているか、それともチェックに対応しているかについての情報がないことです。もちろん、いつでもボードにポジションを置いて、それがチェックメイトかどうかを確認することはできますが、表記から直接推定することはできません。したがって、そのようなプロパティは、可能な表記法を区別する上でも重要になります（コンパクトさなどは別として）。

それが役立つ場合、これはプログラミングの実用性と効率性の理由で求められます。提案をありがとう。

あなたはプログラミングについて話しているので、おそらくFENよりもコンピュータのメモリ空間でよりコンパクトなストレージスキームを探しているでしょう。大きなテーブルベースでそれがどのように行われるかを調査することに加えて、2つの可能性がすぐに思い浮かびます。

通常のFEN

この説明のために、「通常の」FENは、1バイト（8ビット）文字で表される単なる典型的なテキスト文字列です。単純化された最悪のケースを見てみましょう：

r1b1k1n1/1p1p1p1p/p1p1p1p1/1n1q1b1r/R1B1P1N1/1P1P1P1P/P1P1K1P1/1N1Q1B1R w KQkq e3 999 999

もちろん、これは有効なFENではありませんが、複雑さの有効な上限です。ランクごとに8文字、プラス7つのスラッシュ、5つのスペース、および13の追加文字が残りのフィールドを構成します。これは89文字で、合計サイズは712ビットです。

圧縮FEN

このバージョンは、FEN表現を採用し、いくつかの基本的な観察を使用して、それを格納するために必要なビット数を削減しています。ここに私たちの観察があります：

1. マシンの保管にはスラッシュは不要です。各ランクは単に「8に加算」する必要があります。そのため、内部表現のスラッシュを排除できます。
2. 残りの可能な文字（最初のセクション）は次のとおりkK qQ rR bB nN pP 12345678です。20文字の区別は5ビットに収まるので、単純化した最悪のケースでは、5ビットx 8ファイルx 8ランクで、最初の部分は320ビットです。
3. スペースは必要ありません。再び彼らは人間にとって便利です。これで5文字節約できます。
4. 「誰が動くのか」は1ビットです。白か黒です。
5. Castlingの可用性は4ビットですKQkq。それぞれで使用可能/使用不可です。
6. En passantは通常は使用できず、多くのスペース（6ビットですべての正方形を表す）を占める可能性があるため、最後に移動してオプションにします。enpassantビットが存在する場合は使用できますが、使用できない場合はスペースを節約するために、移動および半移動ビットの後に表現を終了するだけです。
7. 簡単にするために、移動と半移動の各カウンターに10ビットを割り当てています。つまり、この形式で表されるゲームは1023移動（最後のキャプチャまたはポーンの前進からの半分の移動）を超えることはできません。

私たちの完全なフォーマットは次のようになります（en passantが利用可能な簡略化された最悪の場合）：

<position><whose move><castling><half moves><full moves><en passant>
 320 bits  1 bit       4 bits    10 bits     10 bits     6 bits

これにより、不可能な最悪の場合の合計サイズは351ビットになり、開始点のサイズの半分未満になります。

µFEN

表現の肉のためにFENを完全に放棄すると、もう少しスリムにすることができます。単一の任意の正方形を考えます。その正方形は空である場合もあれば、その上に駒がある場合もあります。駒がある場合、それは白または黒のいずれかであり、キング、クイーン、ルーク、ビショップ、ナイト、またはポーンです。これは合計13の異なる状態であり、4ビットで表すことができます。このようなもの：

0000: empty square
0001: White Pawn
0010: White Knight
0011: White Bishop
0100: White Rook
0101: White Queen
0110: White King
0111: unused
1000: unused
1001: Black Pawn
1010: Black Knight
1011: Black Bishop
1100: Black Rook
1101: Black Queen
1110: Black King
1111: unused

明らかに、いくつかの未使用の「部分ビット」があるため、この手法は、圧縮技術の知識がある人、または単に異なる状態のより注意深いマッピングによって、ほぼ間違いなくさらに改善できる可能性があります。また、実際には、隣接する空白スペースの圧縮がないため、これは上記の圧縮FEN よりも大きくなる可能性があります。ただし、ボード全体を常に256ビット（4ビット* 64平方）で表します。これは、最悪の場合で20％改善されます。

簡単にするために、圧縮FENの後半にタグを​​付けるだけで表現を完成させます。したがって、フォーマットは次のようになります。

<position><whose move><castling><half moves><full moves><en passant>
 256 bits  1 bit       4 bits    10 bits     10 bits     6 bits

これにより、ワーストケースのスペース要件が287ビットになります。悪くない！

注1：私はコンピューターサイエンスの経験があるため、これはすべて最悪のケースの分析にすぎません。標準のFENは通常、私が説明したよりもはるかに優れたパフォーマンスを発揮します。これは、通常の位置が、ここでの比較に使用した全員のシナリオではないためです。したがって、改善率は実際に私が実際に示したものより少し低い可能性が高いですが、少なくとも圧縮されたFEN表現については、傾向はおそらくまだ残っています。誰かが標準のFEN（ひいては上記で提案された圧縮バージョン）の確率論的平均ケース分析を実行したい場合は、非常に興味があります。

注2：圧縮形式を処理するための速度のトレードオフは、アプリケーションにとって価値がある場合とない場合があることに注意してください。使用している言語と個々のビットに対する制御レベルによっては、より多くのスペースが必要な場合でも、単純なFENの方がはるかに高速に使用できる場合があります。

注3：新しく提案された表記のいずれかに「チェック/チェックメイト/チェックなし」インジケーターを追加する場合、それは3つの追加の状態を表す追加の2ビットです。en passantインジケーターの前に投げ込みます。

拡張位置記述（EPD）は、FENに「操作」を追加します。これらの操作には、特に、ベストムーブ、繰り返しカウント、予測ムーブなどがあります。それは、明らかに、よりコンパクトではありませんが、より多くのことを行います。

明らかなものがない場合を除いて、表現は

0      empty
100    white pawn
101    black pawn
110xxx any piece except Rook
111x   Rook

32 * 1 + 16 * 3 + 12 * 6 + 4 * 4 = 168の位置ビットでフルハウス（つまり、キャプチャ前）をエンコードします。さらに、もちろん、4つの城ビット、3つのen passantビット、7または8つの50ムーブルールビット。

最悪の場合（8個のポーンが他の8個のポーンをキャプチャするコストによって促進され、20個+ 4個のルークがボード上にある）、40 * 1 + 20 * 6 + 4 * 4 = 176位置ビットが必要です。

ボードとすべての情報（50ムーブルールを除く）を扱いやすい256ビットに収めることができます。私は以下を提案します。64の正方形と1正方形あたり4ビットにより、16の可能な状態が可能になります。0は空の正方形を表します。次に、6個を用意しますが、「可動ルーク」用に7個を予約するので、キャスリングの可能性を判断できます。白または黒を示す1ビット。15の状態を使用しており、残りの1つの状態は値8（1000バイナリ）です。これは感情の正方形も表しますが、3番目または6番目のランクでそれを使用して、その前のポーンが2つの正方形に移動し、「不死身」に捕獲されることを示すことができます。最後に、この値を使用して移動する側を示します。ボードの下半分にある最初のエンパイスクエアを見つけて、移動するのが白であることを示します。黒の上半分。

あなたが尋ねた：FENの本当に足りない部分の1つは、ポジションがチェックメイトに対応しているか、その問題のチェックに対応しているかに関する情報を持たないという事実です。もちろん、いつでもボードにポジションを置いて、それがチェックメイトかどうかを確認することはできますが、表記から直接推定することはできません。

この時点で、計算のみで複雑な情報を記述だけにすべきものに埋め込もうとするのは良い質問かもしれません。

同じことが移動記法にも適用されます-たとえば、代数記法（e2e4 b1c3）とSAN（e4 Nc3）の間-後者は、すべての移動のTO位置を計算するエンジンを必要とし、前者はデコードするのに計算が複雑ですが、前者推論されたTOの位置を決定するためにmoveジェネレーター全体を記述する必要はありません。これは有益な場合があります。