「　連データベースを作ろうと思う」


「　勝手にしろだぜ」


「　それはデータベースなの？」


「　説明する」


［１］A1
［２］B２
［３］C3
［４］D４（B2）


「　↑　実践譜を用意するのが　めんどくさいので適当だが、
将棋のような棋譜を　囲碁にも導入するとする」


［４］　　D４　　　（B2）
ーーー　　ーーー　　ーーー
１　　　　２　　　　３

１．　何手目（序数）
２．　着手点
３．　コウ


「　↑　将棋と違って　コウ　も記憶しておく必要がある」


「　なんで必要なんだぜ？」


「　人間の棋譜は　さかのぼって読まないから　戻し方を書いていないが、
コンピューターは　さかのぼって読むから　戻し方も書いている必要がある」


「　さかのぼり方を考えるの、逆関数って言うのよ。
関数に比べて　逆関数は　ふだん　そんなこと考えて生きてない人には　奇異　に映るのよ」


「　勝手に映ってろだぜ」

［１］A1
［２］B２
［３］C3
［４］D４（B2）　取った石：C3
　　　　　　　　　ーーーーーーーー


「　↑　だから　棋譜には　取った石を記録しておく必要があるんだが……」


［２０］J10　　取った石：G９，G１０，H９，H１０
　　　　　　　　　　　　ーーーーーーーーーーーーーー



「　↑　大石を打ち上げたら　すごい数になるかもしらん。
３６０個ぐらい石を打ち上げたらどうしよ」


「　３６０個　覚えておけだぜ」

リレーショナル・データベース

「　棋譜に　取った石　３６０個も　記録したくないぜ。
既存の技術に倣って、リレーショナル・データベースのやり方を導入しようぜ？」


［２０］　　　［G9］　　　　→　　　G９，G１０，H９，H１０
ーーーーー　　ーーーーー　　　　　ーーーーーーーーーーーーーー
１　　　　　　２　　　　　　　　　３

１．　何手目（序数）
２．　連の石の中で一番小さな番地
３．　連の石の番地のリスト



「　↑　何手目と、連の石の中で一番小さな番地　を覚えておけば、
どの連か　一意に指定できるはずだぜ」


「　ほんとか」


「　棋譜の変化は　考慮しないものとする」


［２０］J10　　取った連のId：G９
　　　　　　　　　　　　　　ーーーー



「　↑　棋譜は　すっきりするな」


「　石を打ち上げるたびに　何番地の石を取った、と　いちいち　覚えておくの？」


「　そうだぜ」


「　打ち上げる石の数は　１９路盤なら　１～３６０個あるな。
可変長配列に格納するか」


「　Go言語は　ガベージコレクション　を使う言語らしく、
その占有メモリを参照している変数が無くなれば　占有メモリは開放されると思うぜ」


「　ほんとか」


「　ほんとよ。　細かい人は　ポインター変数に nil を代入してでも
占有メモリを　解放の対象にするわよ」

別々にする必要性

「　棋譜と　連データベースを　別々にする必要性はあるのかだぜ？」


「　のちのち、取った石の連だけではなく、
全局面の　すべての連を　連データベースに　格納する予定だぜ」

マッピング

「　『２０手目のＪ２』　とか　『３０手目のＫ１０』　とか
どういう構造に並べてもち、
どういう探索で見つけ当てる？」


「　Go言語に　ハッシュテーブル　はあるの？」

 [Go言語] 初心者必見シリーズ: マップ（Map）  


「　↑　マップという名前であるようだぜ」


「　キーはどういう構造にする？」


何手目　×　盤の面積　＋　連の石の最小の番地



「　↑　上式なら　int型　に収まるだろうし、文字列よりシンプルじゃないか？」


どうやって　テストするのか



「　コードを書いたが、テストするの　めんどくさいな」


「　連データベースを　インポート、エクスポート　できるようにしたらいいんじゃない？」


「　じゃあ　JSONフォーマットを定義するかだぜ」

{
    "header" :
    {
        "boardWidth" : 19,
        "boardHeight" : 19
    },
    "rens" :
    {
        "{id}" :
        {
            "posNth" : 1,
            "locate" : "A1 B2 C3 D4"
        }
    }
}


「　その `{id}` は手計算で求めんの？
このダンプを　設定ファイルとして見たとき、めんどくさくない？」


「　じゃあ　"1, A1" みたいな文字列にするかだぜ？」


「　とりあえず　それで」

連データベースに　連を追加してみようぜ？

「　お父ん、　連データベースは　どうやって使う？」


「　初期局面は、盤面をフルスキャンしろだぜ」


「　なんか　適当な　囲碁の局面図が欲しいけど、囲碁は棋譜の権利にうるさいのよ。
適当な盤面のデータを作って　読み込んでみましょう」




「　↑　これでいいかな？」


「　適当だな」


「　その盤面をスキャンして、連データベースを　外部ファイルにエクスポートして、
盤上の連を認識できているか　確かめましょう！」




「　↑　連じゃなくて　なんか全部の交点を出力しようとしてないかだぜ？」


「　直せ！」

辞書順ソート

「　"A1" みたいな符号で　辞書順に出力すると、
読取方向が変わるぜ！」


「　"01A" にすりゃ　いいんじゃないの？」


「　可読性が下がるだろ」


「　外部テキストファイルは　人間が読むものと思えだぜ。
可読性の低いファイルは　流行らない」


「　国際囲碁連盟に従う必要は無いんじゃないの？」


「　パワフルだな」


「　最小の番地を Id にするのではなくて、最大の番地を Id にしたらどうだぜ？」


「　発想きたな」


「　人間は　右下から　盤を見るの？　見づらいんだけど」

"1, 01A"


「　↑　Id だけ 段→列　にひっくり返すというのは　どうだぜ？」


「　納得度があり、許容範囲内の答えだぜ。　それで行こ」




「　↑　いーんじゃねーの」

2手目以降は差分

「　２手目以降は、盤面全体をスキャンしなくても、
石を置いてみて
置く前の盤と変ったところだけ　記録すればいいと思うんだぜ」


「　その前にやることがあると思うぜ。
どの連と　隣接しているか　を表せだぜ」


「　"001,01A"　という黒石の連は、　"001,01B"　という黒石の連と
隣接しているのよ」

「　それは　『連データベース』　ではなくて　『連単位データベース』　のような
別の構造で　やりたいぜ」


「　記事が長くなったので　次の記事にしろだぜ」