より効率的な枝刈り！？

今は、macOS版MRWorkerの開発フェーズで、評価精度の向上用作業を完了した。その成果はMasterReversi本体にも反映するので、更新版(Ver1.5.8)を作成して微調整中なのだが、直感的な枝刈りが最も悩ましい。

作者はMasterReversi以外にもMirror-DTCも開発している。

Mirror-DTCの場合、サーバー側でキャプチャーしたデスクトップ画面をネットワークで転送してクライアントで映像化するのだが、この時に重要となるのは、転送する映像の圧縮形式だ。

プログラミングなんてした事がない！ みたいな人の場合、デスクトップ画像がどんな形式でコンピュータ内で表現されているかは知らないかもしれないのだが、ある程度の知識がある人なら、ピクセル単位でRGB形式で格納されている！ という事は知っている筈だ。

具体的には、フルHD解像度の画面の場合、デスクトップは、横1920ピクセル、縦1080ピクセルあるので、1920x1080=2073600ピクセルあって、それぞれのピクセルは、赤・緑・青の光の三元色の強さをそれぞれ256段階で表すRGB形式で表現される。

つまり、1ピクセルは、256*256*256 = 約1670万の異なる色表現が行えるので、今時のコンピュータでは1670万色が使える！ みたいな話になっている訳だ。

そんな事を言われても・・・、と、言う人も多い筈なのだが、パソコンの黎明期には、カラー表示が行えるパソコンでも、R・G・Bは1/0の1ビットでしか表せなかったので、2x2x2 = 8色表示しかできなかったりした。

もっとも、1ピクセルを3ビットで表すと、ハードウェア的には格納が面倒になるので、拡張ビットを付けて4ビット表現にした機種の場合、16色の表示ができたのだが、その延長線上で、その内、1ピクセルは8ビットで表現する様になったりした。

そうなると、表現可能な色は256色になったのだが、その256色にどんな色を採用するのか、というのは、別に、パレット、として定義しておく事で、より色々な色を、少ないメモリ搭載量のマシンでも使用できる様になった。

作者が大昔に購入したX68000では、1ピクセルは16ビットで表現できたので、65536色！ という事で、ここまでくれば、パレットを使わなくても、感覚的には、どんな色でも表現可能になった。

その後、RGBのそれぞれを256色、つまり、1ピクセルを24ビットで表現する様になると、フルカラー！ という事で、パレットを使用しなくても、人間が認識できるどんな色でも表現可能！ みたいになった訳だ。

もっとも、それではこれ以上に進化させる事が出来ないじゃないか！ という事で、ハイレゾ音源なんかと同じ感じで、今では、人間が普通は認識できない様な、RGBそれぞれを10ビットで表現する1024x1024x1024 = 10億色カラー！ みたいなモノも出てきているのだが、ハイレゾ音源と同様に、違いが認識できる人は、まず、いないので、現在でも、色数については24Bitで十分！ みたいな感じになっている筈だ。

と、言う事で、画像の色表現は、1ピクセルあたり24ビットで十分で、Appleが2014年くらいにリリースしたMacBookでは、Retinaディスプレイが採用された。

このディスプレイのピクセル密度は人間が認識できる解像度を超えているので、これ以上のディスプレイ密度の画面を搭載しても、ハイレゾ音源と同様に、この解像度は素晴らしい！ みたいに言う人は限られてくる事になる。

つまり、今では、人間が認識できるピクセル密度を超えた画面と、人間が認識できる範囲を超えた色表現が行える様になっているので、画面出力装置については、これ以上の進化は必要ない筈なのだが、実際には、NHKなんかでは8k放送！ なんかをやろうとしている訳だ。

これは、研究者だとか開発者は、何か新しい事をやらないと仕事がなくなるからなのだが、上記のRetinaディスプレイで重要となるのは、解像度ではなく、ピクセル密度になる。

なので、画面サイズを大きくすれば、より高い解像度を使っても意味が出てくるので、100インチの8k液晶に綺麗に表示できる8k放送！ みたいな話も出来きている訳だ。

と、言う事で、上記の話を見ていると、画像表現というのは、ピクセルとRGBの表現の組み合わせになっている！ みたいに感じられる筈だ。

なので、そんな画面表示を圧縮して転送しようとすると、解像度を下げるか、色表現のビット数を減らす事が考えられる筈だ。

このため、データ圧縮技術についての知識がない人は、フルカラーのフルHD画面を圧縮して転送する場合、色表現を24ビットから16ビットくらいに変更し、解像度もフルHDからDVD画質くらいに落とす事を鑑みる筈だ。

実際、そんな感じにする事で、24/16*1080/480^2 = 1.5*2.16*2.16=約7倍の圧縮率が実現できる。

つまり、フルカラーのフルHD表示には24*1920*1080 = 49766400ビットのデータ量が必要になるのだが、これを16ビットカラーのSD画質で転送すれば、16x854x480 = 6558720ビットのデータ量で済むので、49766400/6558720 = 約7.59倍の圧縮率が達成できる訳だ。

と、言う事で、普通に鑑みれば、デスクトップ映像の圧縮では、ある程度の画質を確保したければ、この程度の圧縮率が限界になりそうなのだが、実際には、そんな事は全くない。

何故なら、文字通り、全く異なる次元での、圧縮を行う事になるからなのだが、リバーシの枝刈りについても、同様の話が出てくる。

つまり、普通に鑑みられている枝刈りとは異なる次元での枝刈りを行うと、普通の枝刈りでは達成できない枝刈り、つまり、探索速度の向上が行えるのだが、そのためには、普通の枝刈りとは異なる副作用が出てくる訳だ。

具体的には、映像圧縮では、普通の圧縮を行っていたのでは出てこない様な映像のボヤケだとか、圧縮/展開負荷の増大なんかの副作用が発生する事になるのだが、枝刈りでは、評価値の誤差の増大が懸念される事になるのだが、その出方はリニアではない。

と、言う事で、リバーシの探索処理では、もう一つの枝刈りとして、どうせ、αβ探索用に全ての着手候補について、予め、その良し悪しを判定する簡易評価を行うので、その結果から、本探索を行う着手候補を制限してしまう、という手法も存在する。

この手法を適用すると、探索の途中でβカットだとかαカットだとかが発生するか否かのチェックすら不要に出来るので、より効率的な枝刈りが行える事になるのだが、これは、例えば、30残の局面で、浅い先読みを行って、悪い評価値が出た着手候補については、一切、評価を行わない！　みたいな事を意味する。

良くわかっている人は判っている筈なのだが、浅い先読みで得られる評価値と、深い先読みで得られる評価値は、結構、異なる場合も多い。

なので、こんな枝刈りを行うと、折角、30手の読切をさせているつもりでも、実際には、浅い先読みで行われる2,3手読みで、最善手が判定されてしまう事を意味したりもする訳だ。

と、言う事なので、そんな事はするべきではない！ みたいな声も聞こえてきそうなのだが、浅い先読みで-64石負けになっている着手候補と、64石勝ちになる着手候補が存在する場合、最善手になる確率が高そうなのは、直感的には、64石勝ちの方になる筈だ。

なので、昨日の記事にある様な前向き枝刈りを許容するのなら、こんな枝刈りも許容される筈なのだが、前述の映像圧縮と同様に、異なる方式の枝刈りを行うと、出てくる副作用というのも、予測しづらい今日この頃ではある。