▲コンピュータ将棋スレッド132
■ このスレッドは過去ログ倉庫に格納されています
>>82 は第2世代TPU
棋譜生成は第一世代TPU、Google社内に大量に余っていたんだろ
棋譜生成にかかった時間は書いてなかったような
棋譜生成に大幅に時間がかかるなら3日でプロを超えたと言うのはおかしいが Alphazeroは確かv1TPUを5000台使用だから、v2TPUは約８倍の性能らしいから625基用意すればいいな
p3.16xlargeがv100*64だから10契約すれば五分だろう
ただし一時間に250ドルかかるから１日6000ドルかかるな
三日でいいなら18,000ドルだ
200万あればAlphazeroの検証できますよ！やねさんどうですか GPUは8つだけか
ということは8倍せねばならないから約1600万円か、やねさんならなんとかなるはず… YSSがBonanzaライブラリ使用になってるけど、どういう感じで仕上げてくるんだろうか やねさん、200万円なら私が負担しましょう。
連絡下さい。
但し結果は出して下さいね。 結果が欲しいなら平岡さんの棋譜生成に協力するのが一番手っ取り早いでしょうよ きふわらべのアピール文書25ページでワロタ
とりあえず普通のフォントサイズでよかった >>94
フォントサイズ小さくすれば沢山情報埋められて結局これまでと同じという事態にならなくてよかったな＾＾ やりすぎると文字数制限されるから自重したのでしょう 対戦数が少ないとはいえ、floodgateに4300代がちらほらと。
google先生が現在進行形で本気出してたらどこまで行ってるか気になるところだが・・・ 今回既に「印刷して読めるサイズで」っていう狙い打ちみたいな制限がなかったっけ？ｗ ついに成し遂げたかもしれないです
対aperypaq成績で55-8-37ができました（一手1500～2000万ノード）
この時点で有意差はありますが、もうちょい検証してみていい感じだったら公開しようと思います
具体的にはこのノード数なら500局で勝率55%あれば十分と思っています >>101
ヤセルモとかとの対戦結果出したほうがいいですね
相性が出るから
１つのソフトにだけ勝ち越す評価関数は、よく出来上がります uuunuuunは勝手に測定してるだけなのに迷惑もクソもあるかよと思う。
強そうな評価関数はどんどん公開するべき。
レーティング1位になんかならなくても、特定の戦型で強い等、部分的に優れているなら充分価値がある。 雁木採用率が高く戦型にムラのあるヘンテコyaselmoと対戦させるのは時間の無駄。
レーティングの近い評価関数ならtamoreの方がバランスがいい。 >>102
そうですね
aperypaqとの最終結果が芳しかったらおまけで300局ほど対局させてみます おまけで対局させるならtanuki-かqhapaqにしようと思っています >>105
同じこと思ってたの俺だけじゃなかったんか
当時は雁木が流行りだしてたからアレだったけど序盤がアレだって指摘する人も多かったよね
もっとバランス良いのはrereだけど公開されてないからなー やねうら王 @yaneuraou
https://twitter.com/yaneuraou/status/959600443000107008
『グリザイアの果実』というアダルトゲームが原作のアニメをいま友達と見ながら、原作ではどこでセックスしているのかを当てる遊びをしているのだけど、
「この状況からだと無理くない？」「この程度の親密度からいっちゃう？いや女の子、病んでるから可能か…」みたいなとても難解な謎解きになってる。
そんな事してないではよ将棋ソフト作れやっ！！！
😅😓😒😒😠😡😠😡😠😡👊👊👊💥💥💥 500局（引き分けを抜く）なら279勝（勝率.558）で99%信頼区間の下限で勝率.500越えるね >>110
dropboxだかの容量の関係で今は公開されてないみたい >>105
yaselmoと「だけ」対戦させるのは無駄だろうけど、
ほかのソフトとほどよく回数ミックスさせるならむしろ
yaselmoとは対戦させるべきだろ。 将棋プログラム自作してたら、詰んでる局面でなかなか相手の王様を取りにいかないんで
なんでだろと思ったんだが、駒得オンリーで局面評価してたからだった
「ここで単に王を取るよりも、金を取ってから王を取った方がよくね？」
「あ、あっちの銀を取ってからでも間に合うな」
「お、この角取れるじゃん」
と、勝ちが確定したら王様放置して駒得を稼ごうとし始める
純粋駒得評価関数って、必然的にえらい意地悪な挙動になるんだな >>101
俺も一手1900万ノードでaperypaqに500局で勝率55%のブレンド評価関数を持ってい
るけど、wakameとyaselmoと技巧の3つにはaperypaqより大分勝率が落ちたので、今
は使ってない。キメラはキメラ元には強くなることが多いが、キメラ元以外には勝率が
落ちることが多いよ、キメラには相性があるからな。もう一つ1500万ノード 定跡なし
で勝ち越しても、持ち時間15分秒読み10秒まふ互角局面集ver4使用時では逆にかなり
負け越すのキメラも確認している。 KPPTはもうお腹いっぱい
KPP_KKPTでaperypaqより強い評価関数希望 >>115
とりあえずそのブレンド評価関数を公開してみないか？
まふさんが4200突破したって吹聴してたが、透。さん曰く「yaselmoより弱い」だし
実際に55%あるか調べてみたい、>>115もテスト後公開するみたいだし >>119-120
ありがとうございます。手持ちの評価関数に1手1500万ノード以上、対aperypaqで有意差もって勝ち越せる評価関数はないので比較検証用にも助かります >>114
詰みルーチンを詰んでなかった初期のBonanzaがそれで、勝又教授に
「血も涙もない寄せ」と評された。 >>115
つ[王手が絡む局面での探索延長]
つ[静止探索]
「コンピュータ将棋における全幅探索と futility pruning の応用」でggrks 「ggrks」「orz」
偉そうな事言ってる割に・・・・ｗ >>115 の関連で先ほど公開すると言っていた評価関数を公開します。ファイル名は
15gouにしています。以下のURLからダウンロード出来ます。
http://39.gigafile.nu/0224-7eb7dcdf8a0ca787e9b77037f8c5f81a >>114
王の駒の価値を勝敗を表す数値にして、いくら駒得しても評価値がその数値を超えることがないっていう設定にしたらどうなる？
具体的にいうと王の駒の価値を3万とかにして、他の駒価値の積算でもし3万を超えたらそれは3万ですってことにするっていう感じ。
そうすると、金とってから王とっても、王を先にとりにいっても同じ価値だからどっちを選ぶかは運しだいとかめんどくさいことになるかｗ >>114
それが世に言う通称辱め詰めというやつだ 聖人野田さんおこなの？
山本一成@Ponanza
@issei_y
なのでPonanzaは96bitのハッシュキーを使用している。でも最近の将棋・チェスプログラムじゃハッシュキーサイズは16bit(！)を使用しているみたいだ。
ハッシュキーのコンクリートよりもテーブルサイズの圧縮によるキャッシュ効率の向上をとっている。
正直ちょっとやばい（褒め言葉です）
nodchip@tanuki- @nodchip ・ 19:47:48
@issei_y 補足させていただきます。Stockfish/やねうら王の置換表の実装は
1. 局面を64bitに圧縮したハッシュキーを作る
2. ハッシュキー下位log2(置換表のサイズ/32)ビットを使ってビンに振り分ける
3. 一つのビンは最大3エントリ保存できる
(続く)
@issei_y (承前)
4. エントリに対応する局面の等値判定はハッシュキーの上位16ビットを使用する
となっております。後学のためにご教示願いたいのですが、参照された「最近の将棋・チェスプログラム」は何でしょうか？
Twitter Web Client
PEZYに関するフェイクニュースに対して怒りを露わにする @tanakh 先生の気持ちが少しだけわかった気がする 山本はこのまま知識人を気取り続けるつもりなのか？
将棋ソフトの開発してたほうがよっぽど充実した人生になるんじゃないか >>135
コンピュータ将棋について語ろうとしてもやねさんや野田さんにツッコまれる >>133
単純に興味からの質問と好意的な見方をしましょう＾＾；
>>135
ＡＫＢ辞めたＡＫＢ元メン状態だなPona本。
Pona本からコンピューター将棋を取ったらただの人だが、
そもそも開発を進めてくれる共同開発者がいないからもうどうしようもない手詰まりの状態 なんかさぁ・・・公開するって息巻いたけど自分が計測してたもの以外を丸投げしてねえか？ gigafile.nu これ見て思い出したけど
前のスレでも同じようなこと言ってこのuplodaにあげてたよな。 フェイクニュースと断じるなら悪意を証明しなきゃいけなくないか？ >>129
ありがとうございます
>>137
＞ＡＫＢ辞めたＡＫＢ元メン
例えうますぎ
>>138,139
なんかあった？ 野田さんも一言多いな。間違ってるなら指摘するだけでいいのにフェイクニュースとか
レッテルを貼ってるのはどっちなんだろうか？ "PEZYに関するフェイクニュースに対して怒りを露わにする @tanakh 先生の気持ち"が少しだけわかった気がする
どう読んでもフェイクニュースに対して怒っているのはtanakhさんで少しだけわかったって言ってるだけでしょ 正直どーでもいい。
そこに熱くなる理由がさっぱりわからん。 後学のために〜以降は指し過ぎでしょう
将棋じゃないんだからキッチリ詰ませても遺恨が残るだけなのに 山本一成@Ponanza @issei_y
Ponanzaは引退しない。
Ponanzaは世界コンピュータ将棋選手権の決勝に進出できないぐらいグチャグチャのボコボコに負けるまで引退しない。
だから安心して挑みかかってくるといいよ
今年の世界コンピュータ将棋選手権で、とうとう超強豪であるYSSと激指が決勝進出できなくなったことには意味がある。
一番いい時期で止めずに戦い続けたことに私は敬意を払いたい。
だからPonanzaも最後まで戦う。それこそがコンピュータ将棋への最大の恩返しだ。
これが一年ちょい前の発言
そしてここ半年の発言と行動考えると将棋ソフト開発者の心中察する AKBというより完全に盛りを過ぎたモー娘。
現、元メンバーがやりやってワイドショーで
小さく紹介されるみたいなショボい業界 置換表のハッシュキーが64bittだったとしても
置換表のサイズが2のべき乗で例えば64K エントリ（16 bit）だったとしたら、
>>133なしくみでは全ての局面が16 bitでしか識別されていないということになって山本氏完全勝利 ポナ山さんは前言撤回することになんら躊躇をしない人間だから、
重箱の隅をつついても何も意味がないかもしれない。 >>148
>>133の仕組みでは、64Kエントリーだったら、16bit+16bitで32bit有効だろ？ いやすまん>>148のは「エントリ」の用語の使い方が変だったが
やっぱ置換表サイズが64K * 32 Byteのとき、16 bitでしか識別されないんじゃ…
やねうら王の1エントリは10 Byteで、それが3エントリ束になったやつを32 Byteに収まるしくみ。よって、
>2. ハッシュキー下位log2(置換表のサイズ/32)ビットを使ってビンに振り分ける
というのは単に transp_tab[(64 bitのハッシュキー) % (置換表の一束3エントリの総数)]を参照する、と言っているに過ぎず、
これ自体はどんな置換表でもやることなので、>>148では局面の識別のうちに含めていない。（これが>>150との+16 bit分の食い違いと思われ
で、常識的な置換表なら、局面sのハッシュキーからエントリまで特定した後、そのエントリが本当に局面sの情報を記憶しているのか
確かめるためにハッシュキーの全ビットの等値判定をやるはずなんじゃ（つまり常識的には64 bitの等値判定が要る
そこが>>133では16 bitで済まされている、、 >>151
キーは64bitだけど、
例だと置換表へのアクセスはキーの下位16bit(64K)がエントリの特定に使われて、
特定されたエントリ内でキーの上位16bitが合致するものがあるかどうかを見るから
例だとキー64bitの内、本当にキーとして使われるのは上位16bit+(使われない32bit）+下位16bit（エントリー数分）で
32bitになる所までは良い？
エントリー数は普通もっと大きいので、下位24＋αbit位がエントリの特定に充てられて、
上位16bitと合わせれば40bit+α位は実際に使われるキーとして担保されると思うんだけど、
どこか間違ってる？ 自分の価値が落ちても、チョッパリが不快になれば大勝利の精神だな >>152
ハッシュキーの有効ビット数が32 bitというのは見積もりが甘すぐる…
ビンの数が64 K個で、ハッシュは理想的
（現実に現れる局面が、64 bit（96 bitでも良いが）のハッシュキー空間に一様に分布 && 下位16 bitと上位に相関が無い
とすると、1個のビンは平均64 K回に1回参照される。
置換表サイズを大きくすることでビンの参照周期が伸びれば確かに参照回数（≒時間）当たりの衝突頻度は下がるが、
1個のビン特定後の事後確率としての衝突確率はなんら下がらない
そいつはハッシュキーの上位16 bitでしか比較しないのだから、やっぱ1/64 K程度になるであろう いやｽﾏﾝ参照するビンの中のエントリが先客で満杯ばかりだとすると、
誤：参照回数（≒時間）当たりの衝突頻度は下がる
正：参照回数（≒時間）当たりの衝突頻度は下がらない
よって>>133のしくみは長期間置換表をクリアせずにいるとかなりﾔｳﾞｧげ で、衝突を避けるために1ビンの中に3エントリ設けているわけだが
ビンの中が満杯のとき、たまたまどれかのエントリの記憶する16 bitがハッシュキーの上位16 bit一致する確率は、p=1/(64 K)として
P = 3_C_1 * p * (1-p)^2 + 3_C_2 * p^2 * (1-p) + 3_C_3 * p^3
だけあって、一致したのだけれどそれで正解という（一致後の事後）確率は1/(ハッシュキーの総数)でしかないから
置換表を頻繁にクリアする（結果、ビンの中のエントリに大概空きがある）
という条件でも追加しない限り、
>>133の置換表は毎回だいたい確率Pで衝突を起こす
、、、 満杯前提の置換表しか作ったことが無いから>>133から導かれる結果は斬新やったわ
ノーサンキューだ >>156
難しい説明ごくろうさま。
で、内容はさっぱり理解できないんだけど結局のところ野田さんと山本さんとどっちがあってるの？ >>159
山本氏発言の
>ハッシュキーサイズは16bit(！)
というのは確かに筆が滑った感じで、正しくは
>置換表エントリのハッシュキーの記憶サイズは16bit(！)
なん
ｼﾞｬﾏｲｶ
それ以外（驚愕した動機）はだいたいあってる >>160
んじゃ、結論としては野田さんの勇み足？ Rota_JP
Aperypaq対15gou 209-195-25
探索Yane4.80AVXT
1500万局面/手(一手0.75秒(35T))
定跡オフ,Ponderオフ,投了値3000,引き分け256手
だってさ
Aperypaqにすら勝ち越しできない
Raina_i3 mixE_i3 この人でしょ
定跡使って上位に一発入っただけなのを勘違いしちゃった恥ずかしい御仁
だいたい作成日がねぇ・・・
自分で計測したのを出さずに急ごしらえでキメラ()しただけのgm 広い世界でponanzaと出逢ったことで
自由な序盤へ my destiny
永遠に変わらない独自性を感じてるよ
いくつもの季節 ponanza流で戦って行こう >>163
Rota_JPって毎回引き分けの表記を真ん中じゃなくて右側に記入するから紛らわしい
ほぼ互角じゃないか 15gou x 最高R
3500万ノード 200局 book無 局面集無
15gou の勝率 41% でした・・・ >>159
この内容が分からないというのは開発能力がないひまわりか >>171
んじゃ、わかってるようだから追加で説明を頼むわ。
どうして>>154 - >>157の説明で山本さんがだいたいあってるといえるのか、
要点をかいつまんで解説してくれ。
まぁ、どうせわかってないんだろうけど。 149 名無し名人 (ﾜｯﾁｮｲ bfdc-VW3n) sage 2018/02/03(土) 22:33:05.02 ID:WFL8HojI0
ポナ山さんは前言撤回することになんら躊躇をしない人間だから、
重箱の隅をつついても何も意味がないかもしれない。 https://www.axfc.net/u/3885896
https://www.axfc.net/u/3885897
評価関数を2つ公開します
どちらもまだ検証が不十分ですが、aperypaqにはやや勝ち越せるのではないかと思います
同じ局面でもaperypaqとかなり評価が異なることがしばしばあるので中々面白いです
興味のある方は検証や改造などして遊んでみてください
検証して下さる方がいれば期待できそうな方の評価関数を絞ろうと思います
※後手番で希にあっという間に不利になる手順に飛び込むことがあるのでご注意下さい >>175
やっぱお前も内容わかってないんじゃんｗ >>156訂正；
誤： P = 3_C_1 * p * (1-p)^2 + 3_C_2 * p^2 * (1-p) + 3_C_3 * p^3
正： P = 3_P_1 * p * (1-p)^2 + 3_P_2 * p^2 * (1-p) + 3_P_3 * p^3
誤： （一致後の事後）確率は1/(ハッシュキーの総数)
正： （一致後の事後）確率は1/(ハッシュキーの総数/(2^16 * (置換表のビン数)))
（∵エントリの特定に至った時点でハッシュキーの最上位16 bitと置換表のビンの数にあたる下位bitは一致がもともと確定
■ 具体的数値
ハッシュキー64 bit（で局面の識別に十分と仮定）、
最上位16 bitのみ等値比較、ビンの中の3エントリがどこも満杯とする。
置換表サイズ(ビン数) p P r 衝突頻度(=1/(P*r))
--------------------------------------------------------------------------------
64 K 1.53e-5 4.58e-5 1.00 2.18万回に1回
512 M 1.53e-5 4.58e-5 1.00 2.18万回に1回
※ pとPは置換表サイズに拠らない。（ビンの中に3エントリかつエントリ特定にハッシュキーの16 bit等値比較、で確定
※ rは上で訂正した「（一致後の事後）確率」の逆数で、エントリ特定済条件での衝突確率。置換表サイズ依存だが64 K v.s. 512 Mでは差が出ない。
→2.18万回に1回衝突とか使い物にならない。>>133の置換表は満杯になるような使い方をしてはいけない
置換表サイズに対する勝率は、「どのビンにも空きエントリがある」が満たされた時点で頭打ちになる（そこから先はいくら置換表を大きくしても勝率が伸びない）と予想 >>173
もう少し対局追加してみているのですが、
今度は15gouが勝ち星リード(57%程度)しているので
対局数が500局くらいでないと結果でないかもです。
15gouが強いのは間違いなさそう。
この「最高R」に途中経過でも勝ち越せるソフトは過去いなかったので。 >>129
こちらの環境では1手1500ノードで有意差なさそうです
でも公開してくれてありがとうございました
>>163
Raina_i3 mixE_i3の人ではなさそう
あの人、一個も評価関数公開しなかったし
>>176
早速ダウンロードさせていただきました、ありがとうございます ■ このスレッドは過去ログ倉庫に格納されています
