【オセロ,将棋】ボードゲーム【囲碁,War】

**名前は開発中のものです。** · 03/07/10 00:10

比較的地味なボードゲーム専用のスレが欲しくて立ててみました。

私はc言語で作ったデータベースを使って人間と対戦できる将棋かチェス
みたいなソフトを作りたいと思ってますが、グラフィックインターフェースの
作り方がわからなくてつっかえているレベルです。

**名前は開発中のものです。** · 2011/11/02(水) 12:02:01.50

>>246
駒二種類減らした４面体（占領、武士、巫女、怨霊）ではどうです？
実際に作ったら、とても手が出せない見積もりを頂きましたので、
没にして６面体に戻しましたけど。
パソコン上で動かすだけなら、負担は減るはずです。

あと駒数を減らすのはＯＫです。
２個づつから試して慣れるごとに駒数を増やしていってください。
盤面を「５×５」にして試してもいいと思います。

あと「段階的に簡単なもの」があれば、お願いします。
ただ、以上のことを段階的に教えるのはともかく、
各段階のをつくれとかいわれるのは無意味だし経費的にも無理ですね。

**名前は開発中のものです。** · 2011/11/04(金) 11:16:01.70

そういう問題じゃねぇって。遊ぶ側に苦労を押しつけんなって言ってんの。

テキストでルールとだいたいの遊び方が説明してあるだけの
面白さがわからないゲームで、しかも二人必要だから相手にもルールを覚えさせて
なおかつコマやらボードやらも用意しないといけない、なんて今じゃ誰も手を出さない。

面白さの中心部のみを抽出してすぐに覚えられるゲームにして
フラッシュですぐに遊べるようにして、しかもそこそこ強いCPUが相手してくれる
ぐらいじゃないと、今は客が寄り付かないの。

本気で遊んで欲しいなら、あちこちコピペ貼り付ける苦労をするんじゃなくて
プログラム覚えて自分で完成させるぐらいの苦労をしろ。
俺は自分が遊びたいゲームを作るためにプログラムを覚えた。

**名前は開発中のものです。** · 2011/11/05(土) 10:41:52.88

>>248
そうですね。
例えは悪いけど勇者の手を引いて代わりにモンスター倒して
魔王のところにつれてってて言うくらいの親切さがないと
ダメかもしれませんね。
でもそれで面白いのって感じはしますが。

**名前は開発中のものです。** · 2011/11/07(月) 19:51:57.88

だからそういう問題じゃねぇって。

>面白さの中心部のみを抽出してすぐに覚えられるゲームにして
>フラッシュですぐに遊べるようにして、しかもそこそこ強いCPUが相手してくれる

のは、やってるゲームはあるけど

>例えは悪いけど勇者の手を引いて代わりにモンスター倒して
>魔王のところにつれてってて言うくらいの親切さがないと

なんてゲームはないだろうが。例えが悪すぎる。

**名前は開発中のものです。** · 2011/11/07(月) 19:59:20.54

ゲーム中の楽しい苦労と、ゲーム始めるまでの煩わしい準備の苦労を
同一視するから変な例えになるんだよ。

例えるならハイキングのちょっとした山登りだ。
山のふもとに行くまでに普通の市街地や住宅地を何十キロも歩くのは苦痛。
だから山のふもとまで行くバスが必要だ。ってのが俺の言いたいこと。

お前はそれを「だったら頂上までバスで行けないとダメかもしれませんね」
って言うから話がおかしくなる。
山登りの途中は景色楽しみながらの苦労だからいいんだよ。

**名前は開発中のものです。** · 2011/11/09(水) 18:31:40.10

コネクト6（六目並べ）
http://www.connect6.org/

**名前は開発中のものです。** · 2011/11/10(木) 22:08:34.35

>>248
ご指摘ありがとう。

俺はおもちゃ屋で将棋やオセロの隣に並べるのが目標だったから、
プログラム組むとかそういうのは考えてなかった。
ていうか、そんな技術持ってないし。
でも、おっしゃることはごもっともです。
どこかプログラムを替わりにつくってくれるところを検索して探してみます。

**名前は開発中のものです。** · 2011/11/14(月) 19:50:52.02

ああ、そっちの方で目指してるのか。なるほど。
でも、それもかなりの茨の道だぞ。

おもちゃ屋で定番になって対戦思考ボードゲームなんて
ホントその将棋やオセロか囲碁ぐらいしかないし。
その他のゲームは出ては消えていくだけの存在だ。

目指すとしたら、ドイツボードゲームの系統かな。
基本的にはサイコロやシャッフルカードを使うものだけど
まれに運要素無しのガチ思考ゲーもあったりするし。
でもその場合、最初に覚える要素が凄く単純なものしか残れないし、ウケない。

**名前は開発中のものです。** · 2011/11/14(月) 20:00:08.65

あと、プログラムを替わりにってのは、金出さないとまず無理だと思う。
ゲームを本気で広めたいなら、プログラムしてでも自分で作るべき。
それが出来ないなら、その程度の本気度でその程度のゲームだったって事だ。

**名前は開発中のものです。** · 2012/07/10(火) 15:38:41.19

将棋プログラムできるサイトない？

**名前は開発中のものです。** · 2012/07/10(火) 15:40:08.27

過疎ってるし質問とりやめます

**通りすがりの妖術僧** · 2012/07/27(金) 16:18:03.62

以下のような本もあるしサイトも結構ありますね。

アマゾンで取扱い
「コンピュータ将棋のアルゴリズム―最強アルゴリズムの探求とプログラミング-I・O-BOOKS-池-泰弘」

**名前は開発中のものです。** · 2012/10/17(水) 06:16:37.40

将棋

**名前は開発中のものです。** · 2012/10/17(水) 07:42:20.83

>>258
かなり古いが森田和郎が書いたコンピュータ将棋の本もあるな
「もしかしたら世界初のコンピュータ将棋の本」らしいから、今からしたらかなり初歩的なことしか書かれてないが

**難しいね** · 2013/01/24(木) 19:30:18.98

最近覚えたけど、ぜんぜん勝てない

**名前は開発中のものです。** · 2013/02/06(水) 18:16:09.27

将棋は頭が良くないと強くなれないのか
http://gogono.net/archives/52047142.html

**名前は開発中のものです。** · 2013/03/06(水) 12:40:47.06

http://www.geocities.jp/meisaku_asobu/MageKnightPDF.html
スルー・ジ・エイジ
剣と魔法の国

**名前は開発中のものです。** · 2013/04/23(火) 07:05:31.51

>>255
>あと、プログラムを替わりにってのは、金出さないとまず無理だと思う。

金を出さないなら、企画ごとプログラム担当に乗っ取られても文句言えないよな

◆taka1B7CEQ · 2013/04/26(金) 18:31:25.31

▽持ち駒：
┌──┐
│▽王│一最終手
├──┤ 　には
│▽歩│二 ★☆を
├──┤ 　付けて
│▲歩│三下さい
├──┤
│▲王│四
└──┘
▲持ち駒：

**名前は開発中のものです。** · 2013/05/11(土) 22:28:05.03

友達と将棋盤に、自分は将棋、相手はチェスを並べて戦っている
（チェスは1列足りないので、キングを中央にくるように、端列は開ける）

取った駒は再利用不可で、昇格は昇格する駒に応じて、チェスは相手の最前線、将棋は相手の3段目で昇格

チェス側が強くて勝てないよ・・・

**名前は開発中のものです。** · 2013/05/12(日) 13:24:34.46

将棋側は、あまり動かずに、金・銀を密に連携させて防御陣形をとるべし

チェス側は、ポーン以外はすべて大駒だから、機動力が大きいが、多方向に利くのはクイーンとキングのみだから、そこを狙うべし
クイーンもキングも取られるわけにはいかないから、玉と金2枚で支援して銀2枚を捨てられる将棋側は有利

チェス側はポーンで斜めスクラムを組んで防御前線を張れるが、正面の駒を取れないのが痛い

**名前は開発中のものです。** · 2013/05/13(月) 17:58:19.66

Zillions of Gamesをインストールすれば、自作ゲームがすぐに作れるよ
http://www.zillions-of-games.com/

Zillions Rules File (ZRF)というルールファイルを、テキストエディタで構文に従って書き換えるだけ
http://www.nakajim.net/index.php?%E3%82%A2%E3%83%96%E3%82%B9%E3%83%88%E3%83%A9%E3%82%AF%E3%83%88%E3%82%B2%E3%83%BC%E3%83%A0%E3%81%A8%E3%82%B3%E3%83%B3%E3%83%94%E3%83%A5%E3%83%BC%E3%82%BF%E3%83%BC

もとのゲームファイルの修正で済むようなもの（駒数変更，駒の移動範囲の変更，盤の升目数の変更など）はとても簡単
他の人がアレンジしたボードゲームのZRFも、ダウンロードして参照すると使用可能
http://www.zillions-of-games.com/games/index.html

**名前は開発中のものです。** · 2013/05/18(土) 09:32:23.57

将棋対チェスのゲームって売ってるのかな？

**名前は開発中のものです。** · 2013/05/18(土) 23:16:41.04

わざわざそれだけのために買うやつなんていないだろ

**名前は開発中のものです。** · 2013/05/20(月) 20:20:47.74

ZoGの中将棋AIは最強らしいから、やってみたいな
有料だから残念か

将棋対チェスは、ggると調整されたルールが出てくる

**名前は開発中のものです。** · 2013/05/24(金) 18:09:30.06

>>271
調整ルールの詳細希望！

◆SHOGI//OTA · 2013/05/24(金) 18:48:56.85

チェス側も６枚以上になると駒打てるってルールだったかな
将棋が日本、チェスがアメリカか

**名前は開発中のものです。** · 2013/05/24(金) 22:15:10.72

>>265
▲ニ歩
△同玉
▲三歩打
△一玉
▲ニ歩
△同玉
▲三王
まで

**名前は開発中のものです。** · 2013/05/24(金) 23:20:25.94

６手にて変化の余地なくｽﾃｨｰﾙﾒｲﾄ負け。

**名前は開発中のものです。** · 2013/05/26(日) 02:43:56.90

>>273
サンクスです

確かに大駒中心のチェス側は、高い機動力を生かして序盤は優勢だけど、
終盤は取り合いになると、守備範囲が狭いチェス側は守りきれなくて死ぬ

ある程度、駒をとってから打てるようになるわけね・・・
将棋側はチェス駒を打つわけだけど、チェス駒はナイト以外は向きが分かりにくいから、相手に使用されると嫌だな

◆SHOGI//OTA · 2013/05/26(日) 07:32:03.70

リアでやる時は色反転させるからおｋ
これでもチェス側が勝つとなれば、一気に決める必要があったりして。（ｗ
将棋が金銀で固めてしまうと手がでないヨ。。。

将棋対シャンチーもあるかな

**名前は開発中のものです。** · 2013/05/26(日) 12:06:35.03

米韓戦：チャンギ（韓国将棋） VS チェスなら、あるよ
http://www.zillions-of-games.com/cgi-bin/zilligames/submissions.cgi/55557?do=show;id=553

日中戦：シャンチー VS 将棋とか、誰か作ってくれないかな・・・

4人プレイで、チェス VS 将棋 VS シャンチー VS チャンギのバトルロワイヤルとか面白そう

**名前は開発中のものです。** · 2013/05/26(日) 12:11:22.32

日米戦：チェス VS 将棋は、すでにHSPで専用ソフトが存在していてビックリ！
http://hsp.tv/contest2010/entry.php?id=23

ルールをもっと可変式にして欲しいな・・・
昇格線の位置、駒の再利用の有無、チェス側が空ける列の変更とか・・・

**名前は開発中のものです。** · 2013/05/26(日) 20:14:44.85

>>278は、ソフト購入しないと無理？

シャンチーとかはちょい特殊なので、
同じ盤でやるのはムズイか

**名前は開発中のものです。** · 2013/05/27(月) 19:39:26.72

まずはHPでソフト（体験版：無料）をダウンロード
これで、デフォルトの48種類のゲームが可能（将棋，チェス，チャンギ，シャンチー，マックルックなど）
使用期限はないけど、機能制限（自作ルールが使用不能）あり

次に、Help＞Unlock Full Versionを開いて、NameとCodeに数字を入力すると、機能制限が解除されるよ
これで、OpenRuleGamesから参照することで、ダウンロードサイトの亜種ゲームや変則ゲームも使用可能になる

間違っても、「Zillions of Games」，「keycode」，「serial number」，「passward」などでググってはいかん！
（倫理的にね・・・）

**名前は開発中のものです。** · 2013/05/27(月) 19:44:10.89

>277
そうか、将棋側は、使っていない相手（チェス側と逆の色）のチェス駒を使えば良いのか・・・

チェスの駒は、打ち詰めたり、合い駒を打ったりするのに向いていない・・・
でも、チェス側が手に入れるのは将棋側の駒だから良いのか

相手に取られたチェス駒を、さらに取り返して打てるとなると、チェス側はチェス駒を打てるわけで、新感覚だな

**名前は開発中のものです。** · 2013/05/28(火) 18:33:34.08

>>278
チェス側はナイトが1個足りなくないかい？
ナイトとルークの位置が逆なのも意味があるのかな

チャンギとシャンチーは似てるから、シャンチー VS チェスなら、すぐにできそう

**名前は開発中のものです。** · 2013/05/31(金) 23:01:31.34

3Dチェスのソフトを作るスレに乗っ取り！

**名前は開発中のものです。** · 2013/06/07(金) 06:49:37.26

>>281
ありが糖

中将棋やってみるよ＾＾
調べてみると、摩訶大将棋まであるな

**名前は開発中のものです。** · 2013/06/08(土) 19:23:27.40

立体チェスとか、円形チェスとか、六角形チェスとか、チェス系はバリエーションがスゴイ！

◆ZSCoFl63NY · 2013/06/09(日) 17:15:43.33

他スレでなかなかレスがつかずにこちらにカキコしました。

ループオセロを作りました。exeファイルなどはトラブル防止のため、あえて添付していません。
動作環境はWindowsです。Cコンパイラがない方は、同梱のreadme.txtを参照してください。
コンパイル方法はreadme.txtに全て記述してあります。
↓にうｐしてあります。
http://soft186.e-whs.jp/cgi-bin/up2/img/55.zip

少々強引なコーディングですが、何とか形になりました。
率直な感想を聞きたいので、どうかダウンロード＆コンパイル＆プレイしてやって下さい。

私のスペックですが、Ｃ／Ｃ＋＋がそこそこ使えて、フリーソフトを公開した実績がありますが
プログラマとしての実務経験はほぼゼロです。

**名前は開発中のものです。** · 2013/06/13(木) 18:55:25.55

なんかドラクエの世界地図みたいですね
東西ループ＋南北ループ
もはや角や端は意味を持たない
最後までどんでん返しがあり得るが、盤のマスは有限と
なかなか面白いのでは？
メール希望者には、exeで送っても良いのでは？

できれば、その技術で、「チェスVS将棋」のインターフェイスを作って欲しい
AIなしの対人対戦専用ソフトで

**名前は開発中のものです。** · 2013/06/13(木) 19:04:52.78

ドーナツオセロか

**名前は開発中のものです。** · 2013/06/14(金) 17:56:33.48

正確には、平坦トーラス（曲率0の円環円筒）です

**名前は開発中のものです。** · 2013/06/15(土) 21:26:29.87

>>287
がんばれ！！

**名前は開発中のものです。** · 2013/06/16(日) 12:19:37.51

縦列が一周ごとに下にずれたり
横列が一周ごとに右にずれたりすると
更にややこしくなる。

ていうか残り１枚から大逆転が可能になる

**名前は開発中のものです。** · 2013/06/16(日) 12:26:37.95

赤・白・黒の3色オセロは既出？

**名前は開発中のものです。** · 2013/06/19(水) 00:32:19.46

４色でやってるTV番組があるぜ

**名前は開発中のものです。** · 2013/06/20(木) 19:25:37.41

＞＞294
何色？
赤・青・白・黒？？

**名前は開発中のものです。** · 2013/06/25(火) 20:10:45.63

ほ

**名前は開発中のものです。** · 2013/06/30(日) 12:35:57.68

リアルタイムストラテジー型のチェスとか、HP制の将棋とか、おもしろいかも？

**名前は開発中のものです。** · 2013/06/30(日) 20:09:35.38

その昔、バトルチェスってのがあってな・・・

**名前は開発中のものです。** · 2013/07/01(月) NY:AN:NY.AN

Battle chessでggると、駒を１手で１回ずつ全部動かせるらしい

**名前は開発中のものです。** · 2013/07/02(火) NY:AN:NY.AN

FFみたいなアクティブタイムバトル（ATB）制とか、
タクティクス・オウガみたいなウエイトターン（WT）制は？

**名前は開発中のものです。** · 2013/07/03(水) NY:AN:NY.AN

ハンターハンターの軍棋をゲーム化するとかね。
つうか軍棋って同じ名前で実在するんだな。日本にも軍人将棋ってのがあるが。
ここで色々案も挙がってるが、すでにPCもない時代からこういう考えはあったわけだ。

**名前は開発中のものです。** · 2013/07/07(日) NY:AN:NY.AN

軍蟻は良いかも！
著作権が難しいが・・・

軍人将棋はバリエーションとローカルルールがありすぎて対応が大変
ZoGにも欲しいな
西洋軍人将棋（ストラテゴ）は、PCでも割と見かけるが

**名前は開発中のものです。** · 2013/07/07(日) NY:AN:NY.AN

ハンターのあれってちゃっとルール公開されてたの？
コマが３つまで重ねられるって事しか解んないわｗ

**名前は開発中のものです。** · 2013/07/07(日) NY:AN:NY.AN

ルールなんて自分でこさえちゃえばいいよ。
コマを重ねるってのは、要するに馬にのせたり方天画戟といった装備だったり
名声や決意・覚悟といった精神的なものの加点要素なんじゃないのか？
あるいは倒れた仲間を回収して回復ポイントまで運べるとか。逆に補給物資を運んでいるか。

将棋やチェスなら、味方のコマと重なると2倍の能力になり、一回とられても相打ちで敵も倒せて、自分はそこに残れる、的なシステム。

**名前は開発中のものです。** · 2013/07/07(日) NY:AN:NY.AN

作りたい奴はすでに作り始めてたりする

ハンターハンターに出てきた架空のゲーム「軍儀」
http://kohada.2ch.net/test/read.cgi/cgame/1119733877/l50

**名前は開発中のものです。** · 2013/07/08(月) NY:AN:NY.AN

なるほど、高さ＝三次元的なゲームだったのか。
二段や三段のコマは一段のコマには抜けれず壁の役割になれる。
壁構築で地形みたいな要素にもなる感じかな？

**名前は開発中のものです。** · 2013/07/09(火) NY:AN:NY.AN

高さを考慮したSLGといえば、タクティクスオウガ系のゲーム画面（盤面）になりそう・・・

**名前は開発中のものです。** · 2013/08/03(土) NY:AN:NY.AN

age

**名前は開発中のものです。** · 2014/09/08(月) 16:59:53.68

教京サーバアビエ無戸籍交際薬剤消毒介護職利権ローション羽田帝国上層部24時間パトロール義務上野飲み会マックさむらいニューヨーク森林火災チェック問題ヤーフォー確定申告不足ラーメンスーパーポイントdビデオデッキ破壊タイピングGTX860MIGOZ

教京サーバアビエ無戸籍交際薬剤消毒介護職利権ローション羽田帝国上層部24時間パトロール義務上野飲み会マックさむらいニューヨーク森林火災グリーにんにく牡丹黒家宝ラーメン

教京サーバアビエ無戸籍交際薬剤消毒介護職利権ローション羽田帝国上昇部24時間パトロール義務セコム強盗マックさむらいニューヨーク森林火災グリーにんにく牡丹黒家宝ラーメン
築地TPP偏食中国人勧誘マナー憤怒北京オリンピックパブ立橋フロアWHO経済制裁代協議会飲み食い代官僚日テレ漏洩ボーリングITC問題調査福岡駐車近代道廃人画税幕張銀行ググール無断決裁広告料寒孫ゼリー失調栄養士指的フィルム不毛ハンバーグースラーメン

糞箱弐個弐個沖縄ランド近年ペット原発難民船頭100万円コミックコラムシフト廃品鉄工業プラチナ小スモ再販問題WHO光金アナ雪エネルギーソーシャル決裁ニッカン奮闘鬼記者サービスカ米ラマン露店捜査キセルストアアイダホ会長農家不動産工場感激息子

**名前は開発中のものです。** · 2015/08/18(火) 16:59:55.72

どなたか教えていただけますか？

最近、オセロAIのプログラミングをCで行っています。
今は、探索ロジックの勉強のため、終盤の完全読みを作っています。
置換表付negaMax、置換表付PVSは通常の探索ではきちんと動作しています。

現在MTD(ｆ）にとりかかりました。MTD(f)では、ドライバは擬似コードそのまま。
テスト関数は置換表付negaMaxを流用していますが、そのままだとFail-LowとminMax値
の区別がつかずに、Fail-Lowの指し手を返してしまうので、初段のみαを-1する事で、
内部的に区別できるようにしています。

動作確認にいくつかテストケースでテストしましたが、FFO#40の時におかしな事がおきます。
（FFO：http://www.radagast.se/othello/ffotest.html）

問題）本来の評価値は+38（A2B1C1…）なのに、+30が返る。

以下、判明している状況です。
１）置換表を使用せずにMTD(ｆ）を動作させる。　－＞正解
２）単体でNull Window Searchを行う。　　　　　　－＞正解
３）置換表を使用してMTD(f)を動作させる。　　　－＞少なくともFFO#40では誤答する
４）FFO#40で失敗する条件は、ｆにminMAX値より幾分小さい値（黒+30未満）を設定したとき。
５）negaMax初段でαを-1するロジックを入れなくても、同じ事になります。

デバッグで確認したところ、Fail-Highになるべき条件（黒+30や黒+36の時）で、下限値を
返しています。同一条件で、下限をさらに-1してテストしたところ、α<g<βである事が確認
できましたので、minMax値として間違った値が返っていることになります。

どうも原因は置換表にあり、Null Window Searchの中で、何回も再利用していることに
あるように思います。とはいえ、MTD(f)といえば置換法を再利用する事が前提です。
どこかに誤りがあるのではないかと思います。

同じような問題に遭遇した人はいますか？

**310** · 2015/08/18(火) 17:06:51.32

ちなみに、置換表のキーは、盤面と手番です。

ハッシュ値を使用し、衝突した場合は、チェーンで下につなげています。
今のところ、メモリーの上限等は設定しておらず、領域も足りています。

**名前は開発中のものです。** · 2015/08/18(火) 21:27:38.25

正気か？

**310** · 2015/08/18(火) 23:21:46.36

何がですか？

**名前は開発中のものです。** · 2015/08/18(火) 23:27:30.51

その質問に答えられる人間が２ｃｈにいると？

**310** · 2015/08/19(水) 09:33:45.34

いなければ仕方ないですね。

テスト関数を置換表付negascoutにしたら、ちゃんと答えが返ってくるようになりました。
けど、なんか気持ち悪い。置換表の扱い方は一緒なので、たまたま上手く行ってるだけ
ではないかと思います。むむむ。

MTD(f)にこだわり続けてもあんまり意味が無いので、評価関数づくりに入ります。

３層パーセプトロン型にするか、普通の線形回帰にするか。
パーセプトロンタイプは、パターン学習のタイプを作ってみましたが、学習データ３４０万
棋譜に対して、１回回すのに３日がかりという状態で、検証サイクルが回しづらい状況な
ので、簡略化をするか、線形回帰を試すか思案中です。最終的には、両方作って対戦
させてみるかと思っています。いつになる事やら。

**310** · 2015/08/24(月) 09:51:00.08

BITBOARDで確定石をそこそこ正確に求める方法を考えました。
思いっきり脱線中ｗ

ただ、斜め方向に「列すべてに石が置かれている」状態を検出する方法と、
その時に、斜め方向の列すべてに確定ビット（仮）を建てる良い方法が見つ
からずに、斜め方向のAND用の定数配列を用意してループを１５回回してる。

縦横は、分割統治でそこそこなロジックになったんだけど。

４５度回転を使っても、そんなに高速化できそうにないなぁ。

もちろん、完璧な確定石ではありません。
拾った石は確実に確定石ですが、確定石なのに拾えない石が若干あります。

**310** · 2015/09/02(水) 11:43:34.50

ぬぬぬ。パターンによる線形回帰の石差予想。
最急降下法は収束してるんだけど平均２乗誤差が４８０とかになる。
１σでいうと１局面あたり２２石（黒石の数では１１石）もの誤差。
これでは使い物にならない。

ステージ分割しているんだけど、ステージが進んでも誤差はほぼ一緒。
ウェイトがオールゼロでも似たような数字になるレベル。
テストデータで局面評価させると、それなりに石差は計算しているっぽいが、
最善手で終局まで打ったデータ入れるとステージによって評価値が全く違う。

初期値をゼロからスタートすると、この辺なんだけど、１とかからスタートすると
もっと誤差が大きいところで収束してしまう。初期値を乱数にしたら、更に大きな
誤差で収束してしまう。

ローカルミニマムに捕まってるのかなぁ。

いくつかミスは見つけたけど、本質的な場所じゃないので、結果も変わらず。
むむむむ。

**名前は開発中のものです。** · 2015/09/02(水) 16:33:21.80

正規化をミスってる

**310** · 2015/09/02(水) 21:57:59.44

正規化というと、thellさんのlearning.pdfで言うところの、αの設定ですか？

当初はmin（β/100,β/Nj）の正規化型で作ってましたが、上手くいかないので
収束を早めるのは後回にして、今は単純にステージ毎の局面データ件数α=β/Nの
形にしてます。

が、発散を避けようとすると、βをあまりに小さくしなければならないのが、なんか変な
気がしています。今は10の-7～-8乗くらいの値です。やっぱり変ですよね。

最急降下法のコードどこか間違えてるんだろうなぁ。

**名前は開発中のものです。** · 2015/09/03(木) 04:25:48.28

でもオセロだったら最終数手で１１石くらいひっくり返ってぶれるのは普通じゃない？

**名前は開発中のものです。** · 2015/09/03(木) 04:36:35.33

あ、オセロのＡＩにはぜんぜん詳しくないんだけど
対局を見てたらクルクル石差が入れ替わるので
読み切らずに局面から石差を判断すると
どうなるんかなと思って

**310** · 2015/09/03(木) 10:19:29.05

色々と失礼しました。

もう一度、よーく上記pdfを読み返していたところ、原因らしきものが見つかりました。
記載にあいまいというか、ちょっとおかしいところがあって、式の変形をしっかり追って
確認すれば良かったのですが、思い込みで解釈をして変な計算をしていました。

そこをとりあえずざっと修正したところ、遅々としつつも収束に向かっている模様ですが、
まだまだ完全ではないようです。ある程度二乗誤差が減ったところで、また増え始めたり
しています。正規化も試したけど、やはり同じ。

もう少し、検討してみます。

**310** · 2015/09/03(木) 10:38:17.33

>>320
もともとひっくり返しあった後の終局を予測するのが目的なので、教師データは最終局面
の石差です。盤面の特徴（パターン）から、最終石差を予想するための重回帰計算なので、
その時点の石数は、説明変数に入れてません。なので、パターンの選択が適切なら、
最善手の応酬において１手毎にどれだけ石数が入れ替わろうと、影響を受けずに、
二乗誤差が終局に近づくほど減っていくと予想されます。
というか、そうなるように説明変数であるところのパターンを模索していくと理解しています。

手元にあるwzebraなんかは、評価値と称して最終石差予想が表示されているのですが、
やはり、ある程度の誤差を含みつつも、大きくぶれているようには見えません。

評価関数の使い道を考えると、実は絶対値はそれほど重要ではありません。
中盤探索のｎ手読みの時の盤面評価と、ムーブオーダリングに使うので、ある局面から
派生したｎ手先の局面における相対的な関係が保たれていればOKです。
また、MTD(f)法などを使う時の、ｆの初期値設定にも使います。この時は絶対値で正確な
方が良いはずですが、外れはすぐにカットされて次に行くので、トータルの時間に対する
影響は小さいように感じます。

とはいえ、相対的な関係が保たれているのかをチェックするのは難しいですから、
結局のところ出来上がった評価関数の評価は、教師データとの二乗誤差の小ささに
するしかないかなと。

**310** · 2015/09/07(月) 01:11:39.28

収束しかかった二乗誤差がまた増え始める原因はまだわかりません。
増え始めるまでは収束方向には向かっているのは確かなのでβの初期設定を
いって誤魔化す方向で。最急降下法ってこんなものなのかなぁ。

一通り納得したので、パターンをLogistelloと同一のものにまで拡充してスムージングも
入れてみましたが、新たなバグを仕込んでしまった模様で、一部計算がぐちゃぐちゃorz
バグ探しの旅に出ます。

裏で、Solverの速度アップを検討。
CountBitとPOPCountを組み込み関数にしてみました。FFO#40で30%ほど改善。
続いてFlip関数を６４個のポインタ関数にしてみましたが、時間はほぼ変わらず。
ポインタ関数内の処理が非効率なのか。

Flipのデバッグ中に確定石計算でバグっぽいものを見つけましたが、回帰が落ち着く
まで見なかった事にします。

**名前は開発中のものです。** · 2015/09/10(木) 17:45:51.81

将棋の全駒にユニークなIDを振り、局面を将棋盤に見立てたkoma[9,9]にIDを入れることで表現しようと思っています
その場合、駒のIDから座標を取得するいい方法ってないんでしょうか？
IF文、Case文のオンパレードになってしまうのは仕方ないのでしょうか・・・・

言語C#

**名前は開発中のものです。** · 2015/09/13(日) 16:22:10.24

駒側にも座標を持っちゃえば？

**310** · 2015/09/14(月) 09:33:29.38

線形回帰で相変わらず時間食ってます。
一応、バグらしきものはそれなりに解消されましたが、やはりいかんせん収束が遅い。
一晩かけて５０～１００試行して、途中で止めてやり直しなんてのやってる間に１週間は
あっという間に経ってしまうものです。まだ誤差が大きい。１０００回程度回して、どこまで
収束するか見てみようかなと。またぞろ３層パーセプトロンが気になる今日この頃。

確定石計算もバグ取りはできたと思いますが、その分計算が１．５倍ほどに膨れてしまい
ました。しばらく思考実験していたら、確定石なのに確定していると評価できない確実な
パターンも思いついてしまって、どうせその程度のものなら重い確定石計算しないで普通
に準確定石程度にしとくのが良いかと悩み中。

Solverの速度アップですが、前からやろうと思っていた事を少しづつやっていますが、
統計とってきちんとやっていないので１０％くらいの差だと良くわからない状況です。
コードのメンテナンス性が下がるのがネック。negaMAXが思いの他高速化してしまい
ましたが、MTD(ｆ）が低速化しているかも（謎）。

それなりに評価関数が動きだしたので、置換表２枚にして反復深化も試してますが、
信じられないくらい劇遅状態です。これ本当にコストに見合うのかなぁ。評価関数の
計算が、というか、その中の確定石計算が重いんだと思うけど・・・。

**310** · 2015/09/14(月) 17:35:45.53

反復深化が劇遅なのは、使い方を誤っていました。
リーフのところまで使うとコストアップなのは考えれば当然でした。
まあ、おバカなバグもありましたが。

negaMaxに対して反復深化を試すと、１割程度の高速化となりましたが、
negaScoutに対してやると多少低速化して、negaMaxの反復深化と変わらない速度に。
scout missが３倍近く増えているので、評価関数の精度があまり良くないためかなと。
move orderには、通常はmobilityとコーナー着手を使用しているのですが、これ、
何故か（少なくともFFO#40に対しては）scout missが恐ろしく少ないのです・・・。

MTD(f)が遅いのも、最初に設定するfを評価関数の値にして、それが結構外れで、
探索範囲が広がったのが原因です。scout missと同様に、結局のところ、途中で評価関数
を求めるタイプの高速化は、評価関数の精度次第という当たり前の結果に。

評価関数入れるとノード探索時間が1/10になるので、やはり評価関数用の確定石計算は
準確定石にレベルダウンしようかと思います。中盤AIでの話ですが。

今FFO#40が９秒台なので、あと３～５倍高速化したい。

**名前は開発中のものです。** · 2015/09/14(月) 21:42:06.86

その情熱がうらやましい

**310** · 2015/09/15(火) 20:18:36.71

準確定石の計算って実は思ったよりコストフルかもと気づいてしまい、
急きょコーディングして比較してみる事にしました。

releaseモードだと、自分の計算方法では跡形も残らないため、時間計測不可能。
debugモードでも、数十倍速いと言う結果になりましたので、今の確定石計算ロジック
は、悪いモノではないと自分に言い聞かせる事にしました。

それより、回帰の学習で、少しずつ少しずつ２５０回くらいまで学習進めていたのですが、
バグを見つけてしまい、またやり直しです。むむむ。しかも、なおした事で計算時間が
２～３倍になってしまうという。

**名前は開発中のものです。** · 2015/09/19(土) 00:46:12.58

回帰がやっとまともっぽいところまで収束するようになりました。
今、２５０回学習で、最終ステージが１σ＝７．５程度です。
このペースだと、もっと学習させても、たいして変わらない気もしますが、
もう少し学習を進めてみようかと思います。

この評価関数を元に、反復深化＋MTDF+negaScoutなsolverを動かして
FFO#40で８秒程度になります。インライン関数化とか、最終２手展開とか
やるべき事はある程度やっちゃったので、自分の力だとこの辺が限度かも。

**310** · 2015/09/22(火) 22:15:30.40

回帰は地道に学習中。もう少しやってみるって感じだけど、収束状態の誤差が大きいのは
ステージ分割でオリジナルな変な事をしているからじゃないかと気になりだした。
あと数百回学習を回したら、通常のステージ分割版も作ってみるかなと。

色々いじってるうちに、FFO#40が６．２秒まで来た。何が良かったのか良くわからない。
反復深化をターゲットに改良しているんだけど、negaScoutも同じ時間。

FFO#41を試したら、反復深化で４５秒弱、negaScoutで３０秒弱という結果に。
探索ノード数がすごい事になってるので、反復深化のmoveorderのどこかがおかしい
気がしている。

**310** · 2015/09/25(金) 16:54:56.15

回帰のステージ分割というかスムージングを、ネット上でノウハウ公開されてるみなさん
と同じようにしたら、１σで６を切ってきた。やっぱ、スムージングやり過ぎて、精度が
落ちていたのね。同一ステージ内でも値がばらついているので本当に必要なのか、
気になるので、落ち着いたら両方試そうかと。先に方向性見ちゃったから本来とは
逆順になっちゃうけど。

色々頑張ったら、FFO#40が５．１秒、#41が２０秒、#42が１８秒となりました。
ソースとにらめっこしてれば、ネタはそれなりに出てくるものだなぁと。

しかし、１０年前のCPU使ってるThellにようやく勝てた程度。
Zebraの速さは何なんだと。こちらはcore i7だというのに。

目下の悩みは、_mm_popcnt_u64とBitScanFoward64が使えずに、それぞれ32ビット版を
使っている事。外部依存のところで関数の存在は確認しているんだけど、「そんな名前ない」
と出てくる。Cは趣味のAVRで小さいプログラムしか作った事がなかったけど、VC++くらい
巨大になると、どーもよーわからん。

**310** · 2015/10/04(日) 01:12:59.97

色々やって、FFO#40でnegaScoutで３．４秒まで来ました。

反復深化は異なる方法で２種類作ってみたけど、FFO#40程度の深さだとnegaScoutとの
差が出てこない。２２手とか２４手とかまで行くと、差が出てくるように感じるけど、後回し。

どうしても気になって、Zebraのソース解説（日本語）を見つけて、そこに出てるソースを
見ました。自分なりにロジック面で工夫した事はほぼ同じ事をやっている。流石。
あとマクロを多用してる。僕はインライン指定でコンパイラ任せ。
マクロにするとデバッグが極端に大変になるので、マクロ化するのは最後。

そしてaspiration windowと称しているWindowの取り方が独特で、ここに高速化の
秘密があるとみた。早速真似してみると、また>>310のような問題が・・・
今回は前より理解が進んでいたため、２点修正して解消。
副次的に>>310の問題も、直ったと思う。

が、もう一つ答えを間違うケースを見つけてしまった。
今まではルートノードに問題があったけど、こちらはもっと下位ノードで戻り値がコンタミ
してる感じ。デバッグが難しく、重症っぽい。むむむ。

**310** · 2015/10/07(水) 17:10:37.74

デバッグで試しに変えた箇所を戻し忘れたりして、二次災害三次災害を出して、
相当混乱したけど、やっぱり境界問題だった。これ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で初段の
評価順見てると、まだまだなので、何か別の発想で並び替えが必要な感じ。

評価関数は１０００回くらい回してようやく良い感じになってきたけど、まだ収束しては
いない感じ。学習係数はもっと大胆に大きくしても良かったかな。ここまでやると、
スムージング無しを試すのが億劫になってくる。

反復深化は、ソースのメンテが追い付いていないので、一回破棄。

**310** · 2015/10/12(月) 23:43:49.17

色々やってるけど、FFO#40では速度向上はほとんどなし。
置換表のサイズが見えて来たので、１件ごとにmallocしていたのを、配列にして一括で
領域確保するように変更（当初の形）したら、速度のバラツキがだいぶ減ったように思う。
NPSが変動すると、何か悪いことしかたと悩んでしまい、修正して二次災害を起こすので
地味に大事かな。

FFO#43は多少高速化してて、パラメータ最適化するとMTD(f)で１２秒台くらい。置換表
適用範囲の指定を下（葉）からしていたのを、上（ルート）からに変えた。あと、MTD(ｆ）
などでは何回も置換表を読むので、２回目からはmoveorderに置換表の評価を使うよう
にした。

BITBOARDだと開放度の計算が簡単だという事に気づいて、静的評価関数に使ってみた
けど、現在使用中の次手mobility＋αの順序より劣る感じ。＋αが角とか×とかなので、
序盤から中盤用なのかなぁ。

negaScoutに加えた修正をnegaMaxに適用していたら、negaMaxがおかしくなった。
直して計測したらFFO#40が４０秒程度に。冷静に考えると、これが常識的な速度だと思う。
前回の５秒台がどこから出て来たのか、今となってはわからない。前段の＋α箇所も
結構変えていて、negaMaxはmoveorderで露骨にノードが増減するので、奇跡的な順序
が実現できていたのか。それともバグやオペミス勘違いかも。

そろそろ本格的にネタ切れ。この辺が限界かなぁ。
後回しにしていた修正箇所を直して綺麗になったら、中盤に行くかな。

**310** · 2015/10/14(水) 23:51:46.51

negaMaxはmoveorderの修正漏れでバグってて、直したらやはりFFO#40で５．４秒でした。

MTD(ｆ）は２．４秒でzebra並になったけど、#41以後は３～４倍時間がかかる。
その差は探索ノード数に比例してる。前向き枝刈使うわけにはいかないし、#41以降の
差を詰めるにはmoveorderしかないと思う。

とはいえ主だった事は一通り試してしまった。むむむ。

偶数理論で思いついた方法が純粋に面白そうなので組んでみる。
想定では、速度が結構遅くなるはずなんだけど、まあ面白そうという事で。

**310** · 2015/10/16(金) 10:24:07.38

偶数理論の関数は思いのほか軽くできて、オーバーヘッドの心配が少ないです。

BITBOARDの空マスを、囲まれて独立している塊ごとに分離してBITBOARD配列にして
返す関数を作りました。これをPOPCountで数えて着手した場所が偶数空エリアなのか
奇数空エリアなのかを判定します。

最初にテストしたFFO#43のMTD(ｆ）でいきなり３０％近く高速化して「やった！」と思った
のもつかの間。実はミスで判定を逆にしてまして、偶数マスに打って奇数を相手に渡すと
加点になってました。で、いろいろテストした結果、最初にやったケースではたまたま
良かっただけみたい。例えばnegaScoutやnegaMaxでテストすると、係数変えたり判定
方法に工夫を加えたりいろいろしてみても、何をやっても探索ノードが増えてしまう。

自分はオセロ弱いので、必勝法みたいに言われているものが、アバウト的に最善手に
近い手を選んでくれるんなら、並び順の優先順位計算に、あるウェイトで入れてみようか
的に考えるだけでした。意味とか深く考えるよりやってみるという感じでした。が、最後に
残った２つの空所が偶数と奇数とかの例ならわかりやすいけど、空所が４～５か所ある
ような状況で偶数理論を当てはめようというのが間違いなのかなぁと。

あと、薄々思っているんだけど、テストケースとしてFFOは良くないんじゃないかと（汗
FFOに最適化してると、もっと出現頻度が高い例題でより高速化できる可能性を放棄
しちゃっている事にならないかと。

**310** · 2015/10/17(土) 09:29:41.90

最終２手高速化したあたりから、ノード数が過小になっていたので、それを直しました。
自分のと比較すればよいかと思って放置していましたが、そろそろちゃんと比較しようかなと。
結果、探索ノードが思っていた以上に多かった事、そしてNPSは９～１１K出てるので、
NPSを落としてノード削減する余地があるという結果に。

あまりテストしていなかったFFO#41と42ではzebra方式と呼んでいた（後述）方法が、自分の
中では最速で、MTD(ｆ）の結果があまり思わしくない事も。MTD(ｆ）の#40は初期条件が良か
ったからの模様。

ここらへんでもう一度、zebraサイトのFFOテストページにあるcomplete logなるものを見て
みると、全然違う。バージョン違いなのか、やってる事が全く違う。

浅い探索をしてｆを決めてNull window search（正確には幅３なので正解が判別できる）
を繰り返しているように見える。けど、ログ上に％が出てきて、９８％、９９％、％無しみたい
になっているので、何らかの方法で前向き枝刈しながら、評価値を求めていき、最後まで
幅３の探索しかしていないのかな。こういうのをPVSって言うのかな。

浅い読みとか、前向き枝刈とか絡んでくるんなら、中盤探索をやってから戻ってきた方が
よいのかな。。

**名前は開発中のものです。** · 2015/10/19(月) 09:50:52.09

とりあえず、ざっくり中盤探索のnegaScoutを組んでみた。
素の状態で１０手読みくらいなら１手１０秒以内に終わりそうな感じ。

だけど、いろいろと気になる点が。
とり同一局面から着手可能な手の評価値の順番は、あまりくるっては
いないように見える。ただ、評価値事態は結構ずれている。

そして、黒番白番で精度が全く違うように見える。
言われてみれば、同一局面でも手番が逆転すると評価は全く変わるからなぁ。
今は、手番も一つのパラメータにしちゃってるから、その差異は埋められない。

パラメーターとか評価関数の区分とか再考の余地があるんじゃないかと。

前向き枝刈するにしても、評価関数がフィックスしないとダメじゃないかと。
というわけで、しばらく評価関数方面で時間つぶしかなぁ。

**名前は開発中のものです。** · 2015/10/26(月) 09:44:35.41

中盤探索に入るにあたって、評価関数の計算の試作をいろいろしているんだけど、
いまいちぱっとしない。１００回学習で１晩かかるし、３００回試行くらいしないと傾向が
見えてこないので、時間がかかる。

で、仕方ないので、裏で序盤定石を作り始めてしまった。
こちらも棋譜ベースで作ろうと考えている。

そこまで来た時に、データベースのどういうデータが使いたいのかが、逆にはっきりして
来て、今使ってる３６０万件棋譜の中のデータを選別しようかという方向に傾きつつあります。

が、やっつけで作って中身が思い出せないフォーマット変換のプログラムから直さなきゃならん。
開き直って、もう１度、データ変換から作り直そうかなと・・・

**310** · 2015/10/30(金) 17:31:41.23

棋譜ベースで序盤２０手の定石DB作った。
定石DBは置換表をベースに作ったので、検索は速いけど、容量が大きい・・・。

簡単にαβで２０手探索してみた。
ネットで調べた定石集に載っていない手筋が出てきてしまった。むむむ。
５手目までエビ系で、しかも石差＋２で黒勝ち。棋譜が偏っているのかな。

棋譜は例の５０万棋譜計画の奴で１０手目、２０手目以降を訂正したというデータ。
明らかに壊れたデータが入っていたりと、何かと使いにくい箇所があるデータだけど、
定石DB作るにはこの量でも足りないのかも。

定石探索用の簡易版minMaxを作りながらつらつら考えていたら、終盤探索の
moveorderをもっと良くする方法を思いついた。評価関数の精度次第だけど。

新評価関数は、途中でうっかり仕込んだバグで遅延。ようやく原因が見つかって、３００回
試行まで来た。もうちょい収束させたいけど、テストに使える程度にはなってると思う。

**310** · 2015/11/08(日) 00:32:40.41

moveorderを早くする方法というのは、事前に軽く探索した手順を保存し、その手順から
優先して探索するというもの。理論的にはscout missがゼロになる。
探索した手順を取り出す仕組みが必要になるので、その辺を改造しようと思ったところで、
悪い癖が出てしまいました。Cベースのソースを一旦棚上げして、C++ベースのクラスを
利用した形で一から作り直してしまいました。

moveorderの配列をvectorに変えたり、unordered_mapを見つけたので置換表に使って
みたり。置換表は、システム任せにして動的にメモリ確保に行かすと、探索ノードの減少
以上に速度低下して使えない。最初からある程度メモリ確保させようとしているんだけど、
いまいち設定がわからない。動的にメモリ確保するので、速度のバラツキも大きい。

そもそもC++は初めてなので、目的がオセロからC++というかunordered_mapの習得に
なりかかっていたので、一旦棚上げして、配列ベースの自作ハッシュの置換表に戻る
方向にしました。

とはいえ置換表を外してもnode/secが5kくらいしか出ていないので、実装が悪いところもありそう。
というわけで完全に寄り道しちゃってます。

**310** · 2015/11/12(木) 16:56:19.10

ようやく、C++ベースの終盤探索（negaScout）が、Cベースより若干速くなりました。

・unordered_mapの速度のバラツキはデバッガー上限定。
実行ファイルでも多少ばらつくけど、メモリ効率＆メンテナンス性からunordered_mapを採用。
・探索した確定手順を返す方法の検討で苦戦。
negaScout＋置換表では原理的に無理と認識するのに時間を要しただけでしたorz
置換表無しnegaScoutかnegaMax＋置換表では、後者の方が高速。
・確定手順を元にmoveorderする改造の効果は限定的。
moveorderで先頭にする処理が重い模様。適用範囲を狭めて行くと１～３手で同等の速度。
・ハッシュキー生成簡素化で若干速度アップ。
・その他、細かいスピードアップ。

確定手順の導入で５０％以上速度アップを目論んでいたのですが、無駄な努力でありました。
一応、与える確定手順の数はマクロ定義で可変できるようにしてあります。

評価関数も修正を加えたいので、データ変換部からまた作り直しです。
目標も無しに同じ事２回やるのは面倒だなぁ。

**310** · 2015/11/19(木) 14:23:44.03

定石部分もクラス化が終わりました。クラスなんての扱うの初めてなので、もうちょっと
綺麗にできたかなと思う面もありますが、C++習得が目的ではないので。

終盤確定読みは０．０５秒刻みで速度アップ。FFO#40で２．３秒になりました。

今まで、速いプログラムでは３０手目くらいから勝敗判定を始めると言う記述を読んで、
なんて速いんだと思いつつ、何に使うんだろうと思っていましたが、ようやく腑に落ちました。
オセロというゲームは勝敗だけが問題で、勝つんなら２石差で十分。「少なくとも負けない
手」というなら、(-1,0)のNull windowで探索してβカットされた手を選べば良い。評価値は
不定（これより良いという値）でも負けない手であるという点では「確定」手順です。moveorder
が正確なら、極端に石差を減らす手も選ばない。これなら現状でも２５手ちょいくらいは行けそう。
ただ、これは勝勢の時の話で、敗勢の時の評価値は「これより悪い」という数字だし、
逆転は相手のミスに期待するしかなく、相手も同等のロジックのAI相手だと必敗となる。
結局定石段階で勝負がつく事になります。

今、定石DBは３０手を前提に組んでいますが、３１手目から勝敗判定ができるんなら、定石
を外れない限り中盤探索が不要になり、定石から外れた時にのみ中盤探索が必要になる。
つまり中盤探索は対PC戦では重要度が低く、定石が切れたら、即、終盤探索が始まる。

そもそも評価関数が良ければ、中盤もあまり深く探索する必要がないわけで。
深く読む意味って、なるべく評価が正確なステージを使いたいからなんだなぁと。

というわけで、次はそろそろ中盤探索です。Multi Prob Cutの英語論文を読まねばならぬ・・・。

**310** · 2015/11/21(土) 00:05:47.02

定石DBを使って３０手目まで着手した盤面の予想石差が２で勝ち判定だったので、
試しに３１手目から勝敗判定をしてみました。

(-1,0)のNull windowで７分３０秒ほどで解けました。
（参考）勝ちと引き分けを区別するために(-1,1)で計算すると９分３０秒ほど。
探索ノード数がintではオーバーフローしてしまった・・・。

これから、３３～４手目（残り２６～７手）くらいで、１０秒程度で解けると予想されます。
勝勢ならこれで良いのですが、敗勢の時は、初段がβカットされないので１０倍程度
時間がかかる。そうすると、残り２５～６手目くらいが勝敗読みの限度かなと。

もっと高速化が必要なのか。それとも、何か発想の転換ができるのか。