●打倒・羽生善治？ 8/7/1999
先日ＮＨＫ教育ＴＶでコンピューター将棋の番組がありました。
チェスのチャンピオンにコンピューターが勝った時にも少し話題になりましたが、コンピューターが将棋のプロと互角に勝負するには当分先というのが一般的です。

番組ではカスパロフ氏を破ったディープブルーの開発者の１人が「資金を出してくれれば２、３年のうちにプロ棋士に勝てるシステムを作る」というコメントと、「この開発者は将棋をあまり知らないから簡単にいっているんだ」というコメントが流れていました。
ディープブルーが実際どういうシステムなのかは詳しくしりませんが、推測するに並列分散型のシステムで構成されていて、同時進行でいろいろなロジックを走らせているんじゃないかと思います。
並列システムというのは早い話「三人寄れば文殊の知恵」ということでマルチプロセッサがそれぞれ処理を分担して同時に計算を行っています。
（人間側は他人に相談して手を決めることはできないので、ある意味やや反則ということもいえなくはありません。(^^;）
並列分散型のシステムで将棋マシンを考えてみると、
まず、現状の将棋ソフトで使用されている思考ルーチンを走らせる。（現状のソフトは中盤の攻防には弱いが序盤、終盤あたりの手数がある程度限定される場面ではそこそこいける）
次に、プロの棋士に協力してもらってさまざまな棋譜とその場面での有効な手をデータベース化し、データベース検索システムを走らせる。この時用意しておくデータですが全ての棋譜を網羅することはできないので、中盤の難しい場面を中心にして作成する。
（プロ棋士もそれまでの経験や過去の棋譜、他人の対局などから記憶としてデータを持っているのわけでそのデータに近い情報をコンピューターに持たせるわけです。）
三つ目に、ある程度有効な手からアトランダムに一手を選んでその手のみを検討するルーチンを走らせる。（これは勘だとかひらめきとだとかを擬似的に作り出すためのルーチン）
四つ目に、勝負事というのは自分の土俵で試合をするというのが基本なのでコンピューターの得手不得手を考えて局面を得手の方に変化させる手を考えるルーチンを走らせる。（プロ棋士でも攻めに強い人もいれば守りに真価を発揮する人もいるわけでコンピューターはコンピューターの得手な状況を作らなくてはいけない）
５つ目に、悪手を探すルーチンを走らせる。これはこの手だけは打ってはいけないというのを明確にさせるためのルーチンです。
他にもきっと有用なルーチンがあるでしょうからそういったものも走らせ、それぞれの結果を比較して一手を決めればよい。
ただし、その際確率を少し付加しておく。これは「計算した結果が必ずしも正しいものとは限らない」ということを考慮してのことです。
あと、パソコンなどの将棋ソフトは人間の番になると入力待ちになり思考ルーチンが停止しているので、相手の番でも思考ルーチンが走るようにしておく。（人間同士なら当然やってることです）
こうして考えるとディープブルーの開発者がいうように意外とそう遠くない時点で羽生善治氏と互角？に闘えそうなマシンができそうな気もします。
プロ棋士の持ってるノウハウを基にデータベースの構築や思考ルーチンの判定を強化し、コンピューターの得手不得手はシステム開発者が検討する。
まさに「３人寄れば文殊の知恵」方式です。
コンピューター将棋といっても人が考えるシステムですから最終的には「人対人」の勝負だということです。
●ゲーム理論 7/15/1999
ゲーム理論という分野があります。これはゲームプレイヤーの意思決定のいろいろなパターンを考えプレイヤーの戦略などの解法を求めていく理論です。

意思決定のパターンにはマクシミン戦略（最悪な状況下を想定しその場合のいちばんいい選択を選ぶ）、マクシマックス戦略（最良の状況下を想定しその場合のいちばんいい選択を選ぶ）、 ミニマックス・リグレット戦略（選択したものが外れたという状況下を想定しその場合の後悔値（期待した結果と実際の結果との開き）が一番少ない選択を選ぶ）などがあって、こいうものを踏まえてゲームをシュミレートしていくわけです。
ゲーム理論はコンピューターを使ったシステムのいろいろなものに応用されていて、将棋やチェスのシステムにも使われているそうです。

ただゲーム理論によって必勝法が得られるわけではありません。
そもそもゲームがゲームとして成立するということはそのゲームに必勝法がないというのが絶対条件なわけで、必勝法がわかってしまえばそのゲームはゲームとして成り立たなくなります。
将棋に必勝法が見つかれば先手、後手が決まった時点で勝負がつくわけですから将棋がゲームとして存在しなくなります。

「必勝法がないのがゲーム」すなわち「ゲームに必勝法は存在しない」というのがゲーム理論の基本法則？なんでしょうね。
●最適化は最適か？ 4/12/1999
たまに発生するトラブルに最適化による不具合があります。
コンパイル時のオプションで最適化を指定すると、ソースコードの無駄な部分をカットしたり処理の速度をはやめる変更をおこないます。
これが結構曲者？でそのために予期せぬ不具合が発生します。

例えばループ処理で変数の値を加算してくという場合、メモリ上の領域の値を変更するより一旦値を汎用レジスタに転送しレジスタで加算処理をした後、結果をメモリに転送した方が速くなります。
最適化がこのように処理を変更するとループ中はメモリ上の値はものとままとなってしまい、マルチスレッドや共有メモリでループ中の値をチェックする処理だと問題がでたりします。

さらにやっかいなのが、デバッガを使うためにデバッグオプションをつけてコンパイルすると自動的に最適化が無効になって、デバッグ時に問題が発生せず原因がなかなか特定できないということも重なったりします。
最適化はあくまで元のソースコードを最適化するだけなので、「最適化をすれば劇的に処理がはやくなる」というケースはそうそうある事ではありません。（そもそも劇的にはやくなるというのは元のソースコードが悪いという事(^^;）

楽をするために人任せにすると、結局しんどい思いをする。
最適化はなるだけ指定しない方が良いという事なんでしょうね。
●改行コードをいれましょう 4/12/1999
UNIXで開発したときの話。
プログラムのデバッグの時「printf関数」をソースに入れてプログラムを追っかけるというのをよくしますが、ちゃんと改行コード「￥ｎ」を入れなかったためにプログラムが落ちたときに履歴が表示されないということがありました。
出力バッファに溜まったデータは改行コードがくると表示される。
それをしらなかったためにさんざん悩んだわたしでした。(^^;
●TESTプログラムが動かない？ 4/12/1999
ワークステーションのUNIXで開発したとき、動作確認用のテストプログラムを「test」という名前で作りました。
ところがこいつが動かない。(^^;
実行ファイル名がa.outだと動くのにtestだと駄目。

うーん何故？

実はUNIXには「test」というコマンドがあるからで、testという名で実行ファイルを作ったのが間違いだったわけです。(^^;
●アスキーとASCIIコード 4/4/1999
電脳コラムにも書きましたが、わたしがその昔MSXで最初にプログラミングをはじめた頃「株式会社ASCII」がASCIIコードを作ったと思っていました。(^^;
MSXというマシンはアスキーとMicroSoftが仕様を決めたゲーム機とパソコンとの中間的な機種なのでアスキーが文字コードのASCIIコードも作ったと思ってしまったわけです。

ちなみにASCIIコードというのはAmerican Standard Code for Information（アメリカ規格協会情報交換標準コード）の略称で、本来１バイト＝８ビットである文字コードを通信用に最上位ビットをエラー検出のためのパリティビットとして使い、残り７ビットに文字コードをあてたコードです。

余談ですが、インターネットをしていてよく半角カナを使うなという表記をみますが、これはＪＩＳ（日本工業規格）コードの半角カナがASCIIコードで空きになっている部分（つまり最上位ビットを含めた部分）に割り当てられているためで、 「エラー検出のためにわざと空けている」ということを考えなかった？ＪＩＳの致命的なミスによるものです。