[過去ﾛｸﾞ] 【オセロ,将棋】ボードゲーム【囲碁,War】 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
317: 310 2015/09/02(水)11:43 ID:s0BtWfox(1) AAS
ぬぬぬ。パターンによる線形回帰の石差予想。
最急降下法は収束してるんだけど平均２乗誤差が４８０とかになる。
１σでいうと１局面あたり２２石（黒石の数では１１石）もの誤差。
これでは使い物にならない。
ステージ分割しているんだけど、ステージが進んでも誤差はほぼ一緒。
ウェイトがオールゼロでも似たような数字になるレベル。
テストデータで局面評価させると、それなりに石差は計算しているっぽいが、
最善手で終局まで打ったデータ入れるとステージによって評価値が全く違う。
初期値をゼロからスタートすると、この辺なんだけど、１とかからスタートすると
もっと誤差が大きいところで収束してしまう。初期値を乱数にしたら、更に大きな
誤差で収束してしまう。
ローカルミニマムに捕まってるのかなぁ。
いくつかミスは見つけたけど、本質的な場所じゃないので、結果も変わらず。
むむむむ。
318: 2015/09/02(水)16:33 ID:6FNrQBf/(1) AAS
正規化をミスってる
319: 310 2015/09/02(水)21:57 ID:5gNGVEfH(1) AAS
正規化というと、thellさんのlearning.pdfで言うところの、αの設定ですか？
当初はmin（β/100,β/Nj）の正規化型で作ってましたが、上手くいかないので
収束を早めるのは後回にして、今は単純にステージ毎の局面データ件数α=β/Nの
形にしてます。
が、発散を避けようとすると、βをあまりに小さくしなければならないのが、なんか変な
気がしています。今は10の-7〜-8乗くらいの値です。やっぱり変ですよね。
最急降下法のコードどこか間違えてるんだろうなぁ。
320(1): 2015/09/03(木)04:25 ID:CNXgxM7O(1/2) AAS
でもオセロだったら最終数手で１１石くらいひっくり返ってぶれるのは普通じゃない？
321: 2015/09/03(木)04:36 ID:CNXgxM7O(2/2) AAS
あ、オセロのＡＩにはぜんぜん詳しくないんだけど
対局を見てたらクルクル石差が入れ替わるので
読み切らずに局面から石差を判断すると
どうなるんかなと思って
322: 310 2015/09/03(木)10:19 ID:Fd8XT4rV(1/2) AAS
色々と失礼しました。
もう一度、よーく上記pdfを読み返していたところ、原因らしきものが見つかりました。
記載にあいまいというか、ちょっとおかしいところがあって、式の変形をしっかり追って
確認すれば良かったのですが、思い込みで解釈をして変な計算をしていました。
そこをとりあえずざっと修正したところ、遅々としつつも収束に向かっている模様ですが、
まだまだ完全ではないようです。ある程度二乗誤差が減ったところで、また増え始めたり
しています。正規化も試したけど、やはり同じ。
もう少し、検討してみます。
323(1): 310 2015/09/03(木)10:38 ID:Fd8XT4rV(2/2) AAS
>>320
もともとひっくり返しあった後の終局を予測するのが目的なので、教師データは最終局面
の石差です。盤面の特徴（パターン）から、最終石差を予想するための重回帰計算なので、
その時点の石数は、説明変数に入れてません。なので、パターンの選択が適切なら、
最善手の応酬において１手毎にどれだけ石数が入れ替わろうと、影響を受けずに、
二乗誤差が終局に近づくほど減っていくと予想されます。
というか、そうなるように説明変数であるところのパターンを模索していくと理解しています。
手元にあるwzebraなんかは、評価値と称して最終石差予想が表示されているのですが、
やはり、ある程度の誤差を含みつつも、大きくぶれているようには見えません。
評価関数の使い道を考えると、実は絶対値はそれほど重要ではありません。
中盤探索のｎ手読みの時の盤面評価と、ムーブオーダリングに使うので、ある局面から
派生したｎ手先の局面における相対的な関係が保たれていればOKです。
また、MTD(f)法などを使う時の、ｆの初期値設定にも使います。この時は絶対値で正確な
方が良いはずですが、外れはすぐにカットされて次に行くので、トータルの時間に対する
影響は小さいように感じます。
とはいえ、相対的な関係が保たれているのかをチェックするのは難しいですから、
結局のところ出来上がった評価関数の評価は、教師データとの二乗誤差の小ささに
するしかないかなと。
324: 310 2015/09/07(月)01:11 ID:OHPpdG+6(1) AAS
収束しかかった二乗誤差がまた増え始める原因はまだわかりません。
増え始めるまでは収束方向には向かっているのは確かなのでβの初期設定を
いって誤魔化す方向で。最急降下法ってこんなものなのかなぁ。
一通り納得したので、パターンをLogistelloと同一のものにまで拡充してスムージングも
入れてみましたが、新たなバグを仕込んでしまった模様で、一部計算がぐちゃぐちゃorz
バグ探しの旅に出ます。
裏で、Solverの速度アップを検討。
CountBitとPOPCountを組み込み関数にしてみました。FFO#40で30%ほど改善。
続いてFlip関数を６４個のポインタ関数にしてみましたが、時間はほぼ変わらず。
ポインタ関数内の処理が非効率なのか。
Flipのデバッグ中に確定石計算でバグっぽいものを見つけましたが、回帰が落ち着く
まで見なかった事にします。
325: 2015/09/10(木)17:45 ID:R9JX9LJx(1) AAS
将棋の全駒にユニークなIDを振り、局面を将棋盤に見立てたkoma[9,9]にIDを入れることで表現しようと思っています
その場合、駒のIDから座標を取得するいい方法ってないんでしょうか？
IF文、Case文のオンパレードになってしまうのは仕方ないのでしょうか・・・・
言語C#
326: 2015/09/13(日)16:22 ID:5eWB08IT(1) AAS
駒側にも座標を持っちゃえば？
327: 310 2015/09/14(月)09:33 ID:Rx5y2/Cc(1/2) AAS
線形回帰で相変わらず時間食ってます。
一応、バグらしきものはそれなりに解消されましたが、やはりいかんせん収束が遅い。
一晩かけて５０〜１００試行して、途中で止めてやり直しなんてのやってる間に１週間は
あっという間に経ってしまうものです。まだ誤差が大きい。１０００回程度回して、どこまで
収束するか見てみようかなと。またぞろ３層パーセプトロンが気になる今日この頃。
確定石計算もバグ取りはできたと思いますが、その分計算が１．５倍ほどに膨れてしまい
ました。しばらく思考実験していたら、確定石なのに確定していると評価できない確実な
パターンも思いついてしまって、どうせその程度のものなら重い確定石計算しないで普通
に準確定石程度にしとくのが良いかと悩み中。
Solverの速度アップですが、前からやろうと思っていた事を少しづつやっていますが、
統計とってきちんとやっていないので１０％くらいの差だと良くわからない状況です。
コードのメンテナンス性が下がるのがネック。negaMAXが思いの他高速化してしまい
ましたが、MTD(ｆ）が低速化しているかも（謎）。
それなりに評価関数が動きだしたので、置換表２枚にして反復深化も試してますが、
信じられないくらい劇遅状態です。これ本当にコストに見合うのかなぁ。評価関数の
計算が、というか、その中の確定石計算が重いんだと思うけど・・・。
328: 310 2015/09/14(月)17:35 ID:Rx5y2/Cc(2/2) AAS
反復深化が劇遅なのは、使い方を誤っていました。
リーフのところまで使うとコストアップなのは考えれば当然でした。
まあ、おバカなバグもありましたが。
negaMaxに対して反復深化を試すと、１割程度の高速化となりましたが、
negaScoutに対してやると多少低速化して、negaMaxの反復深化と変わらない速度に。
scout missが３倍近く増えているので、評価関数の精度があまり良くないためかなと。
move orderには、通常はmobilityとコーナー着手を使用しているのですが、これ、
何故か（少なくともFFO#40に対しては）scout missが恐ろしく少ないのです・・・。
MTD(f)が遅いのも、最初に設定するfを評価関数の値にして、それが結構外れで、
探索範囲が広がったのが原因です。scout missと同様に、結局のところ、途中で評価関数
を求めるタイプの高速化は、評価関数の精度次第という当たり前の結果に。
評価関数入れるとノード探索時間が1/10になるので、やはり評価関数用の確定石計算は
準確定石にレベルダウンしようかと思います。中盤AIでの話ですが。
今FFO#40が９秒台なので、あと３〜５倍高速化したい。
329: 2015/09/14(月)21:42 ID:1S1dymvg(1) AAS
その情熱がうらやましい
330: 310 2015/09/15(火)20:18 ID:egtjjW0V(1) AAS
準確定石の計算って実は思ったよりコストフルかもと気づいてしまい、
急きょコーディングして比較してみる事にしました。
releaseモードだと、自分の計算方法では跡形も残らないため、時間計測不可能。
debugモードでも、数十倍速いと言う結果になりましたので、今の確定石計算ロジック
は、悪いモノではないと自分に言い聞かせる事にしました。
それより、回帰の学習で、少しずつ少しずつ２５０回くらいまで学習進めていたのですが、
バグを見つけてしまい、またやり直しです。むむむ。しかも、なおした事で計算時間が
２〜３倍になってしまうという。
331: 2015/09/19(土)00:46 ID:OgvQcqwn(1) AAS
回帰がやっとまともっぽいところまで収束するようになりました。
今、２５０回学習で、最終ステージが１σ＝７．５程度です。
このペースだと、もっと学習させても、たいして変わらない気もしますが、
もう少し学習を進めてみようかと思います。
この評価関数を元に、反復深化＋MTDF+negaScoutなsolverを動かして
FFO#40で８秒程度になります。インライン関数化とか、最終２手展開とか
やるべき事はある程度やっちゃったので、自分の力だとこの辺が限度かも。
332: 310 2015/09/22(火)22:15 ID:70n8Fwqa(1) AAS
回帰は地道に学習中。もう少しやってみるって感じだけど、収束状態の誤差が大きいのは
ステージ分割でオリジナルな変な事をしているからじゃないかと気になりだした。
あと数百回学習を回したら、通常のステージ分割版も作ってみるかなと。
色々いじってるうちに、FFO#40が６．２秒まで来た。何が良かったのか良くわからない。
反復深化をターゲットに改良しているんだけど、negaScoutも同じ時間。
FFO#41を試したら、反復深化で４５秒弱、negaScoutで３０秒弱という結果に。
探索ノード数がすごい事になってるので、反復深化のmoveorderのどこかがおかしい
気がしている。
333: 310 2015/09/25(金)16:54 ID:9OkLc3+M(1) AAS
回帰のステージ分割というかスムージングを、ネット上でノウハウ公開されてるみなさん
と同じようにしたら、１σで６を切ってきた。やっぱ、スムージングやり過ぎて、精度が
落ちていたのね。同一ステージ内でも値がばらついているので本当に必要なのか、
気になるので、落ち着いたら両方試そうかと。先に方向性見ちゃったから本来とは
逆順になっちゃうけど。
色々頑張ったら、FFO#40が５．１秒、#41が２０秒、#42が１８秒となりました。
ソースとにらめっこしてれば、ネタはそれなりに出てくるものだなぁと。
しかし、１０年前のCPU使ってるThellにようやく勝てた程度。
Zebraの速さは何なんだと。こちらはcore i7だというのに。
目下の悩みは、_mm_popcnt_u64とBitScanFoward64が使えずに、それぞれ32ビット版を
使っている事。外部依存のところで関数の存在は確認しているんだけど、「そんな名前ない」
と出てくる。Cは趣味のAVRで小さいプログラムしか作った事がなかったけど、VC++くらい
巨大になると、どーもよーわからん。
334: 310 2015/10/04(日)01:12 ID:+bDErzEp(1) AAS
色々やって、FFO#40でnegaScoutで３．４秒まで来ました。
反復深化は異なる方法で２種類作ってみたけど、FFO#40程度の深さだとnegaScoutとの
差が出てこない。２２手とか２４手とかまで行くと、差が出てくるように感じるけど、後回し。
どうしても気になって、Zebraのソース解説（日本語）を見つけて、そこに出てるソースを
見ました。自分なりにロジック面で工夫した事はほぼ同じ事をやっている。流石。
あとマクロを多用してる。僕はインライン指定でコンパイラ任せ。
マクロにするとデバッグが極端に大変になるので、マクロ化するのは最後。
そしてaspiration windowと称しているWindowの取り方が独特で、ここに高速化の
秘密があるとみた。早速真似してみると、また>>310のような問題が・・・
今回は前より理解が進んでいたため、２点修正して解消。
副次的に>>310の問題も、直ったと思う。
が、もう一つ答えを間違うケースを見つけてしまった。
今まではルートノードに問題があったけど、こちらはもっと下位ノードで戻り値がコンタミ
してる感じ。デバッグが難しく、重症っぽい。むむむ。
335: 310 2015/10/07(水)17:10 ID:i7/9rua6(1) AAS
デバッグで試しに変えた箇所を戻し忘れたりして、二次災害三次災害を出して、
相当混乱したけど、やっぱり境界問題だった。これmoveorderの順によって出ない
可能性もあるので厄介。自分は開き直って、探索の幅に-1つけてるけど、皆さんは
どう回避しているのかなぁ。
zebraのwindowの取り方は、基本的にMTD(f)みたいに置換表利用を前提とした、
固定分割サーチだけど、negaScout（MTD(f)やzebra方式の中で使用している）と
速度的には同等な感じ。最初の探索で勝敗がわかるという点がメリットなのか。
MTD(f)は評価関数が正しくないと、検索時間が伸びる可能性があって、以前から
negaScout単体でも十分な気がしてる。
FFO#40は後述の静的評価関数を判明しているパラメータで最適化すると、
negaMaxで５秒台。negaScoutで３．４秒前後。MTD(f)で２．６秒前後。
ThellさんのHP記載よりは高速化したけど、zebraにはまだ勝てないというか、テストした
FFO#41〜#43ではzebraの高速度合（ノード数の少なさ）が突出している。
ノード削減はmvorder用の静的評価関数に掛かっている。静的評価関数のパラメーター
をいじってるけど、FFO#40最速のパラメータとFFO#43最速のパラメータが違い、#43用は
#43ではノード数を半減できるのに、#40では増えて遅くなってしまう。negaMaxで初段の
評価順見てると、まだまだなので、何か別の発想で並び替えが必要な感じ。
評価関数は１０００回くらい回してようやく良い感じになってきたけど、まだ収束しては
いない感じ。学習係数はもっと大胆に大きくしても良かったかな。ここまでやると、
スムージング無しを試すのが億劫になってくる。
反復深化は、ソースのメンテが追い付いていないので、一回破棄。
336: 310 2015/10/12(月)23:43 ID:ZTwsIi7y(1) AAS
色々やってるけど、FFO#40では速度向上はほとんどなし。
置換表のサイズが見えて来たので、１件ごとにmallocしていたのを、配列にして一括で
領域確保するように変更（当初の形）したら、速度のバラツキがだいぶ減ったように思う。
NPSが変動すると、何か悪いことしかたと悩んでしまい、修正して二次災害を起こすので
地味に大事かな。
FFO#43は多少高速化してて、パラメータ最適化するとMTD(f)で１２秒台くらい。置換表
適用範囲の指定を下（葉）からしていたのを、上（ルート）からに変えた。あと、MTD(ｆ）
などでは何回も置換表を読むので、２回目からはmoveorderに置換表の評価を使うよう
にした。
BITBOARDだと開放度の計算が簡単だという事に気づいて、静的評価関数に使ってみた
けど、現在使用中の次手mobility＋αの順序より劣る感じ。＋αが角とか×とかなので、
序盤から中盤用なのかなぁ。
negaScoutに加えた修正をnegaMaxに適用していたら、negaMaxがおかしくなった。
直して計測したらFFO#40が４０秒程度に。冷静に考えると、これが常識的な速度だと思う。
前回の５秒台がどこから出て来たのか、今となってはわからない。前段の＋α箇所も
結構変えていて、negaMaxはmoveorderで露骨にノードが増減するので、奇跡的な順序
が実現できていたのか。それともバグやオペミス勘違いかも。
そろそろ本格的にネタ切れ。この辺が限界かなぁ。
後回しにしていた修正箇所を直して綺麗になったら、中盤に行くかな。
337: 310 2015/10/14(水)23:51 ID:V3YF/mde(1) AAS
negaMaxはmoveorderの修正漏れでバグってて、直したらやはりFFO#40で５．４秒でした。
MTD(ｆ）は２．４秒でzebra並になったけど、#41以後は３〜４倍時間がかかる。
その差は探索ノード数に比例してる。前向き枝刈使うわけにはいかないし、#41以降の
差を詰めるにはmoveorderしかないと思う。
とはいえ主だった事は一通り試してしまった。むむむ。
偶数理論で思いついた方法が純粋に面白そうなので組んでみる。
想定では、速度が結構遅くなるはずなんだけど、まあ面白そうという事で。
338: 310 2015/10/16(金)10:24 ID:Q2afyb0d(1) AAS
偶数理論の関数は思いのほか軽くできて、オーバーヘッドの心配が少ないです。
BITBOARDの空マスを、囲まれて独立している塊ごとに分離してBITBOARD配列にして
返す関数を作りました。これをPOPCountで数えて着手した場所が偶数空エリアなのか
奇数空エリアなのかを判定します。
最初にテストしたFFO#43のMTD(ｆ）でいきなり３０％近く高速化して「やった！」と思った
のもつかの間。実はミスで判定を逆にしてまして、偶数マスに打って奇数を相手に渡すと
加点になってました。で、いろいろテストした結果、最初にやったケースではたまたま
良かっただけみたい。例えばnegaScoutやnegaMaxでテストすると、係数変えたり判定
方法に工夫を加えたりいろいろしてみても、何をやっても探索ノードが増えてしまう。
自分はオセロ弱いので、必勝法みたいに言われているものが、アバウト的に最善手に
近い手を選んでくれるんなら、並び順の優先順位計算に、あるウェイトで入れてみようか
的に考えるだけでした。意味とか深く考えるよりやってみるという感じでした。が、最後に
残った２つの空所が偶数と奇数とかの例ならわかりやすいけど、空所が４〜５か所ある
ような状況で偶数理論を当てはめようというのが間違いなのかなぁと。
あと、薄々思っているんだけど、テストケースとしてFFOは良くないんじゃないかと（汗
FFOに最適化してると、もっと出現頻度が高い例題でより高速化できる可能性を放棄
しちゃっている事にならないかと。
339: 310 2015/10/17(土)09:29 ID:uZH1KzRS(1) AAS
最終２手高速化したあたりから、ノード数が過小になっていたので、それを直しました。
自分のと比較すればよいかと思って放置していましたが、そろそろちゃんと比較しようかなと。
結果、探索ノードが思っていた以上に多かった事、そしてNPSは９〜１１K出てるので、
NPSを落としてノード削減する余地があるという結果に。
あまりテストしていなかったFFO#41と42ではzebra方式と呼んでいた（後述）方法が、自分の
中では最速で、MTD(ｆ）の結果があまり思わしくない事も。MTD(ｆ）の#40は初期条件が良か
ったからの模様。
ここらへんでもう一度、zebraサイトのFFOテストページにあるcomplete logなるものを見て
みると、全然違う。バージョン違いなのか、やってる事が全く違う。
浅い探索をしてｆを決めてNull window search（正確には幅３なので正解が判別できる）
を繰り返しているように見える。けど、ログ上に％が出てきて、９８％、９９％、％無しみたい
になっているので、何らかの方法で前向き枝刈しながら、評価値を求めていき、最後まで
幅３の探索しかしていないのかな。こういうのをPVSって言うのかな。
浅い読みとか、前向き枝刈とか絡んでくるんなら、中盤探索をやってから戻ってきた方が
よいのかな。。
340: 2015/10/19(月)09:50 ID:BMJ9Bhec(1) AAS
とりあえず、ざっくり中盤探索のnegaScoutを組んでみた。
素の状態で１０手読みくらいなら１手１０秒以内に終わりそうな感じ。
だけど、いろいろと気になる点が。
とり同一局面から着手可能な手の評価値の順番は、あまりくるっては
いないように見える。ただ、評価値事態は結構ずれている。
そして、黒番白番で精度が全く違うように見える。
言われてみれば、同一局面でも手番が逆転すると評価は全く変わるからなぁ。
今は、手番も一つのパラメータにしちゃってるから、その差異は埋められない。
パラメーターとか評価関数の区分とか再考の余地があるんじゃないかと。
前向き枝刈するにしても、評価関数がフィックスしないとダメじゃないかと。
というわけで、しばらく評価関数方面で時間つぶしかなぁ。
341: 2015/10/26(月)09:44 ID:uWG/Yjb0(1) AAS
中盤探索に入るにあたって、評価関数の計算の試作をいろいろしているんだけど、
いまいちぱっとしない。１００回学習で１晩かかるし、３００回試行くらいしないと傾向が
見えてこないので、時間がかかる。
で、仕方ないので、裏で序盤定石を作り始めてしまった。
こちらも棋譜ベースで作ろうと考えている。
そこまで来た時に、データベースのどういうデータが使いたいのかが、逆にはっきりして
来て、今使ってる３６０万件棋譜の中のデータを選別しようかという方向に傾きつつあります。
が、やっつけで作って中身が思い出せないフォーマット変換のプログラムから直さなきゃならん。
開き直って、もう１度、データ変換から作り直そうかなと・・・
342: 310 2015/10/30(金)17:31 ID:uxyAnbEX(1) AAS
棋譜ベースで序盤２０手の定石DB作った。
定石DBは置換表をベースに作ったので、検索は速いけど、容量が大きい・・・。
簡単にαβで２０手探索してみた。
ネットで調べた定石集に載っていない手筋が出てきてしまった。むむむ。
５手目までエビ系で、しかも石差＋２で黒勝ち。棋譜が偏っているのかな。
棋譜は例の５０万棋譜計画の奴で１０手目、２０手目以降を訂正したというデータ。
明らかに壊れたデータが入っていたりと、何かと使いにくい箇所があるデータだけど、
定石DB作るにはこの量でも足りないのかも。
定石探索用の簡易版minMaxを作りながらつらつら考えていたら、終盤探索の
moveorderをもっと良くする方法を思いついた。評価関数の精度次第だけど。
新評価関数は、途中でうっかり仕込んだバグで遅延。ようやく原因が見つかって、３００回
試行まで来た。もうちょい収束させたいけど、テストに使える程度にはなってると思う。
343: 310 2015/11/08(日)00:32 ID:LMw8+3qF(1) AAS
moveorderを早くする方法というのは、事前に軽く探索した手順を保存し、その手順から
優先して探索するというもの。理論的にはscout missがゼロになる。
探索した手順を取り出す仕組みが必要になるので、その辺を改造しようと思ったところで、
悪い癖が出てしまいました。Cベースのソースを一旦棚上げして、C++ベースのクラスを
利用した形で一から作り直してしまいました。
moveorderの配列をvectorに変えたり、unordered_mapを見つけたので置換表に使って
みたり。置換表は、システム任せにして動的にメモリ確保に行かすと、探索ノードの減少
以上に速度低下して使えない。最初からある程度メモリ確保させようとしているんだけど、
いまいち設定がわからない。動的にメモリ確保するので、速度のバラツキも大きい。
そもそもC++は初めてなので、目的がオセロからC++というかunordered_mapの習得に
なりかかっていたので、一旦棚上げして、配列ベースの自作ハッシュの置換表に戻る
方向にしました。
とはいえ置換表を外してもnode/secが5kくらいしか出ていないので、実装が悪いところもありそう。
というわけで完全に寄り道しちゃってます。
344: 310 2015/11/12(木)16:56 ID:4hPfHY6k(1) AAS
ようやく、C++ベースの終盤探索（negaScout）が、Cベースより若干速くなりました。
・unordered_mapの速度のバラツキはデバッガー上限定。
実行ファイルでも多少ばらつくけど、メモリ効率＆メンテナンス性からunordered_mapを採用。
・探索した確定手順を返す方法の検討で苦戦。
negaScout＋置換表では原理的に無理と認識するのに時間を要しただけでしたorz
置換表無しnegaScoutかnegaMax＋置換表では、後者の方が高速。
・確定手順を元にmoveorderする改造の効果は限定的。
moveorderで先頭にする処理が重い模様。適用範囲を狭めて行くと１〜３手で同等の速度。
・ハッシュキー生成簡素化で若干速度アップ。
・その他、細かいスピードアップ。
確定手順の導入で５０％以上速度アップを目論んでいたのですが、無駄な努力でありました。
一応、与える確定手順の数はマクロ定義で可変できるようにしてあります。
評価関数も修正を加えたいので、データ変換部からまた作り直しです。
目標も無しに同じ事２回やるのは面倒だなぁ。
345(1): 310 2015/11/19(木)14:23 ID:W/V+CKXD(1) AAS
定石部分もクラス化が終わりました。クラスなんての扱うの初めてなので、もうちょっと
綺麗にできたかなと思う面もありますが、C++習得が目的ではないので。
終盤確定読みは０．０５秒刻みで速度アップ。FFO#40で２．３秒になりました。
今まで、速いプログラムでは３０手目くらいから勝敗判定を始めると言う記述を読んで、
なんて速いんだと思いつつ、何に使うんだろうと思っていましたが、ようやく腑に落ちました。
オセロというゲームは勝敗だけが問題で、勝つんなら２石差で十分。「少なくとも負けない
手」というなら、(-1,0)のNull windowで探索してβカットされた手を選べば良い。評価値は
不定（これより良いという値）でも負けない手であるという点では「確定」手順です。moveorder
が正確なら、極端に石差を減らす手も選ばない。これなら現状でも２５手ちょいくらいは行けそう。
ただ、これは勝勢の時の話で、敗勢の時の評価値は「これより悪い」という数字だし、
逆転は相手のミスに期待するしかなく、相手も同等のロジックのAI相手だと必敗となる。
結局定石段階で勝負がつく事になります。
今、定石DBは３０手を前提に組んでいますが、３１手目から勝敗判定ができるんなら、定石
を外れない限り中盤探索が不要になり、定石から外れた時にのみ中盤探索が必要になる。
つまり中盤探索は対PC戦では重要度が低く、定石が切れたら、即、終盤探索が始まる。
そもそも評価関数が良ければ、中盤もあまり深く探索する必要がないわけで。
深く読む意味って、なるべく評価が正確なステージを使いたいからなんだなぁと。
というわけで、次はそろそろ中盤探索です。Multi Prob Cutの英語論文を読まねばならぬ・・・。
346(1): 310 2015/11/21(土)00:05 ID:WWzrsUCT(1) AAS
定石DBを使って３０手目まで着手した盤面の予想石差が２で勝ち判定だったので、
試しに３１手目から勝敗判定をしてみました。
(-1,0)のNull windowで７分３０秒ほどで解けました。
（参考）勝ちと引き分けを区別するために(-1,1)で計算すると９分３０秒ほど。
探索ノード数がintではオーバーフローしてしまった・・・。
これから、３３〜４手目（残り２６〜７手）くらいで、１０秒程度で解けると予想されます。
勝勢ならこれで良いのですが、敗勢の時は、初段がβカットされないので１０倍程度
時間がかかる。そうすると、残り２５〜６手目くらいが勝敗読みの限度かなと。
もっと高速化が必要なのか。それとも、何か発想の転換ができるのか。
上下前次1-新書関写板覧索設栞歴
あと 656 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.022s