▲コンピュータ将棋スレッド132
■ このスレッドは過去ログ倉庫に格納されています
>>101 ヤセルモとかとの対戦結果出したほうがいいですね 相性が出るから 1つのソフトにだけ勝ち越す評価関数は、よく出来上がります 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」 偉そうな事言ってる割に・・・・w >>115 の関連で先ほど公開すると言っていた評価関数を公開します。ファイル名は 15gouにしています。以下のURLからダウンロード出来ます。 http://39.gigafile.nu/0224-7eb7dcdf8a0ca787e9b77037f8c5f81a >>114 王の駒の価値を勝敗を表す数値にして、いくら駒得しても評価値がその数値を超えることがないっていう設定にしたらどうなる? 具体的にいうと王の駒の価値を3万とかにして、他の駒価値の積算でもし3万を超えたらそれは3万ですってことにするっていう感じ。 そうすると、金とってから王とっても、王を先にとりにいっても同じ価値だからどっちを選ぶかは運しだいとかめんどくさいことになるかw >>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 AKB辞めたAKB元メン状態だなPona本。 Pona本からコンピューター将棋を取ったらただの人だが、 そもそも開発を進めてくれる共同開発者がいないからもうどうしようもない手詰まりの状態 なんかさぁ・・・公開するって息巻いたけど自分が計測してたもの以外を丸投げしてねえか? gigafile.nu これ見て思い出したけど 前のスレでも同じようなこと言ってこのuplodaにあげてたよな。 フェイクニュースと断じるなら悪意を証明しなきゃいけなくないか? >>129 ありがとうございます >>137 >AKB辞めたAKB元メン 例えうますぎ >>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 やっぱお前も内容わかってないんじゃんw >>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 早速ダウンロードさせていただきました、ありがとうございます >>182 訂正1500→1500万 >>181 >>129 はより深いノードで実力発揮するのかもしれませんね 要検証か 15gou VS testeval 503-21-482(一手200万ノード) https://i.imgur.com/pk38kQM.jpg お強いですね。 >>184 testevalは前スレの259?それとも自作? 前スレ259です。ノード数が少ない場合にはまあまあ強さを発揮していると考えてるので 毎回対局結果すらキャプしない馬鹿と 0.1秒とかでドヤッてるガイジは何も学習しないんだな >>176 を少しは見習え 水門でクジラちゃんが19gou=kakarotにふっ飛ばされた件 (ただし定跡どハマりだった模様) >>184 windowsユーザーってこんなフォントで発狂しないの(´・_・`) ? >>188 2戦目は定跡抜けた後のがっぷり四つから、一手の読み勝ちでカカロットの勝ち。 (読み筋はどちらも同じで評価だけ違った) まだ対局回数が少ないとは言え、R4400を狙える力はあるのかも。 今までのやり方でAlphaZeroに迫っているのを見ると、それだけ将棋は探索の効果がでかいということだろうか それともこっそりDLが混じってるとか? そもそもAlphaZeroの結果が謎が多すぎる。 なんでそんな簡単にelmoのすぐ上に行けたのか、なんでそこで止まってしまったのか。 YSSの人がレーティングと実際の勝率について書いてたけど、コンピュータも人間もレーティング差が大きいとeloレーティングに基づく勝率よりも5割に近づく 実際のAlphaZeroはもっと強い可能性がある レート自体は自己対戦から出してるとのことだから相対的に控えめに出てる可能性もある? とりあえず多めにR4600と見つもっておこう。 いっそ計測はelmo基準にすれば良くない? 対elmo特化の戦績だとしても その方がAlphaZeroの棋風を擬似的に再現してる可能性という意味で需要あるし >>196 AlphaZeroグラフ自体は自己対戦からだろうけど、縦軸の数値はuuunさんのサイトとelmoとの対局で当てはめたものだと推測 とはいえ30万ステップ以降のグラフの伸びがほぼ横ばいでそれでいて不安定なのは間違いないですね 混ぜると強くなる理由 https://github.com/gcp/leela-zero/issues/814#issuecomment-362931617 Averaging weights from nearby networks decreases noise from mini-batch gradient calculations. If the network is very near the optimum then the weights don't change much during the training and we can think that the network weights are the optimal weights plus some noise caused by the stochastic gradient calculation. Averaging the weights decreases the amount of noise in weights and brings the network closer to the optimum. Same effect can be had if learning rate is decreased. だって 学習率下げた時の段差と関係あったのか そもそも学習率はあまり大きくするべきではないんですよね、収束までは遅くなりますけど elmo絞りをするならなおのこと学習率は小さくするべきだと思います 学習率をただ下げてもダメだそうだぞ。 線形評価関数ではないが、DeepLearningの世界では小さすぎる学習率は局所解に収束してしまう要因として挙げられている。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.4 2024/05/19 Walang Kapalit ★ | Donguri System Team 5ちゃんねる