yaneurao

https://github.com/oreilly-japan/deep-learning-from-scratch-3/blob/976e9bf3ad556ce06e1d6c2da78db02d52b4b6a1/dezero/core.py#L198 https://github.com/oreilly-japan/deep-learning-from-scratch-3/blob/976e9bf3ad556ce06e1d6c2da78db02d52b4b6a1/dezero/core_simple.py#L139 書籍のほうでは、後者になっています。おそらく、前者が直し忘れだと思われます。 それに関連してですが、内包表記の変数名が一貫していないのは感心しません。例えば、 https://github.com/oreilly-japan/deep-learning-from-scratch-3/blob/976e9bf3ad556ce06e1d6c2da78db02d52b4b6a1/dezero/core_simple.py#L128 こういうところで、変数名を何故xにするのでしょうか。(inputにしないのは何故なのか。outputsのときだけ変数名をoutputとするのは何故なのか) 一貫性がなくて見ていて気持ち悪いです。 ついでに書籍のほう、p.249 > y = self.outputs[0]() ここ、weakrefだから"()"をつけていることを書籍のほうのソースコード上にも"#weakref"のようにコメントがついていたほうが親切だと思います。 それから、 > x, = self.inputs tailing commaは、このコードを読まされる側としては見落としやすく、バグの原因になりやすいため、括弧をつけたほうがよろしいです。 cf.https://www.python.org/dev/peps/pep-0008/#when-to-use-trailing-commas 例) > (x,) = self.inputs

TensorRTとcuDNNにPATHを通されてしまうと、dlshogiが参照しているのとは異なるバージョンのTensorRTとcuDNNを参照するプログラム(具体的にはふかうら王)が動かなくなってしまいます。 なので、dlshogiのインストール手順の説明の修正を希望します。 具体的には、ふかうら王では以下のようにフォルダを構成することを推奨しています。 これに似た構成をdlshogiでも推奨していただくわけにはいきませんでしょうか。(図や説明はこのやねうら王Wikiから自由にコピペして使っていただいて構いません。) https://github.com/yaneurao/YaneuraOu/wiki/%E3%81%B5%E3%81%8B%E3%81%86%E3%82%89%E7%8E%8B%E3%81%AE%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB%E6%89%8B%E9%A0%86#%E3%81%B5%E3%81%8B%E3%81%86%E3%82%89%E7%8E%8B%E3%83%95%E3%82%A9%E3%83%AB%E3%83%80%E6%A7%8B%E6%88%90%E4%BE%8B

dlshogiのOwnBookエンジンオプションなのですが、 - USIの原案では、これはUSI_OwnBook - Stockfishで採用されているのも、UCI_OwnBook - また、ShogiGUIがダイアログで「定跡を使う」にチェックを入れると設定してくるのもUSI_OwnBook です。 やねうら王はこれらの事情に鑑み、2020年3月にエンジンオプション名OwnBookをUSI_OwnBookに変更しています。 なので、ここはUSI_OwnBookになっていたほうがありがたい人がたくさんいるように思うのですが、変更してもらえないものでしょうか。 ``` なお、将棋所で対局開始時にこの２つを必ず指定しているのは、この２つは使用頻度が高く、値の変更も頻繁に行われると思われるためです。 USIの原案では、これ以外にも、USI_OwnBook、USI_MultiPV、USI_ShowCurrLine、USI_ShowRefutations、USI_LimitStrength、USI_Strength、USI_AnalyseModeという名前のオプションが予約されています。（詳しくは原案を読んで下さい。） http://shogidokoro.starfree.jp/usi.html ```

SelectMaxUcbChild()なのですが、子ノードがすべて引き分けの時に親ノードにそれを伝播していないです。😥 なので伝播していれば早い段階で引き分けだとわかる局面でも引き分けだと判明するのに時間がかかります。 https://github.com/TadaoYamaoka/DeepLearningShogi/blob/2ec875c037c4abc3e6f5511e2169461cf3457ff4/usi/UctSearch.cpp#L1349 1) すべての子ノードが、勝ち(IsWin) => 親ノードは負け 2) すべての子ノードが、引き分け(IsDraw) => 親ノードは引き分け 3) ひとつでも子ノードが、負け(IsLose) => 親ノードは勝ち となるのですが、1),2)のIsWin,IsDrawはMove(指し手構造体)の上位bitを用いるので、bitwise andしていけば1),2)同時に求まります。 3)もその時についでにbitwise orしていけば求まります。 ついでに言うと、子ノードすべてのMoveだけの配列があれば、その配列に対して、AVX命令で8つずつまとめて上のbitwise and/orができます。 // なのでそういう構造になってほしい気はします。 さらに言うと、1,2,3)のケースにおいて、そのindexを返す必要はなくて(子ノードの訪問回数のincrementが不要なら)、indexを返さず、上のbitwise andした結果なり何なりを参照渡しされた引数などに返すほうが、すっきりしたコードになります。

https://github.com/TadaoYamaoka/DeepLearningShogi/blob/2ec875c037c4abc3e6f5511e2169461cf3457ff4/usi/UctSearch.cpp#L1227 これだと、例えば、draw_value_white = 1.0(勝ち)、draw_value_black = 0.5(引き分け)の時、先手は千日手を引き分け、後手は千日手を負けだと思って探索するという非対称な探索を行っていることになります。こういう非対称な探索がやりたい機会は現実的にはほとんどないので、これは無意味な設定だと思います。 現実的には(例えば大会では)、先手番であるなら、引き分けを避けたくて、後手番なら引き分けは0.5勝扱いとみなして、対称的な探索をしたいのです。 例えば、この時、次のように設定したいわけです。 　draw_value_black = 0 　draw_value_white = 0.5 よって、上の当該箇所は、pos->turn() == BLACK ではなく、root_color(探索開始局面の手番) == WHITE になっているべきだと思うのです。