▲コンピュータ将棋スレッド123 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
ディープラーニングの将棋作ってる人、(wcscに出てない)elmo学習を七割くらい早く学習できるようにしてたけどあれは普通の評価関数でも早くできるようになるんだろうか？ >>481
epochはミニバッチ1回でカウントアップなのね >>481
そのpatch、損失減るの早すぎィィィ Basashiが全然ハイエンドマシンのyaselmoと当たらねぇ 1950Ｘが押されてる・・・・・
上のほうにいたyaselmo絞った人か やねうら王、KPPの手番なし(PP,KPP手番あり)型評価関数 EVAL_KPP_PPT、2/3ぐらい書けた。
ってあるのですが
これって強くなるの？ >>491
自分も似たようなことを考えてて、PPT型評価関数を作ってみてる最中。
もしかしたら2駒関係+手番で十分なんじゃないかって思って。だってPPの中にKPやKKの評価も含まれるんだもん。
うまくできれば評価関数のサイズを小さくできて、ショボいPCでも深く読めるようになるかなって思った次第。 >>492
お前は何を言っているんだ？
PPT型なんか評価関数の精度が思いっきり下がるんだから深く読めるわけがない。 >>493
深く読む＝探索深さのこと言ってるんだったら何も間違ってないでしょ
精度が悪いからなんて言い出したら、探索使わずその局面だけの評価したらKPPTなんてクソゴミ精度だぞ
結局探索と組み合わせてなんぼ 評価関数の精度が高くなればなるほど激しく前向き枝刈りができるようになって
同じ時間でより深く読めるようになるってことじゃないの
逆に精度が下がればあまり先を読めなくなる むしろ評価関数の読み込みを省略した奴が欲しいわ
ひようら王V4.75ならBonanzaより強いんじゃないか？
そして本家のひようら王はもうDL出来なくなってるのね 駒割のみならゼロ埋め評価関数で再現できるけど
手持ちで1/4加算させるのは素人の俺には無理だった
更に初めから評価関数を読まなければNPSも上がりそうだけど
プログラミング技術がないとその改造もムリゲーだった >>495
評価関数毎に最適な探索部書いたらそうなる かも しれんが、別にそんな開発の仕方はしてないしなあ
同じ探索部使ってもN駒パラメータが多い方が、枝刈りを積極的に行うかどうかなんてわからんし、どうやって検証するのかと
パラメータの少なさによるNPS向上は明白だけど、それ以上に枝刈り効果が高いなんてのは仮説に仮説を重ねすぎてる
というか◯◯は深く読むって議論自体に意味がなく、単に強さを比べればいいだけ >>498
>評価関数毎に最適な探索部書いたらそうなる かも しれんが、別にそんな開発の仕方はしてないしなあ
やや違う希ガス
少なくとも探索部のハイパーパラメータは今日日パラメータを振った上での自己対戦という品種改良的なやり方で評価関数に合わせ込まれてゐるし
本家stockfishとかは探索部のロジックまで品種改良的にやっている気配がする
>>495
評価関数の精度向上でNの手間で期待値として2^Nノードの探索を省ける、みたいな劇的なNPS向上効果は現実には無い
速い探索部は駒得だけにしても速いというのが現実
な印象 他スレで見たけど
yaselmoで解析すると大山康晴が歴代で1番一致しているらしいね
時代を先取りし過ぎでしょ。。。 今日電王トーナメントの開催方式を知ったんだけど随分運ゲー気味になってしまったな
相変わらず予選は8回戦しかやらないし3番勝負は決勝だけ 連盟がドワンゴに対してやらかしたらしいし、電王トーナメントも今回限りかもな >>501
冤罪問題の時の検証だと技巧と一番一致するのは橋本ってデータが出てたし、ソフトごとの癖でそのへんの傾向は大分異なるのかもね >>505
でも守衛室カンニングしてたのはハッシーじゃないから >>500
あぁ、やっぱ最終的にはそんな評価するようになっちゃうかぁ…。指摘ありがとうございます。 >>507
ついでにいうと２コマ関係だと壁形の認識も難しくなる。
技巧は２コマ関係だが玉周辺は利き評価で別扱いしてるからそこで空間も評価してるんかね。 >>508
ということで、KPPTは偉大だという結論に至りましたw
ならできることはやはり探索部の改善しかないということで、ソースとにらめっこを始めましたw
改善のスローガンは「先人の絞り結果を信じよう」ですw >>509
3駒KPPTは、学習の手間、評価精度、評価速度とメモリ消費の制約とバランスから選ばれてるに過ぎんので、
ハードが進化すれば4駒KKPPTとかKPPPTとかになるんでは？
大駒をK扱いにした拡張３駒HPPTは来ないのかね？
大駒の損得があると過大/過小評価しそうだが。 >>510
大駒を考慮した評価は真っ先に考えたんですが、おっしゃるとおり過大評価に対するペナルティをどうするかで詰まってしまって諦めましたw やねさん、オレが考えそうなことは既にやってたらしく、やりたいことは既にコーディングされてたw(探索パラメータの動的変更機能)
clang++対応に書き直すだけで実現できたので、現在の評価関数に対応したパラメータを模索中。 KKPPはともかくKPPPにしたらFutility purningが理想的に効いたとしてもNPSが1/4になるかもしれんがどうなの？
大駒をK扱いにした拡張３駒HPPTでHの位置の有効性はK周辺のKPPで決まってしまうと思われ、
仮にHPPに大きな得点が付いたとしたら汎化能力的に不正解な気がするがどうなの？
KPPでなくKPPＴにする有効性はTの違いを1パラメーターぐらいの追加で除去できない理由が無いから多分都市伝説 HPPTをやりたいのであればHを1個追加につきKPPに対してサンプル数を14万倍ぐらいに増やして学習したら多分ペナルティーのしくみとか考えなくともKPPと同水準まで逝ける >>514
14万倍……少なくともうちのリソースじゃムリw
だんだんプロトコルみたいになってきたな。そのうちHTTPとかできそうだw >>513
NPS4分の1なら探索深さ2手分。
3駒より本筋を読めているなら問題ない。
いや、序中盤では４駒有利、終盤では深さ優先、3駒有利になるかも。
大駒、特に飛車は盤面全体を支配するので他の駒との位置関係を精査する意味はあると思う。
飛車を詰められないようにするという以上に。
ただ、ヘタに実装すると川柳のヘボ将棋になりかねんな…。
飛車角交換も評価難しそう。
KPPTは1手深く読んで反転すりゃKPPで足りるが…プログラムのデバッグしやすさの問題では。 今年の電王トーナメント、トーナメント戦が決勝以外１戦かつ１時間切れ負けになってて草ｗ
もはや本当に只のじゃんけん大会に成り下がってしまったなｗ tanukiやうさぴょんの開発者はやねうら王超えられないのに出場続ける意味はなんだろう 開発者にとって将棋ソフト開発なんて趣味の一つみたいなもんだ >>518
電王トーナメントのマシンの搭載メモリが32GB以下だと本当におみくじ状態
メモリが128GBだと差が出るらしいけど。
大会スペックは、googleかamazonかmicrosoftのクラウドコンピューティングあたりになるといいな yaselmoを新オプションでKPP_PPT化すると技巧2よりも弱くなってしまうのね
初めからKPP_PPTで学習した評価関数を作らないとダメか >>521
ドスパラが売りたいPCを使うのでそれはない。
amazonがスポンサーになれば別だが。 大会後にソフト公開されても誰も使えないようなハイスペ専用ばかりだと味が悪いしね WCSCと差別化されるのは意義のあることだと思うけどね やねうら王さんしかちゃんと取り組んでる開発者いないじゃないですか
やねうら王さんが将棋ソフト開発やめたら進歩はストップですね
しょせんはやねうら王ライブラリ使用な開発者だらけですし >>529
所詮みんな趣味でやってるんだしそれは仕方ないのでは？ >>529
何事も洗練され高度になってくるとガチ勢ばかりでハードル高くなってくる。
オリンピックとかサスケとか鳥人間とか。 >>531
今朝何気なくフェッチしたら、コミットされててビックリしたw >>533
これは、tanukiもKPP_KKPTになる流れだよな
KPPTに比べて何が優れてるかわかる奴おる？ >>522
epoch0から再教育を始めました。果たしてどんな評価関数になるのやら…。 >>534
KPPのファイルサイズが半分になる
740MBが370MBになるのはでかいっすよ >>537
乱暴な言い方をすると、
サイズが半分になる→読む量が倍になる→強くなる（かもしれない） >>538
評価関数のサイズと読む量は何も関係なくない？ >>538
KPP_KKPTがKPPTより高速なのは確かだけど、テーブルサイズと実効速度をごっちゃにするのは乱暴すぎでは（あと読む量は倍にまではならない）
例えばGPSfishの評価関数なんて超省メモリだけどNPSは滅茶苦茶低い KPPTと比べて
KPP_KKPTのメリット:
・ファイルサイズが小さくて取り回しがいい
・消費メモリが少ない
・パラメタが少ないため学習の収束が早い（かもしれない）
・ちょっと早い（R40相当？）
デメリット
・評価関数の精度が下がる（R40程度）
参考
https://mobile.twitter.com/yaneuraou/status/882384671094341632
間違ってたらごめん >>541
R40上がってR40下がるとしたら、やねうら王やtanukiがこのタイミングでこれをやるメリットは？ >>540
乱暴すぎたかw
もちろんおっしゃるとおりなのは百も承知なんだが、細かく説明するのがめんどかったのでw
やねの探索部がここまで速くなってるので、サイズが小さくなった分の時間を読みに回せるようになるのは大きいですよ。
あと、GPSとやねを比べちゃいかんですよw >>535
とりあえず千田定跡をyaselmoでdepth3〜6で1億生成したものがあったので、これを食わせてKPPTのyaselmoと戦わせてます。
全くのゼロから1億を1回絞っただけなのでえらい弱いですが、1発入れるぐらいはできてますね。
あと、NPSはけっこう上がってます。探索パラメータは変えてないので、素の状態で速いみたいです。(SSE4.2です) >>544
おまけでevalmergeのKPP_KKPTパッチを作ったんですが、需要あります？ >>546
KPP_KKPTで作成した評価関数をブレンドできるのですが、KPPTでブレンドしたものをKPP_KKPTに変換したものと、素材をKPP_KKPTに変換してからブレンドしたもののハッシュを比べたら同じでしたw
なのでいらないですね。すいません。 daigo? @daigog 23分23分前
その他
[Floodgate/Shogi-serverの中間報告] ご不便をおかけしております。Webサイトは表示できるようになりました。各種プログラムは設定中ですので、今しばらくお待ちください。 >>543
やね氏によると、現状で評価関数の負荷は全体の３分の1ということなので、超軽量の０負荷評価関数でも５割しかNPS上がらない。
ttp://yaneuraou.yaneu.com/2016/09/24/%e3%82%b3%e3%83%b3%e3%83%94%e3%83%a5%e3%83%bc%e3%82%bf%e3%83%bc%e5%b0%86%e6%a3%8b%e3%81%a7%e3%81%af%e4%b8%a6%e5%88%97%e6%8e%a2%e7%b4%a2%e3%82%92%e3%82%84%e3%82%81%e3%82%8b%e3%81%93%e3%81%a8%e3%81%af/
すなわち１手も深く読めない。
３駒関係はそれほどに軽くて強い。 >>551
> ３駒関係はそれほどに軽くて強い。
だから、その軽いはずのKPPTをなぜこのタイミングでKPP_KKPTみたいにさらに軽いものにしようとしているかということだよ
なんで？ このスレに詳しい人が降臨すると片っ端から尋問されててワロタ やねうら王でもうKPP_PPT型の評価関数作れるの？
数日前に2/3が完成とか見たばっかりなのに >>555
よく見ろ
KPP_PPTやめてKPP_KKPTみたいだよ やねうら王の更新のタイミングはexeのバージョン4.75だけ気にしてればいいのですか？
https://github.com/yaneurao/YaneuraOu
のページは頻繁に更新されてますけど >>557
https://github.com/yaneurao/YaneuraOu/releases/
上記URLから最新の思考エンジン：
YaneuraOu-2017-earlyV475.zip
をDLすればいいだけでしょ >>557
対局しかしないならば、それでいいと思いますよ。
オレは新機能をすぐに試したいのでソースを落としてきてビルドしてます。 KPP_KKPT型の評価関数作ろうとするにはビルドから変更しなきゃいけない？それとも実行ファイルのコマンドに既に実装されてる？ >>560
ビルドしないと使えないです。
ビルドにはVisual Studioが必要って書いてありますが、Visual Studioでビルドすると配布されているものよりNPSは出なくなります。 >>561
「VC++2017でコンパイル可能」とは書いてあるけど、「Visual Studioが必要」とは書いてないのでは。 俺環は ubuntu+wine だからソースからビルドするのは無理だな >>564
Makefileもあって、gccでもビルドできるようになってますよ。オレはこっちでビルドしてます。 >>565
え、そうなの
一度試してみるわサンクス ビールわろた
エルモ絞り
やねうら絞り
かっぱ絞り
たぬき絞り やった！MSYS2/clangでOpenMPを有効にできた！
って、できてなかったのオレだけ？
githubに上がってるMakefileができてないから、やねさんもできてないんだと思うんだけど。 >>574
やねさんの意見箱には入れてきた。
clang系一式とtoolchainが入っている前提で、
・/mingw64/x86_64-w64-mingw32/includeに、/mingw64/lib/gcc/x86_64-w64-mingw32/7.2.0/include/omp.hのシンボリックリンクを張る
・Makefileの「-fopenmp」を「-fopenmp=libgomp」に修正
これでイケます。
英語の文献漁りまくった〜 >>575
シンボリックリンクは不要でした。
Makefileの修正だけでOKです。 makefileやめてcmakeにしてくれ
VSもcmake対応強化したっぽいしcmake一本で行こうで >>565
566だけどubntuでビルドできて一応CUI起動できることは確認した
しかしShogiGUIでエンジンに登録しようとするとハネられてしまう
何か足らないことがあるのかな >>575
これダメだわ。プリプロセッサがOPENMPを有効とみなさなくなる。
clangで動いてるけどOpenMPは有効じゃない。
evallearnでビルドしてlearnコマンド打ったらワーニングが出るので気づいた。
現在さらに調査中。 リンク時にも-fopenmpをつけないと空回りするよ
akiさんも同じところではまっていたような ■ このスレッドは過去ログ倉庫に格納されています
