-
-
Notifications
You must be signed in to change notification settings - Fork 136
やねうら王の更新履歴2019まで
yaneurao edited this page Jun 6, 2022
·
2 revisions
■ 2019/11/28
- Android用のAndroid.mkでのビルドが通らなくなっていたのを修正。
■ 2019/07/04
- 解説.txtの説明が古かったの修正。
■ 2019/07/03
- エンジン名のdefineからOTAFUKUの文字を取り忘れていたところがあったのを修正。
- bookコマンド一部動かなくなってた。ごめん。
- lintで引っかかっていた箇所修正。
■ 2019/06/30
- USIコマンド拡張。"side"追加。(AyaneruServerの実装で必要となった。)
■ 2019/06/29
- トライルールのときにトライの指し手を選ばなかったの修正。
■ 2019/06/26 V4.88
- V4.88にバージョンナンバーを上げる。
- makebook extend_treeで"sfen"局面を読み込んだ時に"moves"がついていないなら"moves"を付与する。
■ 2019/06/25
- engine_options.txtでオプションを読み込んだときにハンドラを壊していたの修正
- Stockfish 20190625分まで反映
- makebook build_treeコマンド(テラショック定跡生成コマンド)、駒落ちの各初期局面もroot局面にするように変更。
- これで駒落ちの定跡もビルドできるようになった。
- makebook extend_treeコマンド、"startpos moves .."形式だけではなく"sfen ..."形式もサポートする。
- TOURNAMENT用のビルド、EvalHashの初期値が1024になっていなかったの修正。
■ 2019/06/24
- Makefile、すべてのCPU用のすべてのビルドターゲットをビルドできるように修正する。
- 一つ前のcommitによってclangでコンパイルエラーになっていたの修正。
- movepick.cppのQUIET_INITでskipQuietのときには指し手を生成しない。
cf. http://yaneuraou.yaneu.com/2019/06/24/%e5%b0%86%e6%a3%8b%e3%82%bd%e3%83%95%e3%83%88%e9%96%8b%e7%99%ba%e8%80%85%e3%81%8cstockfish%e3%81%ab%e8%b2%a2%e7%8c%ae%e3%81%99%e3%82%8b%e6%97%a5/
- makebookコマンドでオプションのBookFileで指定されている定跡は読み込まないように改善。
- makebook build_treeコマンドで同一局面の場合、gamePlyが最小となる局面についての情報を書き出すように修正。
■ 2019/06/23
- engine_options.txtを読み込んでいるのにソースコードのコメントでengine_option.txtと書いていた箇所修正。
- EnteringKingRuleがengine_options.txtで反映しなかったの修正
- 入玉ルールまわりの処理、リファクタリング
- extra/entering_king_rule.cpp → position.cppに吸収
- engine_options.txtでoverrideしたときに、Optionのhandlerを呼び出すように修正
■ 2019/06/22
- "engine_options.txt"側でBookFileを指定できなかったbug修正。
- ニコニコ生放送用にmultipvで出力しないオプション追加。
- 定跡ファイルの読み込み中にinfo stringでその旨を出力する。
■ 2019/06/17
- Positionクラス、千日手の処理変更。
- 以前の方法の処理に戻す。
- Android用Makefile , AVX512対応の用意など。 Mizerさんのプルリク(#98)
■ 2019/06/15 V4.87
- include忘れ修正
手元の環境だとコンパイル通るのなんで…。
- V4.87にバージョンナンバーを上げる。
- EvalHashオプション追加
- Position::pseudo_legal_s()の不要なチェックを削除 (#97) Aperyの平岡さんのプルリク(#97)
■ 2019/06/10
- make時のエンジン表示名の指定に対応
- USI_Ponder受けつけてなかったの修正
- benchコマンドがASSERTに引っかかっていたの修正
- ASSERT有効にしたときにコンパイルが通らなくなっていたの修正。
■ 2019/06/09
- ENABLE_OUTPUT_GAME_RESULTまわり、コード整理
- Position::discovered_check_candidates(),pinned_pieces()廃止。
- 計測資料、記述追加、readme.mdに定跡生成手順などの補足
- cuckoo配列の初期化コード追加、Position::has_game_cycle()実装など。
■ 2019/06/07
- 定跡DBの書き出し、必ずsortするように仕様変更。
■ 2019/06/03
- Makefile整理
- プロジェクトファイル整理
■ 2019/06/02
- V4.86にバージョンナンバーを上げる。
- 1つ前のcommitでgccでコンパイルが通らなかったの修正
- build_treeの千日手まわりの処理、修正
- build_treeでビルド時に手数違いの局面にもヒットするように変更
- 定跡の書き出しの時に同一局面の手数違いの局面は、一番手数の若い局面のみを書き出すように変更。
- Position::is_repetition()、遡る手数を引数に追加。説明が間違っていたの修正。
- IgnoreBookPlyオプション導入
- 定跡の出力、multipv 1から正順で出力するように変更
- 定跡で重複局面が登録されていたときに出現率の計算がおかしくなるの修正。
- 定跡の書き出し時に同一局面の手数違いの局面については一番手数の若い局面以外を書き出さないように修正。
// 手数違いの重複局面はOptions["IgnoreBookPly"]==trueのときに有害であるため、plyが最小のもの以外を削除する必要がある。
// (Options["BookOnTheFly"]==true かつ Options["IgnoreBookPly"] == true のときに、手数違いのものがヒットするだとか、そういう問題と、
// Options["IgnoreBookPly"]==trueのときにMemoryBook::read_book()で読み込むときに重複エントリーがあって何か地雷を踏んでしまう的な問題を回避。
- 定跡の読み筋で千日手(rep_draw)の出力
- std::string to_usi_string(RepetitionState rs)追加
- miscにnamespace StringExtension追加。
- MKDIRなどをnamespace Dependencyに入れる。関数名をmkdirに変更。
■ 2019/05/30
- Position::pinned_pieces() obsoleteに。
- 定跡DBに候補手のない局面が登録されているとそこにヒットしたときに落ちていたの修正。(バグ報告、ロタさん)
- ARM向け、コンパイル通らなかったの修正(#94 , Mizarさん)
■ 2019/05/28
- Cuckooアルゴリズムまわりの説明が間違っていたので修正
- Ubuntuでコンパイルが通らなかったのを修正。(Ubuntu 18.04のgccでコンパイルが通ることを確認)
- 32bit環境用のMSYS2でビルドできなかった問題を修正
- mate engine、LONG EFFECT LIBRARYを使用していたの修正
- mate engine , kppt/kkpt評価関数のコンパイルが通らなくなっていたの修正
- V4.85にバージョンナンバーを上げる。
- テラショック定跡の生成部を実装したので、これをリファレンスするためにバージョンナンバーを上げておく
engine1 = YaneuraOu2018NNUE_avx2-v483git.exe , eval = tanuki2018_nnue-best
engine2 = YaneuraOu2018NNUE_avx2git201905280050.exe , eval = tanuki2018_nnue-best
T2,b1000,789 - 105 - 836(48.55% R-10.05) win black : white = 53.42% : 46.58%
- futility move countのコード、新しいコードに差し替え
- book2019.cpp、sjisで保存してたので、コメント文の「機能」の「能」の文字の2バイト目に￥があって、gcc/clangでコンパイルエラーになっていた。utf-8で保存しなおした。
- Lazy SMPでhelper threadをmain threadより先行させるコード、削除
- テラショック定跡部 丸ごと
- StatsEntry 一部を新しいコードに差し替え
- TTEntryのdepth、int8_tからuint8に変更
- timeman、USI_Ponderオプションを考慮するように修正
- EasyMove削除
- LazySMPのvoteの処理、改良
- 探索のtime managementまわり、Stockfish10のコードと差し替え
engine1 = YaneuraOu2018NNUE_avx2-v483git.exe , eval = tanuki2018_nnue-best
engine2 = YaneuraOu2018NNUE_avx2git201905272200.exe , eval = tanuki2018_nnue-best
T2,b1000,459 - 42 - 489(48.42% R-11.0) win black : white = 51.05% : 48.95%
■ 2019/05/27
- seeのコード、きちんと差し替わっていなかった。修正。
- Stockfish10で探索部にperft追加されたのでそちらのperftを使うようにしてtestコマンドのほうのperftのコードを削除
- extra/timeman.cppのフォルダ移動
- main.cpp追加
- move_pick.h/cppをmovepick.h/cppとリネーム
■ 2019/05/26
- searchのコード、むちゃくちゃ整理した
engine1 = YaneuraOu2018NNUE_avx2-v483git.exe , eval = tanuki2018_nnue-best
engine2 = YaneuraOu2018NNUE_avx2-v484git201905251830.exe , eval = tanuki2018_nnue-best
T2,b1000,889 - 111 - 940(48.61% R-9.69) win black : white = 51.67% : 48.33%
■ 2019/05/25
- seeのコード、最新のものに差し替え
- tt.h / tt.cppを最新のコードに
- NO_EVAL_IN_TT廃止
- 置換表にスレッドごとに領域を分ける機能廃止(ソースコード見づらい＆複雑になる＆教師生成時の効果に乏しい)
■ 2019/05/24
- V4.84にバージョンナンバーを上げる。
BookPvMovesを導入したのでこれをリファレンスするためにバージョンナンバーが以前と変わっている必要がある。
アップデート自体はまだ作業中。近日中に残りのアップデートを行う。
- 置換表使用率が最大で99.9%にしかならないのを修正
- makebook thinkコマンドでノード制限の指定が出来るように
- config.hのフォルダを移動させたのでそれに伴う解説文の修正
- 定跡にヒットしたときにその定跡の変化を深くまで出力するように。
- BookPvMovesオプション導入。
- 定跡書き出し時、採択率が同じ場合に評価値で並び替えがされないbug修正。
- MovePicker、少し最新のコードに寄せる
- threadまわり、もう少し最新のコードに寄せる
- Learner::search()は千日手スコアはContemptの値を無視して、0を返すべき。
(スレッドごとにDrawValueを持っていないので複数スレッドから書き換えられると整合性が取れなくて困るため)
- stricmp()自前実装に置き換え
■ 2019/05/23
- config.hからもincludeをなるべく減らす
- ビルド速度upのため、ソースコード大整理
- Learner::search()のnode数制限の実装
- move_picker.hなど、ファイル名をStockfish10になるべく倣う
- 古い評価関数、古いエンジン部をold_enginesに移動
- 古い告知文、削除および過去記事のほうに移動
- WCSC29優勝に関してreadme.md更新
- Visual Studio 2019のためにproject fileのアップデート
- GPLv3のライセンステキスト追加
■ 2019/05/18
Position::set()とPosition::set_from_packed_sfen()でLongEffect::calc_effect()とEval::compute_eval()の呼び出し順を変更 (#93) tttakさん
評価関数で利きを使用する場合を考慮し、LongEffect::calc_effect()を呼んでからEval::compute_eval()を呼ぶように変更
■ 2019/03/04 - 2019/03/18
// これらはWCSC29に向けた作業。やねうら王のGitHubには反映させていない。
// 反映させるのはWCSC29終了後。
- ソースコードをStockfish10に追随する。
- Stockfishになるべく引数の変数名を合わせる。
- ソースコードの比較のときに紛らわしいため。
- move_picker.h/cpp → move_pick.h/cppにrename。
- 今回、Stockfishのソースコードになるべく合わせたファイル
search.h
tt.h
tt.cpp
misc.h
misc.cpp
thread.h
thread.cpp
thread_win32.h
usi.h // 新規ファイル
usioption.cpp // 新規ファイル
usi.cpp // これは、半分ぐらいだけ作業した。残りはまたの機会でいいや。
move_pick.h // ファイル名をmove_picker.h から rename
move_picker.cpp // ファイル名をmove_picker.cpp から rename
- usi.h
std::string score_to_usi(Value v); → USI::value()に移動。Stockfishに合わせる。
Move move_from_usi(const Position& pos, const std::string& str); → USI::to_move()に移動。
- see_ge()のコード、Stockfish10に倣った。
- コンパイルの高速化のためにソースコードの整理。
- Thread::think()廃止。Stockfishに合わせてThread::search()を用いるように変更。
- thread_win32.h を source/extraからsource/に移動。
- shogi.h / shogi.cppを types.h , types.cppにrename。
- source/extra/config.h を source/config.hに移動。
- all.h削除(使ってない＆保守しつづけるの手間)
- ソースコードの単純化のために以下の機能を廃止する。
- NO_EVAL_IN_TT
- 置換表のTTEntryにevaluate()の値を格納しないオプションだが、これ実質的に使っていないので廃止する。
- スレッドごとの置換表
- 教師局面の生成時や教師局面からの学習時などに必要かと思って用意していたが、スレッド数で置換表を分割するために
置換表効率が悪くなるので置換表のエントリーが衝突する損より大きな損を抱えることになる。
- 教師局面生成時に限って言えば、他のスレッドが見つけた詰み筋など、depthが大きなTTEntryは残るので、詰みを回避することで別の
終局図に到達する可能性が高まり、elmo式の勝敗項の偏りを均す働きがあるので、スレッドごとに置換表は持たないほうが良いという見方ができる。
// スレッドごとに置換表を用意する設定
// Learner::search(),Leaner::qsearch()を呼ぶときにスレッドごとに置換表が用意されていないと嫌ならこれを呼び出す。
// この機能を有効にした場合、TT.new_search()を呼び出したときのOptions["Threads"]の値に従って、
// 置換表を分割するのでLearner::search()を呼ぶまでに事前にTT.new_search()を呼び出すこと。
bool use_per_thread_tt;
// 置換表とTTEntryの世代が異なるなら、値(TTEntry.value)は信用できないと仮定するフラグ。
// TT.probe()のときに、TTEntryとTT.generationとが厳密に一致しない場合は、
// 置換表にhitしても、そのTTEntryはVALUE_NONEを返す。
// こうすることで、hash衝突しておかしな値が書き込まれていてもそれを回避できる。
// gensfenコマンドでこの機能が必要だった。
// cf. http://yaneuraou.yaneu.com/2017/06/30/%E3%80%90%E8%A7%A3%E6%B1%BA%E3%80%91gensfen%E3%81%A7%E6%95%99%E5%B8%AB%E5%B1%80%E9%9D%A2%E7%94%9F%E6%88%90%E6%99%82%E3%81%AB%E9%81%85%E3%81%8F%E3%81%AA%E3%82%8B%E5%95%8F%E9%A1%8C/
bool use_strict_generational_tt;
- 教師生成時のeval_limitは設定しない(上限値である32000にする)ほうが良いことが判明したので[tanuki-(WCSC28)]、上の問題は回避できる。
- KKPPTなどの使っていない評価関数
- コンパイル時間の短縮化のため
- help mate engine
- 都度保守していくのが大変なため。いずれ書き直す。
- local game server
- python製の自己対局スクリプトのほうが使いやすいため。
- Stockfishの変更を反映しないクラス
- Positionクラス
Bitboard discovered_check_candidates() const { return st->blockersForKing[~sideToMove] & pieces(sideToMove); }
Bitboard pinned_pieces(Color c) const { ASSERT_LV3(is_ok(c)); return st->blockersForKing[c] & pieces(c); }
→ この２つ無くすと変更が大変なので現状維持で…。(´ω｀)
- 探索部の改良
- razoringのパラメーターを3つから1つに変更。(Stockfish10)
- 探索パラメーターのparam1,param2廃止。この調整の仕方、しない。
- やねうら王独自のコードを明確に区別してわけるようにした。
- 一部の変数はMainThreadに移動させた。
- その他の改良点
- NNUE評価関数の評価関数ファイル読み込み時にエラーになった場合、エンジンを終了するようにした。
- perftコマンド追加。(トーナメントビルド以外)
- Timerクラス、扱う時刻の値はすべてTimePoint型に
■ 2018/12/29
- USE_RANDOM_PARAMETERSをdefineしたときにコンパイルが通らなかったのを修正。
■ 2018/12/21
- misc.cpp : clangでcastのときに警告が出ていたの修正。
■ 2018/11/18
- 8スレ以上のときに対局開始時のメモリのゼロクリアを並列して行うようにする。
- Stockfishのtt.h / tt.cppにある程度追随。
- TT、メモリをresizeで確保しなおしたときにメモリをクリアするように変わった。
- 二重初期化になる。この修正、取り入れないでおこう。
- benchコマンドでTTを二重にメモリ初期化していたの修正。
- MateEngineでもトーナメントモードでのビルドのときは同様の初期化を行うことにした。
===========================
Total time (ms) : 19613
Nodes searched : 11033416
Nodes/second : 562556
■ 2018/11/12
- MateEngineで"go nodes [ノード数] mate XXX"を受け付けるようにする。
- MateEngineで"nodes"と"depth"の指定ができるようにしようと思ったが、USIプロトコル的に対応してなかった。そうか…。
- USI2.0として対応することにした。
■ 2018/11/08
- MateEngineのときにゼロクリアするコード、無効化しておく。
- 置換表のメモリのゼロクリア、進捗を2GBごとに出力するように変更。
- mate engine、Hashの初期化をisreadyokやっていないの修正。
- しかし、ゼロクリアしていないので時間的にはわずかか…。
- VirtualAlloc()で確保されたメモリを実メモリにcommitするためにゼロクリアしたほうが良いような気がするけども、
hash値が衝突してもTTEntryにmoveを保存していないので別に落ちることはないのか…。そうか…。
- "isready"を受け取ったあと、"readyok"を返すまで5秒ごとに改行を送るように修正する。(keep alive的な処理)
USI2.0の仕様より。
> - "isready"のあとのtime out時間は、30秒程度とする。これを超えて、評価関数の初期化、hashテーブルの確保をしたい場合、
> 思考エンジン側から定期的に何らかのメッセージ(改行可)を送るべきである。
> - ShogiGUIではすでにそうなっているので、MyShogiもそれに追随する。
> - また、やねうら王のエンジン側は、"isready"を受け取ったあと、"readyok"を返すまで10秒ごとに改行を送るように修正する。
- "isready"時にhashの確保を開始するタイミングでhash sizeも出力するようにしよう。
- GenAllLegalMovesオプション追加。
- これ、トーナメントモードでは無効化しておく。
- 王手将棋の時のコードが残っていたの削除。
■ 2018/10/04
- BookDirを変更したときに、Aperyの定跡ファイル(book.bin)が読み込めなくなるのを修正。(ohtaroさんの報告) (修正内容の指摘、tttakさん)
cf. https://github.com/yaneurao/MyShogi/issues/57
- フォルダ名を変更したときに、定跡を使わない場合にも"no_book"というファイルを読みに行っていたのを修正。
- misc.hにPathクラス追加。
- C#のメソッド名に合わせる。
- path_combine → Combineにrename
- GetFileName()追加
■ 2018/09/24
- MSYS2上でNNUE型の評価関数の実行ファイルがビルドできない件を解説.txtに追記
- LineScanner、少しリファクタリング。(挙動はほぼ変わらず)
- engine_options.txtの読み込み時にbuffer overrunすることがあったの修正。
- LineScannerのEof()判定、間違っていた。
■ 2018/09/23
- SkillLevel実装。(Stockfishの"Skill Level"を忠実に移植。)
■ 2018/09/15
- tanuki-詰将棋エンジン
- ソースコードにコメント大量追加
- intになっているところ、桁が足りない恐れがあるところはuint32_tに変更。
- uint16_tで済むところはuint16_tに変更。
- info hash..の出力、もう少し細かくやるように変更。
- TTの世代カウンター復活。16bitにする。
- あとは、sub-treeの大きさの評価をきちんとすべき。(現状、num_searchedがsub-treeの大きさを反映していない)
- できればGC実装すべきだと思う。
■ 2018/09/10
- tanuki-詰将棋エンジン , 詰探索中の出力を変更した (#91) (tanuki-さんのプルリク)
* clang++によるコンパイル警告を抑制した
* 詰探索中の進捗状況の出力を変更した
■ 2018/09/08
- tanuki-詰将棋エンジン , clang++によるコンパイル警告を抑制した #90 (tanuki-さんのプルリク)
■ 2018/09/07
- tanuki-詰将棋エンジン , 置換表エントリの世代を削除し、置換表エントリのハッシュの最下位ビットに探索開始局面の手番を入れるようにした #89 (tanuki-さんのプルリク)
- この修正により、一度解いた局面を解かせるときには一瞬で応答が返ってくるようになった。
■ 2018/09/06
- V4.83にバージョンナンバーを上げる。
- 詰将棋ルーチンで受け側の局面から探索させたあとに攻め側の局面から探索させると不詰と出力されるバグを修正した #88 (tanuki-さんのプルリク)
- 詰将棋エンジンハッシュエントリをつぶすとき、探索ノード数を考慮するようにした (#87) (tanuki-さんのプルリク)
■ 2018/08/22
- 詰将棋エンジン、Hashが二重に確保されているのを修正。part2
■ 2018/08/14
- 詰将棋エンジン、Hashが二重に確保されているのを修正。
- Hashに16MBを指定したときに4096MB確保されるの修正。
■ 2018/08/12
- 詰将棋エンジン コンパイル時のwarningを消した (#86) (tanuki-さんのプルリク)
- 詰み手順を復元する探索ルーチンの中で受け手側の手番かつ王手がかかっている状況で1手詰みルーチンを呼び出すバグを修正した #85(tanuki-さんのプルリク)
詰手順を復元する探索ルーチンの中で
受け手側の手番かつ王手がかかっている状況で
1手詰みルーチンを呼び出しているバグを修正しました。
これにより金子清志氏の全応手逆王手最長１５手で
合法な詰手順が出力されるようになりました。
http://www.ne.jp/asahi/tetsu/toybox/challenge/c1090.htm
ただし、最短の詰手順ではありません。
- 逆王手がかかっている局面でも詰みを探索するようにした #84 (tanuki-さんのプルリク)
逆王手がかかっている局面でnotimplementedを返さないようにするオプション、
ReturnNotImplementedIfCheckedを追加いたしました。
デフォルトはtrueで、falseにすると逆王手がかかっている局面でも探索を行います。
- 詰将棋エンジンで制限時間をチェックするようにした #83 (tanuki-さんのプルリク)
詰将棋エンジンで制限時間をチェックするようにいたしました。
GUIからエンジンへ制限時間を設定した上で詰将棋エンジンを解かせる場合は、
USIプロトコル通り
go checkmate 60000
などと指定してください。
制限時間を越えた場合、USIプロトロルにある通り、エンジンからは
checkmate timeout
が返ってくるようになっています。
■ 2018/08/05
- Buildfiles #82 (Mizarさんのプルリク)
* build batches update
- YANEURAOU_2018_OTAFUKU の評価関数タイプをMakefileから選択できるように
- NNUEやMATEエンジンでcleanしきれないゴミが残ってビルド失敗していた部分の対策
- USE_BLAS: tanuki-2018エンジンのevallearnビルドにてBLAS有効化
- LineScannerでpeek_text()したときに文字列終端まで行くと、まだその文字列をget_text()していないのにIsEof()がtrueを返すの修正。
■ 2018/08/04
- 詰将棋エンジンに、より長い詰み手順を返すMorePreciseMatePvオプションを追加した (#81) tanuki-さんのプルリク
■ 2018/08/01
- スレッドstack、100MBに設定してコンパイルしてあるのを25MBに変更。
- 協力詰めで手数が5万手ぐらいになるので大きめである100MBに設定したが、スレッドあたり100MBも消費するので32bit環境ではメモリ割り当て的に厳しい。
(4スレッドであれば待機スレッド含めて5スレッドあり、スタック用だけで500MB消費する。)
- Windows10だとメモリを確保しても、実際にそのメモリにアクセスするまで実メモリに割当てするのは遅延されるが、
Windows7ではそうでもないので馬鹿正直に500MB消費する。つまりは、この理由からWindows7×32bit環境でわりと苦労することになる。
- 32bit環境でUSE_SHARED_MEMORY_IN_EVALを有効にする。
■ 2018/07/29
- "engine_options.txt"で、optionとしてそのエンジンが持っていないものを指定すると先頭のoptionが破壊されるの修正。
■ 2018/07/28
- usi.cpp clangでコンパイルしたときに警告が出ていたの修正。
- 解説.txt にMSYS2環境でのNNUE評価関数のビルド方法追加。
■ 2018/07/27
- 起動時に、"engine_options.txt"を読み込み、Optionsに反映するように。
- エンジンオプションのデフォルト値の変更について、解説.txtに追記
- "BookDir" option追加。
■ 2018/05/27
- Move omp_set_num_threads() call to worker threads (#80) (ynasu87さん)
- NNUEで学習のときにスレッドの分散が適切に出来ないことがある問題の修正。
■ 2018/05/24
- * 連続王手の千日手のチェックを追加した
* 対局規定第8条第7項に従って修正した
* ソースコードのフォーマットを修正した
cf. https://github.com/yaneurao/YaneuraOu/pull/79
(tanuki-さん)
- Mateエンジンで、探索が開始しないバグを修正した(tanuki-さん)
■ 2018/05/20
- 祝！Android公式サポート (#76) (Mizarさん)
- Support NEON for NNUE evaluation functions (#77) (ynasu87さん)
- NEON向けNNUE最適化。
■ 2018/05/17
- StateInfo::capturedPcの説明が間違っていたの修正。
■ 2018/05/15
- Add NNUE evaluation functions (#75) (ynasu87さん)
- この新時代の幕開けとも言える新型の評価関数をマージできることに心に喜悦を禁じえない。
■ 2018/05/07
- MATE_ENGINEでgo mateに対してcheckmateで応答する。(kazu-nanohaさん)
■ 2018/05/03
- 128GB超えの置換表を扱うのはデフォルトでは無効にする。
- config.hでUSE_HUGE_HASHをdefineしたときのみ有効に。
■ 2018/05/02
- 置換表サイズの2^Nという制約を取り除く。(ただし、2MB単位で確保する)
- Allow for general transposition table sizes. (#1341) : https://github.com/official-stockfish/Stockfish/commit/2198cd0524574f0d9df8c0ec9aaf14ad8c94402b
- わずかに遅くなるがそれは棋力にはほぼ影響はないはず…。
- 16GBメモリの環境でHashの値として以前は14000(≒14GB)などと指定しても以前は8192(8GB)までしか使われなかったのが
今回の変更により14000ぴったりまで使われるようになったので、以前より置換表をめいいっぱい確保でき、このおかげで
探索効率が改善して強くなるという効果は期待できる。(長い持ち時間で置換表を使い尽くしているような状況ならば)
例) Hashとして3を指定して1秒対局。以前のバージョンでは置換表は2MBの確保になり、本バージョンでは、3MBの確保となる。)
// TTEntry*を求めるところ
return &table[(((uint32_t(key) * uint64_t(clusterCount)) >> 32) & ~1) | (key & 1)].entry[0];
engine1 = YaneuraOu-2018-OtafukuV482.exe , eval = Apery20171111
engine2 = YaneuraOu-2018-OtafukuV482a.exe , eval = Apery20171111
T1,b1000,618 - 51 - 941(39.64% R-73.04) win black : white = 51.57% : 48.43%
// これだとkeyのbit0が(uint32_t(key))に含まれているので、以下のように改良した
return &table[(((uint32_t(key >> 1) * uint64_t(clusterCount)) >> 32) & ~1) | (key & 1)].entry[0];
engine1 = YaneuraOu-2018-OtafukuV482.exe , eval = Apery20171111
engine2 = YaneuraOu-2018-OtafukuV482b.exe , eval = Apery20171111
T1,b1000,289 - 21 - 510(36.17% R-98.67) win black : white = 50.44% : 49.56%
- 置換表の128GB制限を解除する
- 128 GB TT size limitation : https://github.com/official-stockfish/Stockfish/issues/1349
- このスレッドに書かれている修正案、いくつかの点においてよろしくない。
- cf. 置換表の128GB制限を取っ払う冴えない方法 : http://yaneuraou.yaneu.com/2018/05/03/%E7%BD%AE%E6%8F%9B%E8%A1%A8%E3%81%AE128gb%E5%88%B6%E9%99%90%E3%82%92%E5%8F%96%E3%81%A3%E6%89%95%E3%81%86%E5%86%B4%E3%81%88%E3%81%AA%E3%81%84%E6%96%B9%E6%B3%95/
- singular extension時のhash keyを求めるコード、改良。
■ 2018/05/01
- _blsr_u64()をgccでインライン展開するには-mbmiが必要(-mbmi2ではやってくれない)
kazu-nanohaさんからのプルリクエスト
■ 2018/04/30 V4.82
- ProbCutのパラメーター導入
- PARAM_PROBCUT_MARGIN1 , PARAM_PROBCUT_MARGIN2
- ProbCutのマージン、手で調整する。
PARAM_DEFINE PARAM_PROBCUT_MARGIN1 = 194 + 16/2;
PARAM_DEFINE PARAM_PROBCUT_MARGIN2 = 48/2;
- NUMA環境のマルチスレッド対策。
- 8スレッド未満だと異なるNUMAに割り振られることがあり、パフォーマンス激減するのでその回避策。
- Upon changing the number of threads, make sure all threads are bound : https://github.com/official-stockfish/Stockfish/commit/1c50d8cbf554733c0db6ab423b413d75cc0c1928
- gccだとconstexprをつけたところでエラーになっていたのを修正。
- V4.82リリース
engine1 = YaneuraOu-2018-OtafukuV480.exe , eval = Apery20171111
engine2 = YaneuraOu-2018-OtafukuV482.exe , eval = Apery20171111
T1,b1000,435 - 25 - 540(44.62% R-37.56) win black : white = 49.33% : 50.67%
T1,b2000,440 - 31 - 499(46.86% R-21.86) win black : white = 54.42% : 45.58%
T1,b4000,209 - 19 - 232(47.39% R-18.14) win black : white = 51.93% : 48.07%
T1,b8000,86 - 12 - 112(43.43% R-45.89) win black : white = 46.97% : 53.03%
T2,b2000,93 - 11 - 126(42.47% R-52.76) win black : white = 55.71% : 44.29%
// 時間なくてこれだけしか計測できていないが、V4.80と比べて弱くはなさそうなのでこれをV4.82とする。
■ 2018/04/29
- futility_marginの計算にimproving導入。
- futility_marginのパラメーターの値、変更。143→172
- ProbCutにimproving導入
- ProbCutの指し手の試行回数を3回に制限
- Singular Extensionのコード、少し整理
- IIDの条件式単純化
- Simplifiy IID condition : https://github.com/official-stockfish/Stockfish/commit/d6252ef202f43d42d05b80145f3014da4d22863e
- "PARAM_IID_MARGIN_ALPHA"削除
- Singular Extensionのフラグ変数削除
- Simplify Singular Extension condition : https://github.com/official-stockfish/Stockfish/commit/0cfb653eeca1bc44b9d331498a9ccb3e9b97a9c1
- 置換表をcallocではなくmallocで確保するように変更。
- Explicitly zero TT upon resize. : https://github.com/official-stockfish/Stockfish/commit/2ba47416cbdd5db2c7c79257072cd8675b61721f
- shogi.hなどの定数、可能なところはconstexprに変更。0.2%ぐらい速くなったかも。(計測誤差？)
- Use constexpr when makes sense : https://github.com/official-stockfish/Stockfish/commit/28b6a457c24d9202ba43a6d6703221250f0f8749
■ 2018/04/28 V4.81 (V4.80から+R15～25程度)
- stat_bonus 32倍するの忘れてた。これで元の強さぐらいになった。
- 探索部に、Eloに関するコメント追加。(これはStockfish 9のソースコードのそのまま)
- IIDでttValue代入していなかったの修正。IIDのparameter 256→128に変更。
- fail lowのときにstatScoreをゼロにするように変更。
- RazorMarginのパラメータ、Stockfish 9に合せた。
■ 2018/04/27
- Stockfish 9にキャッチアップのために準備
- 旧エンジン(探索部とmove_picker)をsource/old_enginesにコピー。
- C++14でstd::tr2を使用するとwaring C4996が出るので抑制。
- Visual Studio用の2017GOKUのソリューションを削除
- 使用するWindows SDKのバージョンを10.0.16299.0に変更。
- move_pickerをStockfish 9に準拠。R100ぐらい弱くなった。原因究明中。
- search()、変数を整理した。Stockfish 9に変数宣言をする場所を極力合わせた。
■ 2018/01/25
- ONE_PLYが1以外の場合のinfo depth等を修正(tttakさん)
- やねうら王2018になって、makebookコマンドが有効になっていなかったの修正。
- Makefile、gccがデフォルトになっていたのclangに修正。
■ 2018/01/12 V4.80
- 探索部の改良のために比較実験したときの計測資料公開
- docs/計測資料.txt
- BookIgnoreRateの処理のところでgccだとwarningが出ていたの修正。
- やねうら王2018 with お多福ラボ 公開。このコミットにおいては、SDT5版とほぼ同様。
- やねうら王2017Earlyの探索部をsource/old_engines/ に移動
- やねうら王 V4.80として公開。
■ 2017/12/02
- デバッグ用にqsearch,searchコマンド追加。
■ 2017/12/01
- mate engineがコンパイル通らなくなっていたので修正。(かず@なのはさん)
- mate-search.cppでclangでコンパイルが通らなかったの修正。(かず@なのはさん)
■ 2017/11/25
- 学習部、少し整理
- 学習時の手番のetaを非手番側の1/8に変更。(like Apery)
- ADA_PROP削除
- V_FRACTION_BITS廃止。
- Weight配列をmemsetで初期化するの廃止。
■ 2017/11/23
- learnコマンドに序盤を学習対象から外すオプション追加。(実験中なので現時点では隠しオプション)
- reduction_gameply
■ 2017/11/18
- gensfen2018コマンド追加準備。(現状、非公開)
■ 2017/11/17
- evaluate_kpptの高速化(yuk-toさん) : https://github.com/yaneurao/YaneuraOu/pull/69
- EVAL_MATERIALのときのcompute_eval()やコメントがおかしかったの修正。(tanuki-さん)
■ 2017/11/09 SDT5 version
- KKPP_KPPT型評価関数、学習時の次元下げコード追加。
- learn.hのUSE_KKPP_LOWER_DIMをdefineすると学習時の次元下げが有効になる。
■ 2017/11/08
- learn shuffleコマンド、読み込み中の教師局面ファイル名を出力するように変更。
- maekbook thinkコマンド、保存開始と終了を出力するように変更。
- TT.new_search()やっていたの、無駄なのでコメントアウト。
■ 2017/11/07
- makebook thinkコマンドで定跡の保存間隔を15分単位に変更。
- 保存するときに現在時刻を出力するように変更。
- EvalLearningToolsからmir_piece()とinv_pieceをevaluate_mir_inv_tools.h/.cppに分離。
- USE_FV_VARを定義したときにEVAL_LEARNが必要になるのがおかしいので。(kazu-nanohaさんからの指摘)
- makebook thinkでログ出力のときにsync_coutを使っていなかったの修正。
- EvalLearningToolsからmir_piece()とinv_pieceをevaluate_mir_inv_tools.h/.cppに分離その2。
- learning_tools.h/.cppのほうcommit忘れていたの修正。
- Visual Studioのソリューションで古いexeフォルダを含んでいたの修正。
■ 2017/11/06
- evaluate_nabla2実装準備
- gensfenコマンドのときに生成されるファイル名をランダムな名前にするオプション追加。
- AWSで複数インスタンスを立ち上げるときにstartupのスクリプトのなかでgensfenコマンドを実行したいため。
- bookcheckコマンド、4手目までは枝刈りを甘く変更。
- position.hにEVAL_NO_USEが残っていたのなど修正。(kazu-nanohaさん)
- thread.cppでUSE_ENTERING_KING_WINがdefineされていないときにMOVE_WINを指し手候補に入れていたの修正。
■ 2017/11/04
- "makebook think"コマンドで指し手で1手生成ごとに通し番号を出力することにした。
- time management、極やねうら王向け調整。
- 学習部、omp parallel の中で omp parallel for をするのは無駄(kazu-nanohaさん)
- cf. https://github.com/yaneurao/YaneuraOu/pull/67
- gensfenコマンドで生成されるファイルの分割保存のためのsave_everyオプション追加。
- AWSのspot instanceのterminate対策。
■ 2017/11/02
- "test bookcheck"コマンドの説明、ソースコード上に追記。
- "test bookcheck"のときに評価値が低くなった時点で枝刈りをするコード、追加。
- "makebook think"コマンドで指し手で1手生成ごとにthread idとタイムスタンプを出力するようにした。
■ 2017/10/31
- KPP_KKPT_FV_VAR公開。KPP_KKPTのUSE_FV_VAR(可変長EvalList)を用いたリファレンス実装。
- KPP_KKPT型に比べてわずかに遅いが、拡張性が非常に高く、極めて美しい実装なので、
今後、評価関数の拡張は、これをベースにやっていくことになると思う。
- 来年以降、可変長EvalListが主流になると思う。
- EvalIO、評価関数の型が違うときの変換コード、修正。
- nabla対応コードその1。
- nabla対応コードその2。
■ 2017/10/29
- EVAL_NO_USE廃止につき、evaluate_no_eval.cpp削除
■ 2017/10/28 V4.79
- FV38のコード、少し整理。
- Position::put_piece()整理
- Position::update_kingSquare()追加。
- Position::put_piece() refactoring
- EVAL_NO_USE , 削除
- ss->plyの意味を変更したときに詰みまでの手数が1手短く出力されるようになっていたのを修正。
- EvalList::is_valid()追加。
- USE_FV_VARのときの更新処理、benchの値が一致するところまでは進めた。
- DirtyPieceをevaluate.hに移動
- FV_VAR方式のとき、Position::do_move()ではこのDirtyPieceのほうを更新することに変更。
- VALUE_NOT_EVALUATEDの値が小さすぎたの修正。
- FV_VAR方式のpiece_listのデバッグ完了。無事動いた。
- Position::set()にゴミの行があったの修正。(thx.ishidakeiさん) : https://github.com/yaneurao/YaneuraOu/issues/64
- gensfenコマンドでrandom_move_minplyとして-1を指定すると定跡を抜けたあと連続したランダムムーブになるようにした。
- 連続対局、二度目で落ちる件、修正。
- 定跡で採択率0の指し手が採用される件、修正。(thx.tanuki-さん) : https://github.com/yaneurao/YaneuraOu/issues/65
- Aperyの定跡ファイル読み込み時に、すべての指し手の採択回数が0のときに0割になる件、修正。(thx.tanuki-さん) : https://github.com/yaneurao/YaneuraOu/issues/65
■ 2017/10/27 V4.78
- Let ss->ply denote the number of plies from the root to the current node : https://github.com/official-stockfish/Stockfish/commit/ba4e215493de31263b9bd352af79d00193e545bf
- Don't score as an immediate draw 2-fold repetitions of the root position : https://github.com/official-stockfish/Stockfish/commit/6d89d0b64a99003576d3e0ed616b43333c9eca01
- Position::is_repetition()の引数の意味が変更になるので注意！
- Position::set()の引数の仕様が変更になるので注意！
- Positionのコピーコンストラクタ、削除。
- Position::startState廃止。
- Position::set_hirateでStateInfo*を要求するように変更。
- goコマンドのときに探索開始局面までの手順を考慮していなかったのを修正。(千日手判定などに影響)
- ここまでをV4.78としてリリース。
- BonaPiece inverse hack、revertする。可変長piece_listを導入準備。
- 可変長piece_list、KPPTに対応。KPP_KKPTは半分ぐらい対応。
■ 2017/10/26
・EvalLearningTools、small refactoring。
・KKPPT追加準備。
・KKPPTのコードその1。とりあえずKKPP_KKPTからportingしてきた。AVX2用コードまだ。
・KKPPTのコードその2。AVX2用コードをKPPTからporting。とりあえずコンパイル通ったところまで。
・KKPP_KKPTのコードその9。SSE4.1用のコンパイルが通らなかったの修正。
・KKPPTのコードその3。SSE4.1用のコードのコンパイルが通らなかったの修正。
・KPP_KKPT/KKPP_KKPTについて後手玉が移動したときのKKPの計算、古いコードになっていたのを修正。
・KKPPTのコードその4。KPPTからの変換部のバグ修正など。
・KPPT、small refactoring。
・KKPPTのコードその5。evaluate()でeval hashにhitしたときのバグ修正など。
・KKPPTのコードその6。学習部のfreezeオプション対応。
■ 2017/10/24
・EvalLearningToolsを大改造したときに残ってたバグ修正。
・KKPP_KKPTのコードその6。学習部の初期化のバグ修正。なお、まだ何かバグっている模様。
・KKPP_KKPTのコードその7。学習部のバグ修正。
・KKPP_KKPTのコードその8。学習部の定数定義修正。
■ 2017/10/23
・KKPP_KKPT対応。evaluate_kkpp_kkpt/ 追加。
・KKPP_KKPTのコードその1。KKPPを使う部分のコードとload/save()と学習部がまだ。
・EvalLearningTools::KK,KKP,KPPの設計変更。自由に組み合わせられるようにした。大改造になった。学習部、何かバグがあれば教えて欲しい。
・KKPP_KKPTのコードその2。load()/save()実装,KPP_KKPTからの変換関数を用意。
・KKPP_KKPTのコードその3。evaluate()のほう、KKPP配列を用いるように変更。変換関数のバグ取った。ミラーの処理、削除。
・KKPP_KKPTのコードその4。KKPPで用いるkkのencode/decode関係のコードを整理。
・KKPP_KKPTのコードその5。学習部を書いた。ただし未デバッグ。
■ 2017/10/22
・EvalLearningTools::KKPPクラス追加。
■ 2017/10/21
・EVAL_NABLA実装準備。
・EVAL_KPP_KKPT、少し高速化。
■ 2017/10/20
・EVAL_KPPP_KKPT、KPPPの計算を行なう駒の開始番号を指定できるようにした。
■ 2017/10/17
・EvalLearningToolsなど少しリファクタリング。
■ 2017/10/16
・学習部、SGD_UPDATEを指定したときにコンパイルが通らなくなっていたの修正。
・SGD_UPDATEのときに乱数使うのやめる。
■ 2017/10/15
・helices対応その2。
・PieceNo型、NO(ノー)と紛らわしいので、PieceNumberとrenameする。
■ 2017/10/14
・evaluate_helices、追加準備。
・4駒系の学習部のバグ修正。add_gradするときのindex壊してたっぽい…。
■ 2017/10/13
・BonaPiece inverse hackのための改造その1。たぶん数%速くなる程度なので残りはSDT5が終わってから実装することにする。
・KPPPT/KPPP_KKPT型評価関数を公開。差分計算実装していないので使い物にならない。ソースコードの参考用。
・learnコマンドでrandom_multi_pv == 0は、multi_pv無効の意味になっているべきなのでそういう扱いにする。
・learnコマンドでrandom_multi_pv == 1は、multi_pv無効ではなく、multi_pv == 1の意味に変更する。
・learnコマンドのrandom_multi_pvのデフォルト値を0に変更する。
■ 2017/10/06
- Stockfish
- Tweak statScore condition : https://github.com/official-stockfish/Stockfish/commit/0e949ac2c956dc5ac03dc9da7050d895b3fb964a
- Measure nodes after search finished. : https://github.com/official-stockfish/Stockfish/commit/c33af32dada1be9f6aed851e8cf87599203e2eb2
- Decrease reduction for exact PV nodes : https://github.com/official-stockfish/Stockfish/commit/07b5a28a68b4cc67f1447fce85fc910aa209b319
■ 2017/10/03
・EvalLearningTools::KPPPのクラス、少しリファクタリング。
・EvalLearningToolsのinverse_→inverse_sign , adjust_grad→apply_inverse_signにrename。
■ 2017/09/30
・KPP_KKPTのlearnerのupdate、toRawIndex()を使って書きかえ。
■ 2017/09/28
・探索パラメーターの自動調整のコード、コンパイルが通らなくなっていたのを修正。
・EvalLearningTools::KPPPのkingをint型に変更。
■ 2017/09/27
・setoptionコマンドでstring型に対して空の文字列を設定できるように変更した。("EvalDir"などに対して空の文字列を設定したいことがあるため)
・EvalLearningTools::KK,KKP,…に、toRawIndex()導入。
■ 2017/09/24
・kpp_kkpt評価関数をAVX2でVPGATHERDDを使うようにして高速化。(tanuki-さん)
■ 2017/09/17
・探索の調整パラメーターにPARAM_ASPIRATION_SEARCH_DELTA追加。
・update_cm_stats→update_continuation_historiesにrename。
・Stockfishにcatch up。
- Move depth calculation in probCut : https://github.com/official-stockfish/Stockfish/commit/f907d5b7d93a161bc88aeaec403631de9de092f9
- これはspeed upしない、間違った理解に基づくcommitなので反映させないことにする。
- Adjust moveCount history only at LMR : https://github.com/official-stockfish/Stockfish/commit/7b4c9852e1421ebe6ec326c38f04ad575ad91053
- これはすでにやっていた。
- Use moveCount history for reduction : https://github.com/official-stockfish/Stockfish/commit/5ef94eb970bc1e4f95ebc13ec2c31b191ea46f87
- この後に変更が来てた。
・実験中
- statScoreによる延長
- Evasion Pruning Tweak : https://github.com/official-stockfish/Stockfish/commit/1d31065e1d1f04ecf47fc959523c560e8657fbfa
- Increase reduction if tt-move is a capture : https://github.com/official-stockfish/Stockfish/commit/77342126d8417469bd6a398cfc6c0594b1f02f82
■ 2017/09/15
・KPPPT対応。(しばらく非公開)
・miscにあるinsertion_sort、昇順になってなかったの修正。(降順になっていた)
■ 2017/09/14
・SkipLoadingEvalがtrueのときに読み込みが失敗した一つ目のファイルにしかエラーを出力しなかったのを修正。
・learnコマンド時の評価関数メモリのcorruptチェックを省略するように修正。
・MultiThinkでcorrputチェック、フラグの指定間違えてたの修正。
・learnコマンド時のrmse計算用の局面数を1000から2000に変更。
■ 2017/09/13
・learnコマンドで学習時に、教師局面との指し手一致率を出力するようにした。
・python用の学習ログ解析スクリプトを新ログ形式に対応させた。
■ 2017/09/11
・"test evalsave"コマンド追加。
■ 2017/09/10
・learnコマンドでcheck sumが一致せず、corrupt checkに引っかかることがあるのを修正。
・Stockfishの最新版にcatch upその1。
- Small simplication of see_ge() : https://github.com/official-stockfish/Stockfish/commit/741523eda8e0d1fb418d579c7cda9a73040b8914
- Fix uninitialized memory usage : https://github.com/official-stockfish/Stockfish/commit/e385f194e970f0675bd4c3509bca4a6c81b6df5e → スレッドのコード整理したときにすでにやってた。
- Simplify away non-normal moves in SEE … : https://github.com/official-stockfish/Stockfish/commit/bf485f4affc37cd408a65b66b8a3aad059bad5f3 → 将棋で関係なかった。
- Improve multi-threaded mate finding … : https://github.com/official-stockfish/Stockfish/commit/d5f883ab29d43b35746ff605cf13c3722df56041
- PER_STACK_HISTORY削除
- PER_THREAD_COUNTERMOVEHISTORY削除
- USE_MOVE_PICKER_2017Q2削除。move_picker.h/cppを./に移動。
// 以上、探索結果には影響がないので棋力は向上してない。(わずかに速度が速くなっているかも知れないが計測できるレベルではない)
・Stockfishの最新版にcatch upその2。
- Avoid constructing an empty tuple in qsearch … : https://github.com/official-stockfish/Stockfish/commit/002bf4d8dbf804ce8303e01733341a0922af2e71
- Collect more corrections to optimum/maximum : https://github.com/official-stockfish/Stockfish/commit/daf0fe1f57337d33f9e0af5a8aa8ef0868b20417 → 指し手を時間の10ms前で判定するのやめた。
- Clarify stats range : https://github.com/official-stockfish/Stockfish/commit/9c35b9365d75a3522cee47536419534b1de91f48
- Fix involuntary conversions of ExtMove to Move : https://github.com/official-stockfish/Stockfish/commit/d482e3a8905ee194bda3f67a21dda5132c21f30b
- Unify stats update() : https://github.com/official-stockfish/Stockfish/commit/9001f55147fa304223623a6de0025ffe79f5fcc3
- Use int16_t in History values : https://github.com/official-stockfish/Stockfish/commit/ae6a4ebf1f44cb05e96f8f33342ec281b41b0cc0 → すでにやってた
- Fix incorrect StateInfo : https://github.com/official-stockfish/Stockfish/commit/232c50fed0b80a0f39322a925575f760648ae0a5 → すでにやってた
- Thread code reformat : https://github.com/official-stockfish/Stockfish/commit/df6cb446eaf21c5d07bbd15496da0471aff6ab3f → すでにやってた
- Retire States global variable : https://github.com/official-stockfish/Stockfish/commit/bdeda52efd55c97d0f5da908267c01f973371e5d → すでにやってた
- Simplify finished search in ponder/infinite mode. : https://github.com/official-stockfish/Stockfish/commit/2783203428300cf0a6305b64691ad38fa340f253 → すでにやってた
- Re-apply the fix for Limits::ponder race : https://github.com/official-stockfish/Stockfish/commit/66c5eaebd8c3ecc00a21a9c7f214cb59db4ce4e5
- Fix a race on Limits::ponder : https://github.com/official-stockfish/Stockfish/commit/5410424e3d036b43715c7989aa99e449cdcde18e → これはこのあと修正がある。
- ponder_modeのフラグをreceived_go_ponderとリネーム。Threadsに移動。
- ss->statScore初期化していなかったの修正。(あとのnodeで使ってなかったので探索には影響なさげ…)
- StatBoardsのリファクタリング。
- move_pickerのリファクタリング。
- ソースコード上のStockfishのcommitに対するリンクに、タイトル名を追記。
・Stockfishの最新版にcatch upその3。
- Fix some races and clarify the code : https://github.com/official-stockfish/Stockfish/commit/750dfa0521472e86c67f870fe7ca413d670cafe2 → uiThreadを作るところは採用せず。
- Make variable naming consistent : https://github.com/official-stockfish/Stockfish/commit/dbc984d9f87ba79db3c7802310450f60e95e89e4
- Unify scoring functions in MovePicker : https://github.com/official-stockfish/Stockfish/commit/f731bcadb7908f03c42e3d63fefe82552f09c926 → move_picker整理したときに、すでにやってた
- Remove Stack/thread dependence in movepick : https://github.com/official-stockfish/Stockfish/commit/b40e45c1cc51bd228898314264d6d241478b23d8
- Remove redundant if-statements : https://github.com/official-stockfish/Stockfish/commit/722e1e0da6187916d76a2663f98ac105bc620763 → すでにやってた
- Simplify aspiration window : https://github.com/official-stockfish/Stockfish/commit/a6ae2d3a31e93000e65bdfd8f0b6d9a3e6b8ce1b → すでにやってた
- Provide selective search depth info for each pv move : https://github.com/official-stockfish/Stockfish/commit/377d77dbe922b99ee34d686e4fe180698a9b535a → すでにやってた
- Move stop signal to Threads : https://github.com/official-stockfish/Stockfish/commit/36a93d90f76d32e16a5f2acb09b7de2d67225021 → すでにやってた
- Don't uselessy share rootDepth : https://github.com/official-stockfish/Stockfish/commit/802fca6fdd562c4c52397521eb0ac05cb2be9046 → すでにやってた
- Only main thread checks time : https://github.com/official-stockfish/Stockfish/commit/05513a66410f96959f3a6e70be9aea72425cf7c7 → すでにやってた
- コメント上でlazySMPなどとなっていた箇所を"Lazy SMP"と表記を統一した。
■ 2017/09/09
・go infiniteで詰みを見つけて探索が終了したときのbusy waitのコードとコメントを整理した。
・ソースコードのコメントでSignals.stopになっていたところをThreads.stopに修正。
・トーナメント版と通常版とでcheck sumの値が異なるときがあったの修正。(SurfLaprasさん)
・評価関数の読み込み後の補正処理をlearnコマンド実行時に移動させた。(checksumが変化してしまうので)
・check sumによるソフト名判定にソフト追加。
・endiannessを考慮してcheck sumの計算ルーチンを修正。これにより、check sunの値が変わってしまったが仕方ない。
・各種評価関数のchecksumを追加(SurfLaprasさん)
・EvalLearningTools::KPPP単純化した。
・ThreadクラスとStateInfoクラスにcustom allocator導入。
・gensfenコマンドでdepth 10以上のときに極稀に落ちていたのを修正。
■ 2017/09/09 V4.77
・V4.77リリース。
・今回はASSERT無効にしておく。(不評だったので)
・しかしASSERTに引っかかったからこそ、PV表示のバグが見つけられたので無効にするのは個人的には気が進まないのだが…。
■ 2017/09/09
・Threadのコード、最新のStockfish風に変更。
・ThreadPool、最新のStockfish風にリファクタリング。
・Threadの終了、デストラクタで書くように変更。
・Threadの変更に合わせてponderの処理など、書き換えた。挙動が何かおかしければ報告欲しい。
・MultiPV時に"go infinite"～"stop"を繰り返すと、PVの出力時に落ちることがあったのを修正。このbugはStockfishのほうでもおそらく存在する。
■ 2017/09/07
・KK_INVERSE_WRITE時にKK[sq][Inv(sq)][0]==0を保証するように修正。
・SkipLoadingEvalの仕様変更。ファイルが存在しないときはゼロクリアされたファイルを読み込んだことにする。
・insertion_sortのコードをmisc.hに追加。
・ASSERT無効をデフォルトに変更。
・EVAL_KPPP_KKPTのときにEvalShareオプションが使えなかったの修正。
■ 2017/09/06
・EVAL_MATERIALのときのBonaPieceのdefineを他のものと統合。
・EVAL_KPPP_KKPT関連のコード少し書いた。
・gensfen時のuse_eval_hashのあとの表示で改行忘れ修正。
・EVAL_KPP関連のコード削除。
・learnコマンドのfreeze周り、整理した。EVAL_KPPP_KKPT周り、少し書いた。
■ 2017/09/05
・VALUE_MAX_EVAL、少し上げて、27000に変更。これでもまだevaluate()の返し値が超えるときがありそう。
・Makefile、OpenMPをインストールしていないclang環境用に少し修正。
・evaluate絡みのファイル、整理およびリファクタリング。
・KPP(手番なし)型評価関数、削除。評価関数まわりのリファクタリング。
・progress.h/cppを削除。(資料館に移動)
・eval/kppt/ , eval/kpp_kkpt/ を作成。eval関連のソースコード整理。
・evalフォルダ整理。evaluate_learn_kppt.cppをevaluate_kppt_learner.cppとリネームなど。
■ 2017/09/04
・EvalLearningTools::KPPPのfromIndex()で3次方程式の解の公式間違ってたの修正。
・EvalLearningTools::KPPPのfromIndex()、数式自体は修正できた。しかし、計算誤差で計算が合わない。
・EvalLearningTools::KPPPのfromIndex(),toIndex()、UnitTest通った。
■ 2017/09/03
・KPP_PPT型のソースコード、破棄。
・EvalLearningTools::KPPTのコード書けた。(計算が合ってる自信なし)
■ 2017/09/02
・KPP_KKPT型評価関数ビルド公開。
・rezero KPP_KKPT epoch4公開。
・Msys2環境にてclangでOpenMPを有効にしてビルド出来るようにmakefileを修正。(たまさん)
■ 2017/09/01
・EvalLearningTools::KPPP半分ぐらい書いた。
・KK,KKPのinverseの計算、間違ってたような気がするので修正した。(気がする)
■ 2017/08/31
・KK,KKPの次元下げのコード、害はなさそうなのですべてオンをデフォルトと変更する。
・EvalLearningTools::KPPクラスにis_inverse()追加。
・V_FRACTION_BITS、32bit,64bitを用意。
・SGDで学習させるときのvの値の絶対値をAdaGradのときと同様にした。
・EvalLearningToolsの初期化コード、整理した。
■ 2017/08/30
・clangでlearn版(OpenMPを使用)のビルドが通るようにMakefileを修正した。(たまさん)
・USE_KK_MIRROR_WRITE、USE_KK_INVERSE_WRITE実装。
・USE_KKP_MIRROR_WRITE、USE_KKP_INVERSE_WRITEの両方のシンボルが定義されていないときの処理が間違っていたの修正。
KKの次元下げのコード、間違っていたの修正。
・KK,KKP,KPPの次元下げのコード、リファクタリングした。
■ 2017/08/29 V4.76
・V4.76公開。
■ 2017/08/28
・freeze_kkpの処理、間違ってたの修正。
■ 2017/08/27
・KPPの手番なし(KK,KKP手番あり)型評価関数 EVAL_KPP_KKPというのを実装した。学習部も一通り書けた。
・エラー時の終了処理、3秒待つようにした。
・"test evalconvert"で変換できる評価関数の型にkpp_kkpt32型を追加。
・SkipLoadingEvalオプションの説明追加。EVAL_LEARNがdefineされていればこのオプションが使えるようにした。
・learnコマンドのwithout_kppをfreeze_kppに変更。freeze_kk,freeze_kkpも追加。
・学習時のwの値の範囲を16bitぎりぎりの値まで許容するように変更。
・学習時のwの値の範囲をKK/KPPが32bitなら32bitの値を許容するように変更。
・kpp_kkpt評価関数のAVX2化(tanuki-さん)
■ 2017/08/26
・learnコマンドにKPPを学習させないオプション設定追加。
・learnコマンドにeta2,eta3,eta1_epoch,eta2_epoch導入。
・KPPの手番なし(PP,KKP手番あり)型評価関数 EVAL_KPP_PPT、1/3ぐらい書けた。
■ 2017/08/19
・gensfenコマンドにuse_eval_hashオプション追加。
・benchコマンド連続して2回叩くとassertに引っかかっていたの修正。
■ 2017/08/17 V4.75
・learnコマンドで割引率discount_rateを指定できるようにした。
・evalstatにKKのKの値を出力する実験的コード追加。
・実験的に"test regkk"コマンド追加。
■ 2017/08/14
・学習時のnormの出力に対応。
・USE_KKP_INVERSE_WRITE実装
・学習時にPVの各nodeで勾配を加算する実験コード追加。
■ 2017/08/08
・evaluate_kppp.cppのソースコード上のコメントがおかしかったの修正。
■ 2017/08/02
・SkipLoadingEvalオプション追加。(隠し)
・evalstatコマンドでUSE_EVAL_MAKE_LIST_FUNCTIONが有効のときにもう少し情報を細かく出力するようにした。
・EvalLearningToolsのmir/invの計算にassert追加。
・EvalLearningToolsの初期化は起動後1回限りにするコード追加。同init()時にメッセージを出力するように変更。
・EvalShareで4GB以上の評価関数を共有できなかったバグ修正。
■ 2017/08/01
・mir_piece、inv_piece初期化時のcallback関数を設定できるようにしたなど。
・2GB以上の評価関数を扱うための拡張。
・evaldir変更してからのisreadyで評価関数ファイルを読み直さないのを修正。
・EvalSumなどに比較演算子追加。
・評価関数の差分計算、KKPの値が回転対称であることを前提としていたコード、修正。
(elmoではその仮定が出来るので問題ないが、やねうら王の学習部はその次元下げはやらないことにしていたので問題がある。
あまり表面化しないはずではあるが…。)
・EvalIOでのファイルの入出力にmisc.hにあるファイルの入出力を呼び出してなかったの修正。
・read_file_to_memory、callback関数内でnullptrを返したときにエラーリターンするように変更。
・評価関数などのファイルのサイズが想定サイズと異なるときは読み込みをリタイアするように変更。
■ 2017/07/31
・学習時のVの小数部のbit数、learn.hで8と16を選べるようにした。デフォルト16に変更。
・learn時の三角配列化、バグがないか検証コード追加した。
■ 2017/07/30
・USE_TRIANGLE_WEIGHT_ARRAYをdefineしたときにコンパイルが通らなかったの修正。
・USE_KKP_MIRROR_WRITE、USE_KPP_MIRROR_WRITEのオプション追加。
■ 2017/07/28
・Stockfish : Remove redundant if-statements
cf. https://github.com/official-stockfish/Stockfish/commit/722e1e0da6187916d76a2663f98ac105bc620763
■ 2017/07/26
・learnコマンドのwrite_minply、1 originに変更。
■ 2017/07/24
・elmo式にlambda2,lambda_limitを追加。
・LOSS_FUNCTION_IS_YANE_ELMO_METHOD削除。
・Stockfish : Simplify aspiration window
- cf : https://github.com/official-stockfish/Stockfish/commit/a6ae2d3a31e93000e65bdfd8f0b6d9a3e6b8ce1b
■ 2017/07/22
・option value check: int -> long long (#58) (Mizarさん)
■ 2017/07/21
・tanuki-(WCSC27)のcheck_sumの値を修正 (#57) (tttakさん)
■ 2017/07/20
・Optionクラスが内部的に保持する値をs64化したときにVC++でのコンパイル時に警告出ていた箇所を修正。
・GlobalOptions.use_strict_generational_ttの挙動変更する。
■ 2017/07/19
・gensfenコマンドにrandom_move_like_aperyオプション追加。
・gensfenコマンドにwrite_minply,write_maxplyオプション追加。
・gensfenコマンド、gcc+AVX2だとアクセス違反で落ちていたの修正。aligned_vector追加。
・kifconvert wip20170719b (#55) (Mizarさん)
・エンジンオプションによる探索制限 #56(Mizarさん)
・long long→s64に変更。DepthLimit,NodesLimitの件をUSI拡張コマンド.txtに追記。
■ 2017/07/18
・gensfenまわり、ソースコード少し整理。
・foreach_eval_param、KPPのところ、KKPを調べてたの修正。
"test evalexam"コマンドの結果に影響あり。
・gensfenのときにEVAL_HASH無効化する。
・PRNG、AsnycPRNGのoperator<<(std::ostream& os)、16進数表示に変更。
■ 2017/07/17
・gensfenコマンドの処理、リファクタリング。
・宣言勝ち周り、リファクタリング。何かバグってたらごめん。
・gensfenのときに乱数seed表示するようにしたなど。
・ConsiderationModeがオンのとき、PVを置換表に書き戻す処理を入れているが、それをメインスレッドでしか行わないようにした。など。
・insert_pv_to_tt()のコード、少し修正。
・insert_pv_to_tt()自体、lazySMPと相性悪いので削除する。読み筋が途切れるなら置換表を大きく確保してもらうしか。
■ 2017/07/16 V4.74
・評価関数分解エンジンの実装 (#54) (Qhapaqさん)
・"test evalresolve"コマンドの説明追記
- Makefile元に戻す
- reformatting
- VC++で警告出ていたのを修正
・"test evalmerge"コマンドにfeatureオプション追加。(隠し)
■ 2017/07/15
・EvalShareオプション、異種評価関数との自己対局のときにこの設定で引っかかる人が後を絶たないのでデフォルトでオフにする。
・learn.h/cpp整理
- gensfenのときにPV lineのleaf nodeでevaluate()した値を用いることに変更。
- LEARN_GENSFEN_DRAW_RESULT → LEARN_GENSFEN_USE_DRAW_RESULTに名前変更。
- gensfenまわりのソースコード整理。
- learnコマンドでもshallow valueとしてPV lineのleaf nodeでのevaluate()の値を用いるように変更。
■ 2017/07/14
・"test evalexam"コマンド、KK,KKP,KPP別の集計を行なうように変更。
・Stockfish : Move stop signal to Threads
- cf. https://github.com/official-stockfish/Stockfish/commit/36a93d90f76d32e16a5f2acb09b7de2d67225021
・"bench"コマンド実行時にOptionsを破壊していたので復元するようにした。
・MultiThinkのOptionsの復元のコードが良くなかったので修正した。
・Stockfish : Move stop signal to Threadsその2
- 2017Early以外の思考エンジンに対しても修正。
・Stockfish : Provide selective search depth info for each pv move
- cf. https://github.com/official-stockfish/Stockfish/commit/377d77dbe922b99ee34d686e4fe180698a9b535a
- スレッドごとにselDepthを出力できるようになった。
- selDepthの初期化忘れ修正。
■ 2017/07/10 V4.73
・gensfenのUSE_RANDOM_LEGAL_MOVE、常に有効でいいので削除。
・kifconvert wip20170710a (#51) (Mizarさん)
・kifconvert fix (Mizarさん)
・MultiPVが1以外のときに詰みを発見すると探索が終了してしまうバグ修正。
・random_multi_pv_depth追加。
■ 2017/07/09
・gensfenコマンドにrandom_multi_pv_diffオプション追加。
・test mergeコマンドにkkptオプション追加。仮想的にpp手番にする実験コード追加。
・learn shuffleコマンドにbuffer_sizeオプション追加。
・Makefile BOMをなしに変更。
BOMありだとMacでビルドしたときにLLVM8.1とgcc7.1でmissing separator errorになるらしい。
■ 2017/07/08
・GCC 7.1.0での警告に対する修正。BitboardとEvalSum。
■ 2017/07/07
・GCC 7.1.0での警告に対する修正。(Mizarさん)
■ 2017/07/06
・Stockfish : Tidy up
cf. https://github.com/official-stockfish/Stockfish/commit/6d24ef8585c2ed5618eb9b4ab1d8ee35a05ce2cd
InFrontBB→ForwardRanksBBにリネーム。
・Stockfish : Don't uselessy share rootDepth
cf . https://github.com/official-stockfish/Stockfish/commit/802fca6fdd562c4c52397521eb0ac05cb2be9046
・Stockfish : Use unsigned int for nodes in Limits.
cf . https://github.com/official-stockfish/Stockfish/pull/1163/files
・makebook thinkコマンド、エンバグしていたの修正。
MultiPVで使うときに、2手目以降の評価値が-32001になっていた。
■ 2017/07/05
・"test evalmerge"コマンド、リファクタリング。
・Pieceのデバッグ出力のたときに漢字を2バイトと仮定していた部分、修正。
■ 2017/07/03
・gensfenのときにファイルのflushを一定書き出しごとに行なうようにした。→ 間違い。なってた。
・see_ge()の変数名のリネーム。
・一つ前のgensfenのflushをrevert。
■ 2017/07/02
・Position::do_move()に指し手としてMOVE_RESIGNを渡すといけないのでassert追加。
・Stockfish : Only main thread checks time
cf. https://github.com/official-stockfish/Stockfish/commit/05513a66410f96959f3a6e70be9aea72425cf7c7
・Stockfish : Fix four data races.
cf. https://github.com/official-stockfish/Stockfish/commit/3cb02004596f868ae405b09fbf3a2038a680a989
・Position::nodes_searched()削除
・Threads.init_for_slave()削除。
・search()のときに千日手判定でrootの局面以前まで遡っていなかったの修正。
・Learner::search()をスレッドごとのmulti pvに対応させた。
・gensfenコマンドにrandom_multi_pvオプション追加。
・Position::set_this_thread()廃止。set()などのときなどにthread指定するようにした。
・makebookコマンドなどさきほどの変更に伴って動かなくなっていたの修正。
・以下のプロジェクトを削除。(保守しきれないため)
#define YANEURAOU_NANO_ENGINE // やねうら王nano (完成2016/01/31)
#define YANEURAOU_NANO_PLUS_ENGINE // やねうら王nano plus (完成2016/02/25)
#define YANEURAOU_MINI_ENGINE // やねうら王mini (完成2016/02/29)
#define YANEURAOU_CLASSIC_ENGINE // やねうら王classic (完成2016/04/03)
#define YANEURAOU_CLASSIC_TCE_ENGINE // やねうら王classic tce (完成2016/04/15)
#define YANEURAOU_2016_MID_ENGINE // やねうら王2016(MID) (完成2016/08/18)
#define YANEURAOU_2016_LATE_ENGINE // やねうら王2016(LATE) (完成2016/10/07) : 真やねうら王
#define CHECK_SHOGI_ENGINE // やねうら王 王手将棋 (完成2016/11/30)
#define MUST_CAPTURE_SHOGI_ENGINE // やねうら王 取る一手将棋(完成2016/12/04)
#define RANDOM_PLAYER_ENGINE // ランダムプレイヤー
王手将棋と取る一手将棋はいずれ最新のエンジン部で実装しなおす。
ソースコード自体は、参考用にsource/old_engines/に移動。
■ 2017/06/30
・BonaPieceを32bitに固定することにした。(理由はshogi.hのBonaPieceのところにコメントとして書いた)
・learning_tools.hの型キャスト、ちょっとお行儀が悪かったので少し書き直した。
・gensfenでeval_limitが小さいときに生成が次第に遅くなることがあったのを修正。(報告をしてくださった、滝澤さん、まふさんに感謝！)
・GlobalOptions.use_strict_generational_tt追加。
・スレッドごと置換表確保などはMultiThinkが行なうべきなのでそう修正した。これでmakebook thinkコマンドの精度も改善されるはず。
・LOCAL_GAME_SERVER などで EVAL_NO_USE があるとビルドできなかったのを修正しました。(ishidakeiさん)
・gensfenのときにrandom_move_minplyに1以外を指定すると落ちることがあったのを修正。
■ 2017/06/28
・前回のリファクタリングでBookOnTheFly mode、壊れてしまっていたの修正。(mizarさん)
・book.hがわかりにくかったのでコメント大量に追加して関数を少し整理した。
・gensfenでOptions["BookOnTheFly"] = falseを強制するようにした。
・read_book()でのon_the_flyのフラグ更新処理が怪しかったの修正。
・gensfenでOptions["BookOnTheFly"] = falseを強制したはずがtrueにしてしまっていたので修正した。
・Optionsのassert修正した。
・AsyncPRNG追加。PRNGまわりのソースコード整理。
・BookMoveSelectorにAsyncPRNGを持たせる実装に変更。
・sleep()が間違って単位がマイクロセカンドになっていたのをミリセカンドに修正。
■ 2017/06/27 V4.72
・棋譜生成・学習部でshared_ptrでスレッド間のデータ受け渡しをしている部分、gcc/clangのランタイムで意図しない動作になるので修正。
・SSE4.2以前でlearnコマンドでKPP配列の更新が正しく出ていなかったの修正。
・book.cppのrefactoring。大改造になった。テストあまりしてないのでエンバグしてたら教えて欲しい。
・gensfen時の定跡の採択の挙動を、2017Earlyと全く同一にした。
・gensfen時に定跡ファイルとしてbook.binを指定できなかった問題を修正。
・MemoryBook::probe()をthread safeに実装しなおした。
・clangでコンパイル通らなくなっていたの修正。(mizarさん)
・read_book()関係、整理。
・book.h / book.cppソースコード整理、リファクタリング。
・learn shuffleコマンドの引数の説明足りてなかったの補足。
・test evalmerge、正式に公開する。
・USI拡張コマンド.txt、内容を整理した。
■ 2017/06/26 V4.71
・learn shuffleコマンドでoutput_file_nameを指定できるようにした。
・learn shufflemコマンドでoutput_file_nameを省略できるようにした。
・learn shufflemコマンドのデフォルトの出力ファイル名をshuffled_sfen.binにした。
・learnコマンドでrandom_move_minplyを指定できるようにした。
・USI拡張コマンドとしてgetoption コマンドを追加した。(これがないときちんと現在値を設定できているのか確認できないので)
・learn shuffleqコマンド追加。
・EVAL_SAVE_ONLY_ONCE,LEARN_SFEN_NO_SHUFFLEをlearn.hで定義するのをやめて、learnコマンドのオプションに変更する。
・learnコマンドにsave_only_onceオプション追加。
・learn.hのデフォルト動作をelmo methodに変更。LEARN_DEFAULT削除。
・getoptionコマンド、文字列型のときうまく表示できていなかったのを修正。
・getoptionコマンド、nameを省略したとき、すべてのオプション項目の現在の値を出力するようにした。
・gensfenコマンドの出力ファイル名のオプション名、learnコマンドに合わせて、output_file_nameに変更。
・『Shivoray』V4.71公開。
■ 2017/06/25
・学習部のエラーメッセージに"Error"の文字列を入れた。(検索しにくいため)
・learnコマンドでrandom_move_maxplyとrandom_move_countを指定できるようにした。
■ 2017/06/24
・learnコマンド、初回、rmseの計算で落ちることがあるのを修正。(まだ修正出来てないかも。よくわからない)
■ 2017/06/23
・GUIの「パス」入力（例: ShogiGUI）を受け入れる。(mizarさん) cf. https://github.com/yaneurao/YaneuraOu/pull/46
・learnコマンドでもeval_limitを指定できるようにした。
■ 2017/06/21
・学習部の並列化、OpenMPのループ変数、無符号型にしていたの修正。(VC++でのコンパイルが通らなかった)
・gensfenで千日手のときの処理、間違っていたの修正。
・learnコマンドで不正なsfenが与えられたときのリカバリー処理追加。
・gensfenのエラーチェック強化。
・clangで警告出ていたの修正。
・リゼロ評価関数epoch8公開。
・PRNG、rand()の引数をsize_tではなくu64に変更。(32bit環境でまずいため)
■ 2017/06/20
・shuffleコマンド、マジで完全シャッフルするように変更した。
■ 2017/06/20 V4.70
・gensfenコマンド、depth 3とかでstalemateの局面を書き出すbug fix
・リゼロ評価関数epoch 0公開。
・リゼロ評価関数epoch 0.5公開。
■ 2017/06/19
・gensfenコマンド、壊していたの修正。
・learn shufflemコマンド追加。
■ 2017/06/18
・学習部の微修正。
・教師生成のときに引き分けを書き出すようにした。
・教師局面からの学習のときに引き分けを処理するようにした。
・教師局面生成のときに引き分けの局面を書き出すの、良し悪しあるので選べるようにした。LEARN_GENSFEN_DRAW_RESULT
■ 2017/06/17
・駒落ちの棋譜に対するmakebookが出来るようにした。
■ 2017/06/17 V4.69
・learner.cppでLearner::search(),qsearch()を呼び出していたの、MultiThinkのほうを呼び出すように変更。
・learner、リファクタリングその2。
・makebookコマンド壊していたの修正。
■ 2017/06/16 V4.68
・学習時の評価関数の保存タイミング、デフォルトで10億局面ごとに変更。
・learn.hのEVAL_FILE_NAME_CHANGE_INTERVAL削除。
・学習時のrmseの計算、qsearch()を呼び出すように変更。
・学習時のrmseの計算、500→1000局面に変更。
・学習時のrmseの計算、並列化した。(デバッグ中)
・使わない駒があるとき、BonaPieceの後手から見た番号の初期化が間違っていたの修正。(駒落ち弱かったのこれが原因)
・learner.cpp、clangでコンパイル通らなくなっていたの修正。
・learner、リファクタリング。
■ 2017/06/16 V4.67b
・ContemptFromBlackというオプションを試験的に追加。
■ 2017/06/16 V4.67a
・千日手で打ち切るときに理由を表示するようにした。解説.txtに追記。
■ 2017/06/16 V4.67
・ConsiderationModeで千日手があるときに長いPVが出力されていたの修正。
・ConsiderationModeのときに読み筋に、千日手ならrep、宣言勝ちならwinと出力するようにした。
・ConsiderationModeの件、解説.txtに追記
・ConsiderationMode用にinsert_pv_in_tt()復活させた。
■ 2017/06/15
・連続自己対局スクリプト、持ち時間として固定深さに対応
・リゼロ評価関数epoch7公開。
■ 2017/06/14
・test evalexamコマンド追加(あとで消すかも)
・学習のときにleaf nodeでのevaluate()の値をshallow_valueとして使うようにした。
・MultiThinkなどで乱数のseed固定するコードとかあまり意味なさげなので削除。
■ 2017/06/13
・learning_tools.hのKK,KKP,KPPにデバッグ用の出力関数追加。
・learning_toolsのmir_piece,inv_pieceの初期化タイミングおかしかったの修正。
・EVAL_LEARNのとき、評価関数を読み込み時に、kppのp1=p2のときの値をゼロクリアしたり、
kppのp=0のときの値をゼロクリアしたりするようにした。
・リゼロ評価関数epoch4,5,6公開。
■ 2017/06/12
・Stockfish : Call TT.new_search() earlier.
・リゼロ評価関数epoch1,2,3公開。
■ 2017/06/11
・TTで詰み絡みのスコアでhashの衝突が起きたときに、探索部などでassertに引っかかることがあったのを修正。
・learnコマンドで学習時の出力を少し整理した。
・置換表の世代カウンターをスレッドごとに持つ機能を用意した。→ GlobalOptions.use_per_thread_tt
・置換表の世代カウンターの処理、修正。
・学習のログ解析スクリプト(analyze_learning_log.py)、新しい出力形式に変更。
■ 2017/06/10
・詰んでいる局面と宣言勝ちの局面を渡された場合に読み筋に resign / winを出力することにした。
宣言勝ちのときは、将棋所とShogiGUIでこの出力に対応して欲しい気がする。(読み筋のところに「宣言勝ち」と表示させて欲しい)
・ConsiderationModeで宣言勝ちが読み筋に含まれているとき、これを"win"として出力するようにした。
・置換表に宣言勝ちの指し手が登録されていることを考慮するようにした。
・search()での宣言勝ち判定は置換表にhitしなかったときのみにした。
・LEARN_TIMESTAMP_OUTPUT_INTERVAL削除。
・学習時に出力しているcross entropyの値、正規化するようにした。
・学習時のcross entropyなどの計算に用いる局面数を500に減らした。
・学習時に置換表をスレッドごとに用意する機能追加。→ GlobalOptions.use_per_thread_tt
・学習時に、ファイルの読み込みで負荷がかかると、メインスレッドがweight配列の更新処理ができずに
mini batch sizeを大幅に超えて局面を処理してしまうことがあったのを修正。
■ 2017/06/09
・教師局面のシャッフルコマンドの実行時に進捗を出力することにした。
・学習のログ解析スクリプト(analyze_learning_log.py)、新しい出力形式に変更。
・Stockfish
- use auto& for histories
・教師局面の生成部に宣言勝ちの処理追加。
・学習時にRMSPropが使えるようにした。RMSPROP_UPDATE
・script/analyze_learning_log.py、頂点のplotやめる。
・rootで宣言勝ちのときにもPVを出力するようにした。
・学習のときのtest loss(検証用データのロス) / learning loss(学習データのロス)の両方表示するようにした。
・学習のときのrmse()の計算タイミング修正。
■ 2017/06/08 V4.66
・教師局面の完全シャッフルを行なうコマンドを追加した。詳しくは docs/解説.txt を。
・fail low/highのときにPVを出力するかどうかを思考エンジン設定で選べるようにした。OutputFailLHPV
■ 2017/06/07
・教師局面の生成のときに最後、finalizeを呼び出す前にアクセス違反で落ちることがある問題の修正。(t-suzukiさん)
・学習時にCPUが２つ以上あるときにすべてのCPUにきちんとthreadを割り振るようにした。(tanuki-さん)
■ 2017/06/06 V4.65
・add "test kifconvert" , fix white turn convert to kif(Mizarさん)
・EVAL_KPPT_FAST使ってないから削除。USE_FAST_KPPTも少しコード整理した。
■ 2017/06/05
・EvalIO作った。eval/evaluate_io.h , cpp追加。KPPT型評価関数の入出力、型変換などが簡単に出来る。
・評価関数の読み込み時にeval_learn_init()を呼び出すの、起動が遅くなるのでlearnコマンドの最初に行なうように変更。
・testコマンドにApery(WCSC27)の評価関数を、やねうら王2017Earlyの評価関数に変換するコマンド追加。
・解説.txtにtest evalconvertコマンドについての説明追記。
・EVAL_EXPERIMENTAL導入。
・EVAL_EXPERIMENTALの機能のいくつかを一般開放。
・evaluate_material.cpp → evaluate.cppにrename。evaluate.cppに共通の処理は移動させた。
・isreadyに対する応答の高速化。
■ 2017/06/04
・makebookコマンドでbwを指定したときにno_fileを指定できるようにした。詳しくは解説.txtを。
・makebookコマンド、bwを指定したときの処理、間違っていたので修正。
・指し手のKIF/KIF2形式での出力、そこそこ書けた。
・kifconv consts, utf8/16/32 string (Mizarさん)
■ 2017/06/03
・config.hにinclude <functional>追加。
・Windows環境用のmingw/gccのためにthread_win32.h追加。
・学習時のrmseの計算に時間がかかるの本末転倒なので、1万局面→1000局面に減らす。
・学習時に交差エントロピーを計算して表示するようにした。
・千日手での引き分けを回避しやすくなるようにContemptのデフォルト値を1に変更。
→ すまん。1だと効果なかった。2に変更した。
・MultiThinkまわり、古いエンジン対応コードになっていたので新しいエンジン(2017Early)に変更した。
・makebookコマンドで処理対象sfenとして先後別のsfenを与えることが出来るようにした。詳しくは解説.txtを。
・CSA, KIF, KI2 ライクな棋譜形式での文字列出力実装部。(Mizarさん)
- CSA, KIF, KI2 ライクな棋譜形式での文字列出力部、あとで作業するのでとりあえず#ifdef DO_IT_LATER～#endifで囲んだ。
- extra/kif_converter/ 追加。リファクタリング作業中。
- KIF形式での指し手出力、半分ぐらい出来たのでいったんcommit。
■ 2017/06/02 V4.64
・misc.cppがMSVCでコンパイルしたときに警告出てたの修正。
・learn.h全体をifdef EVAL_LEARNで囲うようにした。
・clangでコンパイルした実行ファイルを配布。
■ 2017/06/01
・clangでwarning出るのでkey128.h少し修正。
・Makefile、clang用に修正。msys2用のclangでwarning出さずにコンパイルが通ることを確認。
・Makefile、デフォルトでclangでコンパイルすることに変更。
■ 2017/05/31
・学習時に用いるEval::Weightをlearn/learning_tools.hとして切り離す。
・学習でSGDを使用するときにメモリ大量に使ってたの修正。
・学習時に用いる重み配列を3角配列化した。(デバッグ中)
・3角配列の学習部、添字間違っていたの修正。
・3角配列でうまく学習できたので、defaultで有効にする。
・SGDでrand(3)==0ときだけ値を動かすコード、削除。
・clangでコンパイルしたときのwarning、いくつか出ないようにした。
・使ってないinclude文削除。
■ 2017/05/29 V4.63
・学習式がelmo(WCSC27)のとき、LAMBDAの値を指定できるようにした。
・learn.hでAdaGradとSGDとを選択できるようにした。
・half float実装
・SlowMoverオプション導入。
・MultiThinkの乱数取得コード修正。(clangでコンパイルが通らなかったらしい)
・学習部でSGDを選択したときにそれを出力していなかったの修正。
■ 2017/05/28 V4.62
・トーナメント用実行ファイル、コンパイルエラーになっていたの修正。
・SfenWriterのデストラクタでclose()を呼び出すように修正。
・ConsiderationModeのとき、置換表からPVをかき集めるように変更。
・PVの出力のコード、refactoring。
・Stockfishに合わせて、from_to()導入。
・Stockfish : History code rewrite
・新しい学習部にSGDでの更新実装。学習時の評価関数の保存は4.5億局面に1回に変更。
■ 2017/05/26
・学習に関するオプション項目、大幅に整理。学習部の調整。
・LearnFloatTypeまわりでstd::atomicを導入しなくても良いことを説明するコメント追加。
・学習部、コメント追加。学習時のオプションなど整理。
・学習部のelmoの更新式、内分をとる形に変形。
・学習時の誤差の表示名変更。
■ 2017/05/25
・Windows用のmakefileでstacksizeを大きめに確保するように変更。(mizarさん)
・EVAL_LEARNはデフォルトでオフにする。Makefile修正した。
・学習部、かなりデバッグできた。(実際に学習を回してテスト中)
・GlobalOptions導入。USE_FALSE_PROBE_IN_TT削除。
■ 2017/05/24
・学習部のコード、刷新した。動作確認はまだ。
※ 開発者の方は、しばらくはApery(elmo)の学習部をお使いください。
■ 2017/05/22
・C++11でコンパイルが通るように修正。
・gensfenのときにhashに一致したときにそれ以前の勝敗の情報が間違っていたのを修正。
・gensfenの2駒交換のコード、削除。効果なさげだしコードが複雑になる。
・learnからLEARN_UPDATE_EVERYTIME関連、削除。コードが複雑化する。
・learn絡みのKPP_MIRROR_WRITEとKKP_MIRROR_WRITE関連のコード削除。これはデフォルトでオンでいい。
■ 2017/05/21 V4.61
・learner.cppのフォルダ内のファイル取得、gccのためにwindows.hを用いて書き直した。→msys2でうまく動かない
・gensfenコマンドでgamePlyを書き出すようにした。
・learnで用いていたrmse計算用の損失関数、変更した。
・gcc用のフォルダの作成、ファイルの列挙のコード、修正。
・学習用のビルドオプションをMakefileに追加。
・対局用に公開している実行ファイル、openmpなしでコンパイルするように変更。
・learn.hから2016LATE用の学習オプション削除。
・gensfenコマンドでmatedのときに局面を書き出していなかったの修正。
・gensfenコマンドでのrandom moveの条件、緩和。
・詰みの局面を渡されたときにinfo stringでmate 1と出力していたの修正。
USIプロトコルは、詰みのときには"info string score mate -0"と出力するときちんと定めるべき！
■ 2017/05/20
・BetweenBB、シュリンクした。
・see_ge()でPosition::piece_on(SQ_NB)にアクセスしてたのでpiece_on側を修正。
・mate1ply()で用いるbitboardの添字の順番入れ替え。
・Positionの各メンバにASSERT追加。
・Position::moved_piece_before()高速化
・CheckCandidateBB、少しシュリンクした。
・engine_invoker5.py、パラメーターの型を間違っていたところ修正。
・engine_invoker5.py、先手の勝率の計算が間違っていたのを修正。
・elmo(WCSC27) learning method support
・packed sfen以外での教師局面の書き出しコード、使ってないので削除する。
■ 2017/05/19 V4.60
・PieceNoをu8に変更。
・Stockfish : Fix memory access in Search::clear()
・EvalList、refactoringした。
・解説.txtにトーナメント用実行ファイルの説明追加。
・Position.hで使っているSlide、u8に変更など。
・LineBB配列、シュリンクした。
・min_attacker()高速化
・RookEffectRank → RookRankEffectにrename
■ 2017/05/18 V4.59
・do_move_impl()での王手している駒の利きの更新を最適化。
・UpdateBitboards()を重複してやっている箇所があったので修正。
・Position::put_piece_simple()追加。少しdo_move()を高速化。
・VC++でSSE2用のコンパイル時にwarning出てたの修正。
・color_of()少し高速化。
・mate1plyの実装、templateにして先後区別する。
・Position::piece_bb → byTypeBBに、occupied → byColorBBにrename。
・do_move()のときのmemcpy()をやらないようにした。
・玉が盤上にいないときにrookEffectがアクセス違反になっていたの修正
・mate engineに対するVC++のプロパティシート追加
・KEEP_PIECE_IN_GENERATE_MOVESが定義されていないときのundo_move()の動作修正
・LONG_EFFECT_LIBRARYをdefineしたときにコンパイルエラーになっていたの修正
・トーナメント用のbuild、FOR_TOURNAMENTオプション追加。AVX2用でEVAL_HASH大きめ。EVAL_LEARN、TEST_CMD使用不可。
■ 2017/05/17 V4.58
・lanceEffect()はrookFileEffect()を使うように変更。
・飛車の利きを求めるための利きテーブルを無くした。
・飛車の利き用のテーブルさらに小さくした。
・角の利き用のテーブル小さくした。
・working memory、だいぶ減ったかも。置換表を小さくすればいままでせ動かなかったスマホでも動くかも。
■ 2017/05/16
・Learner::search、max_game_plyの値を変更しないようにした。
・Limits.max_game_plyに一本化していたの、やめた。
・MaxMovesToDrawを0に設定されたとき内部的にINT_MAXにしていたの、100000に変更。
・is_ready()のなかでSignals.stopなどの変数を初期化するように変更。
・Stockfish
- Execute an implied ucinewgame at startup
・position::gives_check() リファクタリング。
・position.cpp reformatting
・ベンチマークだけTEST_CMDから移動させる。これは常に必要。
・reformatting position.h
・step effectリファクタリング
・Position::attackers_to()、高速化。
・prefetch()にassert追加。
・NextSquareテーブル、u8に変更。
・mate1ply_without_effect.cpp reformatting
・pawnEffect(Color,Bitboard)追加。Shift<>(Bitboard)削除。
・歩の打てるところを調べるコード、テーブルを2つに分割。先後の区別なしにする。
・Bitboard(u64,u64)のSSE2用コードを追加。
■ 2017/05/15 V4.57
・検討モード用の読み筋出力として、ConsiderationMode "検討モード用のPV出力" を用意。
・テスト用に"test search"コマンド追加。
・SILVER_HDK、GOLDS_HDK追加。
■ 2017/05/14 V4.56
・定跡読み込み部、リファクタリングしたときに若干壊してたの修正。(定跡ファイルの対局途中での変更ができなかった)
・Bitboardクラス、リファクタリング。
- Bitboard::test()追加。
- Bitboard::test()追加。
- Bitboard::extract64(),insert64()追加。
- FOREACH_BB、修正。
・VC++のプロジェクト設定、現行のやねうら王のプロジェクトでないものは削除する。(切り替えするとき邪魔なので)
■ 2017/05/13 V4.55
・配布している実行ファイルで同じ定跡の指し手が選ばれる問題修正。(MSYS2のgccのランタイムの問題らしい)
・乱数シードとしてstd::chrono::high_resolution_clock::now().time_since_epoch().count()の時刻も足すことにした。
・定跡選択部、リファクタリング。
・定跡部で指し手を選ぶ時に、いくつからいくつに減らしたかを出力するようにした。
■ 2017/05/12 V4.54
- Stockfish最新版にキャッチアップ
- Default argument for see_ge()
- Remove int to int conversion, unused include.
- Move Pieces[] out of global visibility
- Avoid *begin always being included in the sorted list regardless of its value.
- use int16_t for histories
・詰将棋エンジンのバグ修正と、テストコマンド追加。(thx. tanuki-さん)
・比較実験用のKKPT型評価関数追加。
・HistoryStats、リファクタリング。
・定跡の指し手の選択部、リファクタリング。(何か壊しているかも)
■ 2017/05/11 V4.53
・Learner::qsearch() および Learner::search() でnullポインタアクセスする件修正。(thx. tanuki-さん)
・王手のかかっている局面をPosition::set_from_packed_sfen()で読むと状態が不正になる件修正。(thx. tanuki-さん)
・定跡を選択するときのConsiderBookMoveCountの処理が間違っていたので修正。
・各CPU用のMakefile修正。nosseはx86用にコンパイルする環境が必要なので後回し。
・32bit用にコンパイルするときはEVAL_LEARNをオフにするようにした。
・Makefile、CFLAGSとして-D_WIN64指定しないように変更。
・Makefileにother(ARM用など)を追加。
・VSのプロジェクト設定のカスケーディング追加。(thx. mizarさん)
- [VisualStudioのプロパティシートのメモ](http://qiita.com/bigengelt/items/31c315cf624985a6a47c)
・定跡の指し手選択部、少しリファクタリングした。
■ 2017/05/10 V4.52
・KP絶対を用いた進行度推定ルーチン追加。(tanuki-さん)
・進行度絡みのファイルの整理。move_picker絡みのファイルの整理。
・math.h/cppの中身をmisc.h/cppのなかに移動
・calc_check_sum()の返し値をu64に変更。
・評価関数ファイルの自動判定機能追加。
- 真やねうら王20161010 , 浮かむ瀬(sdt4) , elmo(WCSC27) , 読み太(WCSC27) , Qhapaq(WCSC27) , tanuki(WCSC27)
・eval_sum、u64に変え忘れていた箇所修正。
・共有メモリを使わないときにもeval check sumが出力されるように。
・gccでコンパイルするときもWindows環境であれば、評価関数を共有メモリに配置するように。
・各CPU用の実行ファイルの自動生成バッチファイルを作成した。
■ 2017/05/09 V4.51
・USE_LARGE_EVAL_HASH導入。
・Apery定跡ファイルの読み込みに対応。(tanuki-さん)
・extra/book/ フォルダ作成。定跡の読み込み絡みのソースコードはここに移動。
・定跡データベースの採択率に比例して指し手を選択するオプション追加。(tanuki-さん)
・book.cpp、リフォーマッティング。
■ 2017/05/08 V4.50
・Position::piece_bb、やはり大改造することにした。
・WindowsSDK、10.0.15063.0をターゲットに変更。
・tanuki-さんの詰将棋探索エンジンをmerge。(作業中)
■ 2017/05/07 V4.49
・ShogiGUIの検討モードの読み筋が短いことがある件に関する修正。(thanks! tさん)
・エンジン名の偽装として、USIプロトコルの「usi」コマンドに対してengine名を返すときに同じフォルダに
"engine_name.txt"というファイルがあればその1行目をエンジン名、その2行目を作者名として出力するようにした。
■ 2017/05/06 V4.48
・PvIntervalが0のときに思考を中断した場合、PVを出力しないように修正。(読み筋が途中までになってしまうので)
■ 2017/05/06 V4.47
・ShogiGUIの検討モードできちんと読み筋が出力されるように修正。
- go infiniteのときはPvの出力を減らさないように(PvInterval = 0とみなして動作)
- PvIntervalが0のときに、前回の出力から1ms経過していないと次のPVが出力されないのを修正。
■ 2017/05/06 V4.46
・DirtyPieceのデータ構造、少し変更。
・やねうら王2016MID以前がコンパイル通らなかったの修正。
・Limitsにbenchモード用のフラグを追加。Limitsまわり改良。
・検討モードが使いにくすぎるのでUSE_TT_PV、デフォルトでオンに変更する。
■ 2017/05/05 V4.45
・gccの最新版でbuildが通らなかったの修正。> misc.cpp
・gccの最新版で警告が出ていたの修正。> movegen.cpp
// 色々いじってテストが十分出来てないのでWCSC27の大会参加者は、V4.41を使っておくほうが無難。
■ 2017/05/05 V4.44
・qsearch()でPvNodeのときに強制で1手詰め判定してたの、意味なさそうなのでやめる。
・benchコマンドのデフォルト設定、早く終わりすぎて役目を果たしていないのでdepth15から17に条件を変更。
・Stockfish
- Fix multiPV issue #502
・Position::pieces()改良。
- piece_bb、色別に持たないように変更。
- piece_bb[][]を直接参照しているところをPosition::pieces()経由でアクセスするように変更。
・Visual Studioのプロジェクトファイル
- 並列コンパイルのコンパイルオプションを有効に。
- デバッグ情報の出力、オフにしてたのでオンに戻す。
・やねうら王2017Early、noSSEで動作したのでexe/フォルダに入れておいた。
・MovePickerの配列無駄があったので少し縮めた。
■ 2017/05/04 V4.43
・EVAL_LEARN、間違っててコメントアウトしたままだったの修正。
・EVAL_LEARN、x86用のコンパイルで警告が出ていたの修正。(依然としてx86環境ではメモリが確保できないが…)
・評価関数読み込み用のメモリ確保できなかったときにエラーメッセージを出力するように。
■ 2017/05/04 V4.42
・NO_SSEにコンパイル出来なかったので少し修正。
・NO_SSEにコンパイルするときに警告が出ないように修正。
・やねうら王2017early、SSE4.2/SSE4.1/SSE2の実行ファイルを用意。
・Learner::search()の引数のPosition、参照で受け取ってなかったのを修正。
■ 2017/05/03 V4.41 また強くなっててワロタ
・EVAL_HASHのprefetch有効にする。
■ 2017/05/03 V4.40
・Stockfishのpull req.
- Remove excluded move from TT position key formula.
■ 2017/05/03 V4.39 強くなりすぎワロタ
・探索部、Stockfishのsearch.cppに書式をなるべく合せる。
・Reductionテーブルの初期化コード、ONE_PLYを掛けるように修正。Stockfish本家のほうも同様の修正が必要だと思う…。
・check_time()の呼び出すコード、修正。(npsが出なかったの、これが原因か？)
・#ifndef、紛らわしいので#if !defined()に変更する。
・qsearch()の1手詰め、置換表にhitしなかったときにのみ調べるように変更。ただしPvNodeでは調べる。
■ 2017/05/02 V4.38
・Stockfish最新版にキャッチアップ
- Partial insertion sort
- Use int instead of Value for history related stats.
- simplify logic for history based pruning
- Sort moves partially: linear depth dependence
- Assorted code style issues
- Zero unused constant
- Copy killers in the movepicker
- Retire the misdesigned StepAttacks[] array.
- Don't do InCheck Pruning at the root of QS
- gcc 7 port
以上、2017/5/2時点までキャッチアップ完了。
■ 2017/04/25 V4.37
・rootDepthをValueにキャストせずにValue型と比較していたところ修正。
・プロジェクト設定の調整
■ 2017/04/23 V4.36
・Thread::rootDepth、completedDepthをDepth型に変更。
・Learner::search()調査。少しリファクタリング。
・Xeon Phi対応コード、いったんrevert。
■ 2017/04/22 V4.35
・2017early、探索パラメーター、最終調整。完了。対技巧、4スレ5秒。4033 - 34 - 1625(71.28% R157.91)
■ 2017/04/21 V4.34
・Ryzen向けに、EVAL_HASHデフォルトで有効に変更。
■ 2017/04/21 V4.33
・EVAL_HASHの処理、微修正。
■ 2017/04/20 V4.32
・do_move()でのTTのprefetch、2箇所追加する。
■ 2017/04/19 V4.31a
・learner.cpp、#pragma omp parallel for schedule static を並列化したいforの前に移動。(Qhapaqさん)
■ 2017/04/19 V4.31
・search()にStep 1.からStep 20.のコメントをつける。Step 19.はStockfishのソースには抜けている。
・reduction_tableの名前をReductionsにリネーム。
・Stockfishの最新版にキャッチアップ
- Singular extension and check extension tweak
- Skip quiet moves based on moveCount pruning threshold and history stats
- Penalty for a quiet ttMove that fails low
- Simplify skipping of plies with helper threads
- Further simplify skipping of plies with threads
- Prefer std::find over a hand-coded loop
- Move-Count Formula Tweak
// 以上で、最新のStockfish(2017/4/18)に追いついた。
■ 2017/04/18 V4.30
・Stockfishの最新版にキャッチアップ
- Penalty for a quiet ttMove that fails low
- Standardize stat penalty
- update_cm_stats() 書き換え
- Always have counterMoves associated
- Remove HistoryStats
- Rename FromTo -> History
- Simplify TT penalty stat
■ 2017/04/18 V4.29
・Stockfishの最新版にキャッチアップ
- Removing CM parameter from the Stats struct.
- A small tweak in doEasyMove()
- Drop Stats c'tors
- これに伴い、thread.cppでスレッドメモリの確保のときにゼロクリアを強制するように変更。
- Razor Simplification
- Introduce assert for stats update
- これに伴い、HistoryStats、Statsのupdateでvの値が大きいときにreturnする処理を削除。
- Don't update TT at excluded move ply
■ 2017/04/18 V4.28
・MovePicker新しく用意した。
- move_picker_2017Q2.h / cpp
- これに伴いmakefile修正。
・Stockfishの最新版にキャッチアップ
- Simplify threshold handling for probcut.
- Don't clear EasyMove in search()
- Use consistent variable names for counterMoveStats
- Correct zero-init of Thread data members
- Zero init fromToStats in constructor.
- Tweak best thread selection logic
- Simplified select best thread
- ベストスレッドの指し手を返すときにresignの指し手だとhangすることに対する修正。
- ベストスレッドの指し手を返すときにeasyMovePlayedのフラグを見るように修正。
■ 2017/04/17 V4.27
・開発メモ2017.txt追加。(そのうち消すかも)
・Stockfishの最新版にキャッチアップ
- Help GCC to optimize msb() to single instruction
- Use DEPTH_ZERO initializer for depth in qsearch
- Remove piece condition in decrease lmr reduction check
- Explicitly use alpha+1 for beta in NonPV search
- Clean-up skipEarlyPruning
■ 2017/04/17 V4.26
・Ryzenに向けた最適化、調査。
・attackers_to()のColorを取らないバージョン、バグってた。see_ge()実装以降バグっていたのか。修正。[1秒で+R25]
・attackers_to()のColorを取らないバージョン、香の利きに関して高速化した。全体で1%ぐらい速くなったかも。
■ 2017/04/16 V4.25
・プロジェクトファイルをVisual Studio 2015→2017に変更。
・推奨コンパイル環境をVisual Studio 2017に変更。
・解説.txtのVisual Studio 2015用の説明を削除。
・デバッグのターゲットフォルダ、..\\YaneuraOu2016Engineに設定。
・[pullreq] リファクタリング: コマンドラインオプションのパースにargparseを使用するようにした(tanuki-さん)
・[pullreq] リファクタリング: パスの結合をos.path.join()で行うようにした(tanuki-さん)
・[pullreq] Intel Xeon Phi Processor 7250においてCPUを100%使い切れるようにした(tanuki-さん) → Stockfish公式にpull reqすべき？
・[pullreq] 駒得評価関数での思考エンジンのコンパイルエラーを回避(YuriCatさん)
・[pullreq] 自己対戦フレームワークの先手・後手の表示の誤りを修正した (tanuki-さん)
・V4.24を間違って削除してしまったので復旧。→ config.h
・Windows SDKのターゲットバージョンを10.0.14393.0から10.0.15063.0に変更。
→時期尚早だった。Windows 10 Creators Updateが来てからにする。
■ 2016/12/04 V4.24
・評価関数を増やすためにeval関連の整理。
■ 2016/12/04 V4.23
・shogi.h、4タブ化。
・thread.cpp、4タブ化。
・Stockfish : Handle Windows Processors Groups
・Windows環境にて複数のプロセッサを積んでいるときに探索ですべてのプロセッサを使い切るための改良。
・MultiThinkを全プロセッサを使い切るように修正。
・gensfen、learnコマンドも同様にすべてのプロセッサを使い切るように。
・learnコマンドでopenmpをすべて使い切るように修正。
・openmpのscheduleをstaticを指定するように。
・pythonの自己対局スクリプト、全CPUを使い切るように変更。→ engine_invoker5.py
・KPPT型評価関数のときにEngineNuma optionは指定できないように変更。
・exe/に2017Earlyの実行ファイルを入れる。
■ 2016/12/03 V4.22
・取る一手将棋は、GUIから局面が送られてきたときに合法手チェックをするように。
■ 2016/12/02 V4.21
・取る一手将棋、仮公開。
・exeフォルダ、整理。
・解説.txt更新。
■ 2016/12/02 V4.20
・王手将棋評価関数V6を公開。(+R150)
・取る一手将棋のための準備。
・Learner::search()修正。
■ 2016/11/24 V4.19
・王手将棋評価関数V4を公開。(+R300)
・[Pull Req.] : 盤面を英字表示する際のコンパイルエラーを修正
・USI_PIECE、やはり定義したほうがいいような気がするので修正。
・CHCECK_SHOGI_ENGINE → CHECK_SHOGI_ENGINE 修正。
・連続自己対局pythonスクリプト、後手番のときの勝率も出力できるようにする。
・王手将棋評価関数V5を公開。(+R200)
■ 2016/11/23 V4.18
・王手将棋評価関数V3を公開。(+R400)
・連続自己対局pythonスクリプト、先手/後手の勝率を集計できるようにする。
■ 2016/11/22 V4.17
・learnコマンドでmany coreだとassertに引っかかることがあったのを修正。
・王手将棋用評価関数V2を公開。(+R300)
・王手将棋の実行ファイルの差し替え。
■ 2016/11/22 V4.16
・王手将棋でqsearch()においてss->plyを初期化しないうちにmated_in(ss->ply)で返していたの修正。
■ 2016/11/21 V4.15
・Learner::search()、aspiration型に戻す。綺麗に実装しなおす。
・定跡を読み込んでいないとき、MemoryBook:find()はなる早でリターンするように変更。
・王手将棋用の評価関数V1を用意した。(+R300)
・README.md更新。
・書き直したLearner::search()のaspiration searchがバグっていたので修正した。
・Learner::search()でalpha,beta指定できるの良くないので変更する。
・Learner::qsearch()も同様に修正。
・やねうら王2016Mid/LateからLearnerのスタブ削除。(お役御免)
・EVAL_LEARNなしでTEST_CMD有効にしたときにコンパイルが通らなかったの修正。
■ 2016/11/20 V4.14
・王手将棋(CheckShogi)探索部追加。また、ビルドに追加。
・makefileを王手将棋に対応。
・PER_THREAD_COUNTERMOVEHISTORY追加。
・PER_STACK_HISTORY追加。
・thread.h、2tabになっていたの修正。
・readme等を用意して、王手将棋関連をexe/に入れた。
・プロジェクトファイルのターゲットCPUがAVX2でなくなっていたの修正。
■ 2016/11/18 V4.13
・2017(early)の探索パラメーターの調整
■ 2016/11/17 V4.12
・2017-early-engineの作業開始。関連ファイル追加。
・2017(early)がbuild出来るようにmakefile修正。
・Stockfish[pull req.] : Remove restriction of Depth
→ PARAM_FUTILITY_AT_PARENT_NODE_SEE_DEPTH1削除
→ PARAM_FUTILITY_AT_PARENT_NODE_SEE_DEPTH2削除
T1,b3000,2302 - 144 - 2354(49.44% R-3.88)
・Stockfish[pull req.] : remove evasionPrunable variable, reorder condition evaluation
・Stockfish[pull req.] : Remove branching in key_after()
→ この関数、実装してない。
・Zobrist::psqをSQ_NB_PLUS1まで確保するように修正。
・Zobrist::psq,handはpc==NO_PIECEのときに0を保証するように変更。
・Stockfish[pull req.] : Position::is_draw(): start searching from the 4th ply behind
→ すでにこれに近いコードになっているので修正不要。
・Stockfish[pull req.] : Non-quiet pruning tweak
・PARAM_DEFINE PARAM_FUTILITY_AT_PARENT_NODE_MARGIN2追加。
■ 2016/11/15 V4.11
・gensfenコマンドでは16手目までの局面を書き出さないように変更。
■ 2016/11/14 V4.10
・init_for_search()にhistory等をクリアするコード追加。
・move_picker_2016Q3.hのコメント間違っていたの修正。
・LEARN_READ_SFEN_SIZE → LEARN_SFEN_READ_SIZEにリネーム。
・SfenReader、vector::resize()で元の要素がコピーされることを期待していたので修正。
・SfenWriterのバッファ確保まわりの処理、単純化。
・Learner::search()でmulti pvのときもbest valueが正しく返るように修正。
・read_to_thread_buffer_impl、単純化。
■ 2016/11/14 V4.09
・learnコマンドで置換表の世代を進めるの、1M→100k局面ごとに変更。
・gensfenのSfenWriterのコード整理。
・Learner::init_for_search()のコード整理。
・analyze_yane_log.py、mini-batchのサイズを自動認識するように修正。
・SfenWriter、FILE_WRITE_INTERVAL→SFEN_WRITE_SIZEにリネーム。
■ 2016/11/13 V4.08
・test dumpsfenコマンド追加。
・PackedSfenValueの定義をlearn.hに移動。
・Learner::Search()に初期化コード色々追加。
・gensfen、MAX_PLY2まで生成するのやめてMAX_PLYに変更。
・"test dumpsfen"コマンドにnumber指定できるように。
■ 2016/11/12 V4.07
・Stockfish : Stack offset changed from -5 to -4
・Stockfish : Make a version of Position::do_move() without the givesCheck parameter → すでにそうしてた。
・Stockfish : Allow benches with more than 2G nodes.
・Learn::search()、stackのpv初期化コード追加。
・atoi()を使っていたところstoi()に変更。
■ 2016/11/11 V4.06
・gensfenコマンドで玉の2手指しのコード、削除。
・gensfenコマンド、定跡の局面であっても一定確率でランダムムーブは行なうように変更。
・gensfenコマンドで定跡にhitしなかったときの処理、少しおかしかったので修正。
・gensfenコマンド、learnコマンドの局面の重複除去処理のバグ修正。
・learnerのinit_for_search()にDRAW_VALUEの初期化コード追加。
・gensfenのランダムムーブ、24手目以降ではやらないように変更。
■ 2016/11/09 V4.05
・learn.hのGENSFEN_SAVE_FIRST_MOVE、デフォルトではオフに変更。
・教師局面生成のときの評価値、leafを辿るのやめる。
・GENSFEN_SAVE_FIRST_MOVEをdefineしていないときにコンパイルが通らなかったの修正。
・gensfenのときに定期的にTT.new_search()を呼び出すように変更。
・volatileを使っていたところ、atomicに変更する。
■ 2016/11/08 V4.04
・gensfenで書き出す局面、同一局面の書き出しを制限するためのコード追加。
・learnコマンドでも同一局面を学習対象から外すコードを追加。
■ 2016/11/07 V4.03
・Stockfish : Simplify futility pruning return value
・Stockfish : Use explicit logic for pruning → 反映済みだった。
・Stockfish : Remove useless assignments to currentMove → 反映済みだった。
・Stockfish : Simplify next_move by always scoring evasions → 反映済みだった。
・Stockfish : Per-thread TB hit counters → TB hit counter使ってなかった。
・Position::set_node_searched()削除。(使っていない/使わないから)
・Position::node_searched()をint64_tからuint64_tに変更。
・Thread::node_searched()も同様にuint64_tに変更。
・Stockfish : History Stat Comparison
・Stockfish : Output PV if last iteration does not complete
・Stockfish : Fix a series of undefined behaviours
・Stockfish : Sync variable names in decl vs def
・Stockfish : Reduction Simplification
・Stockfish : Reproducible searches after ucinewgame
■ 2016/11/06 V4.02
・2016Lateの、search()のスタブ、aspiration searchをしているコードを削除。
・gensfenのときに毎node、evaluate()を呼び出すように修正。
■ 2016/11/05 V4.01
・GENSFEN_USE_NO_REPETITION関係、削除。
・learnコマンドで計算するrmse、USE_EVALUATE_FOR_SHALLOW_VALUEのときは、evaluate()基準で計算するように変更。
・learnコマンドでetaを設定できるように変更。
・DISPLAY_STATS_IN_UPDATE_WEIGHTS削除。
・learnコマンドのparser、ソースコード整理。
・学習のときの進み具合をグラフ化するpythonスクリプト追加(tanuki-さんのチームより提供) → analyze_yane_log.py
・scriptフォルダにreadme.txt追加。
■ 2016/11/04 V4.00
・gensfenコマンドで生成される棋譜の数が指定した数ぴったりになっていなかったのを修正。
・gensfenコマンドでdepth < ONE_PLYでも教師局面が生成できるように修正。
・learnのeta2廃止。
・gensfenコマンドでdepth2を指定できるように。
・AdaGradのとき、最初のiterationではwを更新しないように変更。
・save_eval()の開始時にメッセージを出力するように。
・learn.hの設定項目にLEARN_EVAL_SAVE_INTERVAL追加。
・KPP_MIRROR_WRITEが定義されていないとき、get_kpp_indexはmirrorを考慮しないindexを返すように変更。
・学習時のkppのupdateのコード、整理。
・learnの更新式のupdate、整理した。
・learnからUSE_YANENZA_UPDATE削除。
・learnからUSE_YANE_SGD_UPDATE削除。
・kppのp1==p2がゼロかチェックするテストコード追加。
・learnのadd_grad()からdead code削除。
・学習のときのwの絶対値の抑制するコード、調整。
・学習のときのg2の減衰、KKとKKPに適用してなかったの修正。
・USE_KKP_MIRROR_WRITE追加。
・learnはデフォルトでKPPのflipも対応。
・learnのadd_grad()でKK,KKPのflipにも書き込むようにした。
・learnのFloatPairに基本的な演算子追加。
・gensfenコマンドでdepth < 0 のときは単にevaluate()を呼び出すように変更。
■ 2016/10/16 V3.99
・AdaGradの更新式、調整。
・解説.txtに推奨設定のところ追記。
・YaneGrad削除。
・LEARN_READ_SFEN_SIZEのデフォルト値 10Mに変更。
・2016lateのInCheck→inCheckに変更。
・Stockfish[pull req.] : Explicit Logic/Speedup
・Stockfish[pull req.] : Remove assignments to currentMove that don't serve any purpose
・Stockfish[pull req.] : Simplify next_move by always scoring evasions.
■ 2016/10/13 V3.98
・ResignValueの実装、バグっていたようなので修正。
・AVX2用のバイナリが差し替わっていなかったので修正。
■ 2016/10/13 V3.97
・MinimumThinkingTime、電王トーナメントでは2秒未満が計測1秒らしかったので、デフォルトを2秒に戻しておく。
・投了スコアを設定できるように変更。ResignValue
・*_ja.txtの置換表サイズの単位表記を大文字に修正。
・解説.txtに推奨対局設定を追加。
■ 2016/10/13 V3.96
・bitop.hにBLSRマクロ追加。(thanks! > merom686さん)
・gen_sfen時にfail low/highしたら生成を終了するように変更。
・learn.hにLEARN_UPDATE_EVERYTIME追加。
・KPPTのAVX2のコード、Late以外にも開放。
■ 2016/10/12 V3.95
・真やねうら定跡公開。
・やねうら王2016Late(≒真やねうら王)の公開のための準備。
・やねうら王2016Lateの探索パラメーターファイルを公開に変更。
・教師局面の生成部、KINGの二度移動が新しいコードにおいて生成出来ていなかったの修正。
・極やねうら王の定跡ファイル、読み込み対応。
・AdaGradのg2に関するif式修正。(thanks! > 読み太の塚本さん)
■ 2016/10/07 V3.94
・Position::see_ge()、g++で警告出てていたの修正。
・その他、g++で警告出ていたもの一通り修正。
■ 2016/10/06 V3.93
・Stockfish : Do not use SEE in evasion scoring
・Stockfish[pull req.] : Replace Position::see and Position::see_sign by Position::see_ge
・Stockfish : Optimisation of Position::see and Position::see_sign
・USE_SIMPLE_SEE削除。
・2016 Late用のデフォルトパラメーター(Stockfishと同じもの)を公開。
・上の修正にともなって、Score<Evasion>、LVAするの忘れていたの修正。
・score<EVASION>、capture_or_promotionで分岐するように変更。→ revert
■ 2016/10/05 V3.92
・MovePickerのupdate、abs()の括弧の位置がおかしかったの修正。(thanks > merom686さん)
・offsetof()を使うときはstddef.hをincludeするように修正。(thanks > Qhapaqさん)
■ 2016/10/04 V3.91
・Stockfish : Allow inCheck pruning
・makebook mergeコマンドで、different nodeのカウントをしていないところがあったので修正。
■ 2016/10/04 V3.90
・教師局面生成時および定跡生成時に、置換表世代を定期的にインクリメントする処理追加。
・test bookcheckコマンド追加。
・makebook thinkコマンド、与えた定跡ファイルが、moves以下までしかないときに正しく局面を
思考対象としていなかったのを修正。
・makebook thinkコマンド、複数台での分散生成に対応。
■ 2016/10/02 V3.89
・learnコマンド、targetdirを指定したときに読み込むファイルpathがおかしかったの修正。
・learn.cpp、PackedSfenまわりリファクタリング。
・learnコマンド、OpenMP無効なら警告を出すように変更。
・learnコマンドのsave()で、OpenMP無効時も勾配の更新をしないように変更。
・evalmergeコマンドの追加。
・2016 Lateでmakebookコマンドが無効になっていたの修正。
■ 2016/10/01 V3.88
・KPPTのAVX2化。(thanks! > tanuki-さん)
・GENSFEN_SAVE_FIRST_MOVE追加。PVの初手も保存するように変更。
・gensfenコマンドで教師局面を生成するとき、PV leafのevaluate()の値を保存するように変更。
・教師局面からの学習 : 教師のPVの初手と異なる場合、それを学習対象としないように変更。
・learnコマンドのoptionのdir→basedirに変更。
・learnコマンドのoptionにtargetdir追加。
・教師局面からの学習 : search_depthよりPVが短い場合(置換表にhitするなどした場合)、その局面は出力しないように変更。
■ 2016/10/01 V3.87
・N手詰め、まだバグっていたのでまたまた修正。(thanks! > tttakさん)
■ 2016/09/29 V3.86
・N手詰め、まだバグっていたので修正。(thanks! > tttakさん)
■ 2016/09/29 V3.85
・Stockfishのコード、razor_margin[3]を下回るときに静止探索を呼び出しているが、razor_margin[ZERO_DEPTH]
を下回るときでないとrazoringとしておかしい。これはStockfishのバグだろう。修正した。
・Stockfish公式のほうも同じ修正が入った。
→ Stockfish : Remove useless razoring condition
■ 2016/09/29 V3.84
・mate_n_ply()でlegal()の判定忘れていたの修正。
・pythonの自己対戦スクリプト、保守できないので1と4だけ残す。
■ 2016/09/29 V3.83
・2016 Late、razoring marginパラメーターで変更できてなかった。修正。
・2016 Late、razoring margin、関数を通さず、テーブルを直接参照するように変更した。
・USI拡張コマンド.txtでbenchコマンドの説明が間違っていたの修正。
■ 2016/09/29 V3.82
・N手詰め、バグっていたの修正。(thanks! > tttakさん)
・position.hのcheck_info_update()を呼び出す必要があるという注意書き、削除。
■ 2016/09/28 V3.81
・2016 LateのRANDOM_PARAMETER、値を3択ではなく、intervalの範囲で複数の値が試行できるように変更。
・Makefileのソースのところに extra/mate_n_ply.cpp 追加してなかったので追加。
・PARAM_SINGULAR_MARGINのスケール16倍に変更。
■ 2016/09/27 V3.80
・3手詰めやめて、N手詰めに拡張。
・2016 Late、weak_mate_n_ply()を使うかどうかをパラメーター化
・PARAM_WEAK_MATE_PLY追加。
・2016 Late、以下のパラメーター追加。
"PARAM_REDUCTION_ALPHA",
"PARAM_FUTILITY_MOVE_COUNT_ALPHA0","PARAM_FUTILITY_MOVE_COUNT_ALPHA1",
"PARAM_FUTILITY_MOVE_COUNT_BETA0","PARAM_FUTILITY_MOVE_COUNT_BETA1",
■ 2016/09/27 V3.79
・2016 Late、LMRのreductionテーブルの初期化タイミングの変更。
・reduction_table、FutilityMoveCountsをパラメーター化の準備。
・mate3()実装。
・MovePickerの書き換えでclassic-tceまでがコンパイル通らなくなっていたの修正。
■ 2016/09/26 V3.78
・PARAM_SINGULAR_SEARCH_DEPTHをPARAM_SINGULAR_SEARCH_DEPTH_ALPHAにリネーム。
・PARAM_PRUNING_BY_MOVE_COUNT_DEPTHの値が反映していなかったの修正。
・&PARAM_FUTILITY_AT_PARENT_NODE_SEE_DEPTH0削除。
・parent nodeでの負のsee()を持つときの枝刈りに関する旧コード、削除。
・2016 LateにENABLE_OUTPUT_GAME_RESULT追加。
・2016 Lateからdynamic marginに関するコード削除
■ 2016/09/26 V3.77
・2016 LateにPARAM_FUTILITY_AT_PARENT_NODE_SEE_DEPTH3追加。
・PARAM_FUTILITY_AT_PARENT_NODE_GAMMA1,2を追加。
・PARAM_FUTILITY_AT_PARENT_NODE_SEE_DEPTH1→PARAM_FUTILITY_AT_PARENT_NODE_SEE_DEPTH0に名前変更。以下、1,2も同様。
・pythonの自己対戦スクリプト、定跡のランダムシャッフルするオプションを追加。
・PARAM_NULL_MOVE_MARGIN追加。
・PARAM_SINGULAR_SEARCH_DEPTHの初期値がおかしかったの修正。
■ 2016/09/25 V3.76
・PARAMで"fixed"と書かれているものは無いものとして扱うように変更。→ バグっていたので修正。
・2016 late、古いほうのreduction tableの初期化コード、削除。
・2016 late、mate1の呼び出しもパラメーター化する。USE_MATE_1PLY_IN_SEARCH、USE_MATE_1PLY_IN_QSEARCH削除。
・USE_RANDOM_PARAMETERSのとき、2択のパラメーターの採択確率に偏りがあったのを修正。
■ 2016/09/25 V3.75
・singularのPARAM、2を掛けていたの修正。
・PARAMで"fixed"と書かれているものは無いものとして扱うように変更。
・Stockfish : Rename shift_bb() to shift()
・Bitboard::shift()追加。
・movegen.cpp、mate1ply()など、Bitboard::shift()を用いるように変更
■ 2016/09/25 V3.74
・2016 MidのMovePicker、QUIETS→SEARCH_QUIETSに置換もれがあったの修正。
・PARAM_FUTILITY_AT_PARENT_NODE_GAMMAの順番変更。
・PARAM_FUTILITY_AT_PARENT_NODE_SEE_DEPTHまわり変更。
・PARAM_FUTILITY_AT_PARENT_NODE_SEE_DEPTH2を用意。
・Stockfish : Allowing singular extension in mate positions
■ 2016/09/24 V3.73
・analyze_result_log.py、win、drawやloseが0の場合に対応。
→ まだなおってなかった。修正した。
・2016-mid-param.hの冒頭のifdefのシンボル、変更。
■ 2016/09/24 V3.72
・2016 Late用のパラメーターファイル名変更。
・2016 LateにUSE_RANDOM_PARAMETERS機能追加。
・2016 Lateのほう、パラメーターファイル、MASTERとSLAVEに分けるのやめる。
・pythonの対戦スクリプトにPARAMETERS_LOG_FILE_PATHの追加。
・pythonの対戦スクリプト、gameoverコマンド正しく返すように修正。
・ランダムパラメーターのログファイルを分析するpythonのスクリプト追加。
・lateのパラメーターファイルは非公開に変更して、残りはGitHubに公開。
// やねうら王ライブラリを用いる電王トーナメント参加者様へ。
// Lateは書きかけなので使わないほうが無難です。(ただし使用を禁止するわけではないです)
■ 2016/09/24 V3.71
・Stockfish : Fix pin-aware SEE
・Stockfish : Simplify pinners conditions in SEE()
■ 2016/09/21～2016/09/22 V3.70
・ADAMの学習率0.5に変更。更新式、doubleの精度で計算するように変更。
・LOSS_FUNCTIONにCROSS_ENTOROPY_FOR_VALUE追加。
・AdaGradの学習率調整。
■ 2016/09/18～2016/09/20 V3.69
・自己対戦用のpythonスクリプトV3を用意。エンジンそれぞれに対して異なる持ち時間設定で対局できるようにした。
・Stockfish : Fix a warning with MSVC
・Stockfish : Fix indentation in struct FromToStats
・教師局面の生成、USE_RANDOM_LEGAL_MOVE追加。(こちらをdefaultに変更する。)
・教師局面の生成、最大手数を512に変更。
・MultiThinkGenSfen::thread_workerでconst intのMAX_PLYがglobalのMAX_PLYと被っていたの修正。
・USE_DEBUG_ASSERT有効のときに、エラーメッセージ出力後、停止するように変更。
・教師局面からの学習で、クロスバリデーションのために保存している局面は2周目でも学習には使用しないように変更。
・教師局面からの学習、weight_updateをOpen MPで並列化した。(Open MPを有効にしてコンパイルすること)
・教師局面からの学習に、やねんざメソッド実装。
・解説.txtにOpenMPのことを追記。
・教師局面からの学習のときに、kppのmin,max,sumを出力する機能を追加。
・教師局面からの学習、局面をメモリ上のバッファから読み込んだ時点で局面数をカウントしていたの修正。
・教師局面からの学習設定としてUSE_KPP_MIRROR_WRITE追加。デフォルトではこれをオフに。
■ 2016/09/17 V3.68
・Stockfish : Renaming in MovePicker
・Stockfish : Pinned aware SEE
・Positionクラスにattackers_to(to,occ)追加。
・Position::see()、リファクタリング。
・SIMPLE_SEEでないほうのコード、削除。スッキリ。
・min_attackerで角・飛車に馬、龍が混じっていたの修正。
・move_picker_2016Q3.hのMovePicker::pick_the_best()を.cpp側に移動。
・Position::pawn_promotion()追加。
・Stockfish : Use per-thread counterMoveHistory
→ コア数が多いと効果があるが、コア数が少ないか持ち時間が少ないとマイナスの効果があるようだ。
・CSAルール改正に伴い、MinumumThinkingTimeのデフォルト値を2000から1000に変更。
・自己対戦用のpythonスクリプト、score cp XXX のところに数字以外が送られてくるエンジン向けに修正。
■ 2016/09/16 V3.67
・GEN_SFENのときでも、探索部で連続王手の千日手は有効にしておく。
・Stockfish : Change from [Color][PieceType] to [Piece]
・Stockfish : Prune dangerous moves at low depth
・Stockfish : Integrate next_stage() logic into next_move()
・move_piceker_2016Q3.cpp、変数名をStockfishに合わせた。
・調整パラメーターにPARAM_FUTILITY_AT_PARENT_NODE_GAMMA追加。
・GEN_MOVE_TYPEにQUIETSをaliasとして追加。
・指し手生成で回避手、王手の指し手生成のときにcapture_or_pawn_promotion()の判定要らなかった。修正。
■ 2016/09/05 V3.66
・movegenで歩成りの王手生成時の上位8bitに格納する駒が間違っていたバグ修正。(ysさん、thanks!)
・learn.cppでsize_tを使っていたところ、一部u64に変更。
■ 2016/09/03 V3.65
・nanoがビルド通らなかったの修正。
・LONG_EFFECTありのmated1plyがコンパイル通らなかったの修正。
・Position::key()追加。
・learn.hにLEARN_GENSFEN追加。
・Key exclusion_key() → 削除
・futilityでpos.see_sign()を使っていたところ、see()に変更。
・PARAM_REDUCTION_BY_HISTORY = 10000に戻す。
・g++用のmakefileでLATE_ENGINEがコンパイル出来なかったの修正。
■ 2016/09/02 V3.64
・update_stats()整理。
・反駁ペナルティ等の変更。
・ONE_PLYを2,4,8,...できちんと動作するように変更。
・history pruningのときにkillerの判定しないように変更。
・CheckInfo、StateInfoに隠匿。CheckInfoUpdate削除、CheckInfoUpdate()関係すべて削除。
・Position::check_blocker()削除。
・Position::silder_blockers()追加。
・is_aligned()廃止。aligned()追加。aligned()の引数の並び順をStockfishに合せる。
・Position::check_info_update()を呼び出さなくて良くなった。
・Optionクラス、spin型でもto_string()が呼び出せるように変更。
・testコマンドの最初でis_ready()を呼び出すように修正。
・set_check_info()、null_move()のとき処理を分離した。
■ 2016/08/31 V3.63
・学習のときのmini-batchサイズをlearnコマンドのときに指定できるように。
・学習時の評価関数ファイルの保存を8000万局面ごとに変更。
■ 2016/08/30 V3.62
・pythonスクリプトに、自己対局のときに評価値つきの棋譜を残す機能追加。
・教師局面生成時に千日手局面に突入したらその対局を終了するように変更。
■ 2016/08/26 V3.61
・目的関数=勝率の関数のときにも、YANE_SGD_UPDATEの更新式を用意。
・SGDのeta2、constにしてて、global変数参照してた…。0になってたのか…。
■ 2016/08/22 V3.60
・YANE_SGD_UPDATE追加。
・2016Lateをmakebookコマンドに対応。
・test exambookコマンド追加。
・KPPTのときに評価関数名が、usiの応答に対して出力されていなかったのを修正。
・learnコマンドでrmseの計算にsfen_unpack()を使っていたところをset_from_packed_sfen()に変更。
・自己対戦フレームワーク、readyokに対して初回のみ1秒のwaitを追加。
■ 2016/08/20 V3.59
・自己対戦フレームワークに、time outの処理追加した。
・search()のmate1判定、depth == ONE_PLYでもやるように変更。
・IID単純化。
・captureでのLMR追加。
・2016Late engineをgensfenコマンドに対応。
■ 2016/08/19 V3.58
・2016Late engine書きかけ。
・move_picker2016Q3追加。
・Search::search_endの説明が間違ってる気がする。消す。
・move_picker、capturesで歩の成り、考慮しない。
・move_picker、BadCaptureの順序変更。
・evaluateのときのTempo使わないように変更。
■ 2016/08/18 V3.57
・SSEなしのときにBitboardの>>=演算子の実装が間違っていたの修正。(ai5さん、thanks！)
・これに伴い、exeファイル、入れ替え。
■ 2016/08/17 V3.56
・局面生成、盤上に王が1枚しかないときに盤上の2駒を交換しようとするバグ修正。
・nodes as timeモードきちんと実装。
・MultiPV != 1のときにpreviousScoreが設定されていなかったバグ修正。
・評価関数ファイル、numaが異なるときは共有しない仕組みを用意。
・ソースコードにのponderまわりにコメント追加。
・新自己対戦フレームワーク、魔女との対局に対応。
・optionが存在しないときに"Error"の文字列を入れておく。(自己対戦フレームワークなどでtrapしたいため)
■ 2016/08/16 V3.55
・深いdepthでの枝刈り
・depth 1でのnull pruning追加。
・from_sq()追加。
・ColorFromTo historyを導入。
・評価関数パラメーター、共有メモリにCreateしたときはcheck sumを表示するように変更。
・pythonによる自己対戦スクリプト、思考エンジンから送られてきた"Display"を含む文字列はそのまま表示するように変更。
■ 2016/08/16 V3.54
・futility margin調整。
■ 2016/08/15 V3.53
・isready()のときのメモリチェックのコード追加。
■ 2016/08/14 V3.52
・pythonによる連続自己対戦フレームワーク(仮)
→ script/engine_invoker2.py追加。
■ 2016/08/09 V3.51
・Position::is_mated()でstalemateの判定がおかしかったのを修正。(tanuki-さんより報告あり)
■ 2016/08/04 V3.50
・レーティング計算用、pythonのスクリプトをプロジェクトに追加。→ script/calc_rating.py
・思考エンジンの設定をしてlocal-game-serverを呼び出す用のpythonのスクリプトをプロジェクトに追加。→ engine_invoker.py
・評価関数ファイルの読み込みに失敗した場合、エラーを表示したあと1秒待つようにした。
・local-game-serverに子プロセスの終了判定のコード追加。
・local-game-server、プロセスの起動に失敗したときのコード追加。
■ 2016/08/01～2016/08/03 V3.49
・短い時間に対するrtime時の勝率に与える影響が大きいようなので思考時間のランダム化を少し抑制。
・benchコマンドの引数の説明が、USI拡張コマンド.txtのほう、間違っていたので修正。(uuunuuunさんより指摘あり)
■ 2016/07/30～2016/07/31 V3.48
・gensfenのときにeval_limitを指定できるようにした。
・learn.hからGEN_SFENS_EVAL_LIMIT削除。
・局面生成、規定回数になっていないのに終了するバグがあるようだ。
→ 圧縮ドライブに対する細切れのfwrite自体、異様に時間かかるようだ。
・局面生成の表示まわり、変更。終了時にも最終的な出力したsfenの数を表示するように。
・局面生成、規定回数ぴったりにならないバグ修正。
■ 2016/07/28 V3.47
・local-game-serverにEngineConfigDirオプション追加。
・local-game-serverにBookSfenFileオプション追加。
・local-game-serverにEngineNumaオプション追加。
・local-game-serverで指定する対局回数は、対局回数は並列化されている分も考慮した、
トータルでの対局回数に変更。この回数に達すると対局中のものは中断して打ち切る。
・local-game-serverにおいて、goコマンドのあとstopで停止できないように変更する。そうしないとquitをqueueに積めない。
・やねうら王2016において定跡なしを選択できるように拡張。
■ 2016/07/26 V3.46
・Jenkins対応を進めていく。
・gensfenコマンド、生成するファイル名を指定する手段を用意。
・kpptファイルのファイル名のほうにもスラッシュつけてたのでpath_combine()失敗していたの修正。
・gensfenのときに最後、finalizeしてないから指定局面数だけファイルに書きだされていないの修正。
・gensfenでloop回数を指定してもそのループ回数で終了しなかったの修正。(loop_count初期化忘れ)
・TEST_LEGAL_LEAF、デフォルトではundefinedに。
・EvalSaveDir optionを用意。learnコマンドのときに保存先フォルダはこれで変更することに。
・learnコマンドの保存の間隔を1億局面に1回に変更。
・learnコマンドのときファイル名出力したほうがいいや。(入力は、見えないと仮定すると)
・learnコマンドでのsaveのときにpath_combineするの忘れていたの修正。
■ 2016/07/25 V3.45
・learnコマンド使ったときに更新式を表示するように変更。
・epochの初期化忘れていたの修正。
・Adamでコンパイラ周りのバグ(?)回避。
・目的関数をlearnコマンド実行時に表示するようにした。
・learnコマンドでmini-batch sizeを指定できるようにした。
・YaneGrad、mini-batch sizeで学習率ηを変えるようにした。
・SGDのパラメーターもlearn.hではなく、自動的に計算して設定するように変更。
・learnコマンドにloop,dirの指定が出来るようにした。
・misc.hにpath_combine()を追加。
・evaluate_kppt.cppでは、EvalDirの末尾に'/'が指定されていても良いようにこれを用いるように変更。
・learnコマンドのdirオプションもpath_combine()を用いるように変更。
・learnでフォルダを掘るときにもpath_combine()を用いるように変更。
・SGD、mini-batchのサイズで学習率変える必要ない気がしたので修正。
■ 2016/07/24 V3.44
・learnコマンドのために置換表をオフにしているときは起動時に警告が出るように。
・プロジェクト設定、AVX2に戻していなかったの修正。
・gensfenコマンド、lockしてファイル書き出しているのが気持ち悪いのでworker別に作った。
・README.mdに電王トーナメントの参加者向けの情報追加。
・評価関数を共有メモリに配置する件、EvalDirが異なる場合は共有しないようにした。
YaneuraOu + USI version番号 + EvalDir名
が合致したときにのみ共有するようにした。
・evaluate_kppt_learn.cpp、ValueKkFloatとか、要らなかった。整理した。
・学習時のKK配列のlimitの緩和。
・学習時の更新式にAdam追加。
・定跡のバイナリサーチのバグ修正。(thx. merom686さん)
・Adamの学習率調整。
・Linux環境用のmkdirのwrapper書いた。(learnコマンドで用いる)
・makefile、Linux環境だと_LINUXというシンボルを定義するようにした。
・g++でbitop.hで警告が出ていたの修正。
■ 2016/07/23 V3.43
・評価関数バイナリ28種公開。README.mdに追記。やねうら王2016Midのreadme.txtに追記。
・KPPT評価関数において評価関数の共有をしない設定オプションを追加。
・↑の件YaneuraOu-2016-mid_ja.txtに反映。
・config.hにNO_SSE追加。
・やねうら王2016Mid、各CPU向けの実行ファイルビルドしなおして、exe/ に保存。
■ 2016/07/22 V3.42
・学習時に置換表を参照しないオプション追加。learn.hで書けるようにした。
・教師局面ファイル45億局面分、公開した。
・ミニバッチサイズをlearn.hに移動。
・learn.hで学習オプションのconfigureが出来るように。
・棋譜からの学習、ネットワーク上のファイルの読み込みに時間がかかるのでもう一段、バッファリングする。
・save_eval()で、Windows環境ならDirectoryを掘るように。
・棋譜からの学習、ファイルの保存でディレクトリ名変えるのは10億局面ごとに変更。
・update_weights()を呼び出すタイミング、調整した。
・LEARN_READ_SFEN_SIZE、learn.hに移動。
・棋譜からの学習のときにバックグラウンドでファイルを読み込むスレッドを追加。
・AdaGradとYaneGrad、5回目ぐらいまではg2のupdateのみにするようにした。
・save_eval()のときにフォルダ名を表示するようにした。
・learnコマンド、40HTでスケールアウトするように改良。
・learnコマンド、gensfenコマンド、出力を抑制するようにした。learn.hで設定可能。
・file_read_workerのjoin()忘れていたの修正。
■ 2016/07/21 V3.41
・sfenのunpacker、高速化。Position::set_from_packed_sfen()を作った。
・Position::set()のvalidation、ASSERT_LV3以上のときのみするように変更した。(ここが遅いと棋譜からの学習でボトルネックになるため。)
・SGDでのupdateのときの係数、目的関数に合わせて調整するようにした。
・学習の最後にも評価関数パラメーターをファイルに保存するコード追加。
・学習率η2導入。rateをlearn.hで設定できるようにした。
・評価関数パラメーターの各値にリミットをかける。
・AdaGradに最初のほうの更新量を抑制するε項を追加。
・AdaGradのkkpの更新式、タイプミスしてたの修正。
・10億局面ごとではなく5億局面ごとに評価関数ファイルに保存するように変更。
→ 保存間隔、learn.hに移動。
・SGDのηなどもlearn.hに移動。
・1万局面ごとに'.'を出力するかどうかもlearn.hで設定できるようにした。
・棋譜生成時の評価値の上限をlearn.hで設定できるようにした。またこの値を2000→3000に変更した。
・更新式にYaneGrad追加。learn.hで選択可能に。
・YaneGradによる更新式を実装。
・g++でlearner.cppでwarningが出ていたの修正。
■ 2016/07/20 V3.40
・学習のときにkppの次元下げを用いるように実装。
・Eval::save_eval()追加。
・2000万局面ごとに保存するコード追加。
・学習時にmean_error出力するように。
・rmse計算のときに置換表世代を新しくするコード追加。
・256手引き分けになるスコアは学習の妨げになるので棋譜生成のときにMAX_PLY-16までにしておく。
・棋譜からの学習のときに浅い探索の結果としてevaluate()とqsearch()を選択可能に。
・learn.h追加。学習時のオプションはここにまとめた。
・AdaGradの更新式においてサンプル数で割り算するのをやめる。
・updateのときにmax_kkpを表示するようにした。
・AdaGradで最初のほうは値を動かさないように改良。
・AdaGradの学習率調整。
・目的関数として交差エントロピーを実装。
・交差エントロピーの目的関数の導出式をソースコード上に書いた。
・評価関数のファイル名、evaluate_kppt.hに移動。
・save_eval()、evaluate_kppt_learn.cppに移動。
・学習のときに、10億局面ごとに保存する評価関数ファイル名を変更するようにした。
■ 2016/07/17 - 2016/07/19 V3.39
・learnコマンド少し実装。packed sfenファイルの読み込みとshuffle～unpackのコードは書けた。
・learnでmse計算するコード追加。
・learnで∂J/∂Wiを計算するコードまで書けた。
・Eval::add_grad(),update_ada_grad(),init_grad()を追加。
・学習時の損失関数を選べるようにした。
・Evall::add_grad()でrootでの手番を考慮してなかったので修正。
・Eval::update_grad()→update_weight()とリネーム。
・Eval::update_weight()にweight配列に関するassert追加。
・AdaGrad以外にSDGでのupdateも追加。
・EvalのLEARN関連、learnに移動させる。
・evaluate_kppt.h , evaluate_kppt_learn.cpp追加。
・勾配計算するときにshallowとdeep、逆にして関数に渡してた。修正。
■ 2016/07/16 V3.38
・USI原案に従い、sfen化文字列を修正する。
・定跡にも影響が出るので定跡ファイルを修正する。
・makebook sortコマンドを実行したときにsfen文字列を再構築するように変更する。
・inv_piece[]について質問があったのでソースコード上にコメントを追記。
・やねうら王標準定跡V1.01公開。
・やねうら大定跡V1.01公開。
・exeフォルダのやねうら王2016Mid差し替え。
■ 2016/07/15 V3.37
・kpp_mirror_write()まわり、盛大にバグっていたので修正。
・mir_piece[]の初期化コード、バグっていたので修正。
・kkp_mirror_write()、盤面180度回転させたときの符号が違ったので修正。
・bookのsfen文字列の比較部分のコード、少し改良。
・makebook sortコマンドのときに局面のsfenを正規化するように修正。
・ソースコードが2TAB(TAB=スペース2つ)だと、他の環境と合わせるの難しいので、
VS2015標準の4TABに変更していく。
・Linux環境でgetline()が'\r'まで残すので定跡にhitしない問題修正。
・ShogiGUIの検討モードで定跡の指し手が複数表示されない問題を修正。(multipvで定跡を出力するように変更)
・解説.txtにShogiGUIの検討モードのことを追記。
・開発者のために、depth 6でgensfenした10億局面を配布。
■ 2016/07/14 V3.36
・gensfenで圧縮棋譜を生成するときは拡張子をbinに変更。
・定跡を書き出すときにfinalizeで落ちるバグ修正。
・gensfenコマンドで評価値の絶対値が2000を超えたら出力しないように変更。
・exe/フォルダのやねうら王2016Mid差し替え。
・BookDepthLimitとしてゼロが指定されていたときに無視されてしたの修正。
・解説.txtに定跡DBにhitしたときに表示されるメッセージの説明追加。
・やねうら大定跡V1、公開。
■ 2016/07/12 V3.35
・gen_sfen()にis_ready()が抜けてた(気がする)ので修正。
→ MultiThinkが持っているので良いのか…。
・makebook thinkのときに終了時にコマンドのusageが出ていたの修正。
・makebook thinkでのDB上の出現頻度は、バージョンナンバーにしておく。→ やねうら大定跡も。
・やねうら大定跡はNarrowBookを必ずオフにする件、説明追記。
・MultiThinkでworker threadの終了を待つ方法がよろしくないので修正。
・gensfenコマンド、進捗がわかりにくいので改善。
・gensfenコマンドで定跡の局面は書き出さない＆思考しないように修正。
・gensfenコマンドで書き出すときに時刻を出力するように修正。
・gensfenでファイルを作るときにios::appでopenするように変更。
・やねうら大定跡では、手番側から見たスコアの良い順に指し手をソートしてあることを保証するようにした。
■ 2016/07/10 V3.34
・少ないメモリのマシンで思考エンジンを何十個も立ち上げようとしたときにメモリ不足になるので
評価関数をshared memoryを用いて他のプロセスと共有するための改造開始。(作業中)
・Positionのコンストラクタで平手に初期化すると、compute_eval()が呼び出され、このときに
評価関数テーブルを参照するが、isready()が呼び出されていないのでこの初期化が出来ない。
ゆえに、この処理はやめたほうが良い。
・KPPT評価関数でcoutを用いていたところ、sync_coutにしたほうが無難なので修正。
・ALIGNED()マクロ追加。
・g++でbook.cpp , learner.cpp にてwarningが出ていたの修正。
・評価関数テーブルを共有メモリを用いて実現するの、実装完了。→ Windows版はデフォルトでこの設定に。
→ 説明を解説.txtに追記。
・makebook、処理が終わったときにusageが出ていたの修正。
・_stricmp()がlinux系では存在しないらしくその場合、strcasecmp()で置き換えるように修正。
・makebookのときisready()を呼び出しておかないとPosition::set()などが出来ないので修正。
■ 2016/07/09 V3.33
・置換表のprobeを行わない設定追加。USE_FALSE_PROBE_IN_TT
(自己生成棋譜からの学習でqsearch()のPVが欲しいときに置換表にhitして枝刈りされたときにPVが得られないの悔しいので)
・benchのときに、複数スレッドだとmain threadの探索のnode数が表示されていた問題修正。
・benchで複数スレッドのときはmain threadとトータルの情報とどちらも表示することに。
・makebookコマンドに並び替え機能追加。
例)> makebook sort book_src.db book_sorted.db
・定跡をメモリに丸読みせずに指す機能追加。BookOnTheFlyオプション。
・exe/book/standard_book.dbをsort済みのものと差し替え。
・MemoryBookにon the fly機能追加。
・"usinewgame"に対してNo such optionと表示するようになっていたの修正。
・定跡を途中で選び直したときに前の定跡のclear()をしていなかったの修正。
■ 2016/07/05 V3.32
・探索による定跡生成、一定時間経過ごとに保存するようにした。
・makebook mergeコマンド追加。定跡ファイルのマージが可能に。
・book_write()で空のentryは書き出さないように修正。
・makebook thinkコマンドのときに思考対象node数を表示することに。
・定跡生成depth18で32手目ぐらいまで。→やねうら大定跡として公開する(かも)。
・makemove thinkコマンドに思考対象とする開始手数(startmoves)の指定を出来るようにした。
・やねうら王2016Midに新定跡を対応させる。USI option、定跡絡みの指定を大量追加。
o["BookEvalDiff"] << Option(100 , 0, 99999);
o["BookEvalBlackLimit"] << Option(0 , 0, 99999);
o["BookEvalWhiteLimit"] << Option(-140 , 0, 99999);
o["BookDepthLimit"] << Option(16 , 0, 99999);
・あまりBookEvalDiffを大きくすると、すぐに定跡DBにない局面に行ってしまう…。30ぐらいでいいや。
・Visual Studio 2015 Update3後、g++版とnpsがあまり大差ないようなのでg++版の実行ファイルをexe/から削除。
・思考エンジンの説明に、doc/解説などを読むように誘導。
・makebookコマンドでstartmovesの値が反映されてなかったの修正。
・makebook thinkコマンドで新たな指し手を追加していないときはSではなくsを出力してファイルの
書き出しはしないように変更。
■ 2016/07/04 V3.31
・スレッドにまたがってsearchを個別に呼び出すworker用のclass追加。extra/multi_think.cpp
・APRNG、意味ない気がしてきた。削除。
・gensfenまわり、MultiThinkクラスを用いて書き直し。そこそこ綺麗に書き直せた。
・bookまわりもMultiThinkクラスを用いて書き直した。そこそこ綺麗に書き直せた。
・Mid2016のsearch/qsearchのスタブ、デフォルトでsilentモードとした。
・is_ready()のほう、引数にPosition&を取るのやめる。これがあると余計な依存性が発生する。
・g++でbuild出来なくなっていたの修正。
・g++でbuildするとCFLAGS += -fltoをつけるとセグフォで落ちるので、Makefileからこのオブション、削除。
→ shogi.cppでSearch::init() (やねうら王2016Mid)が呼び出された瞬間に落ちている模様。g++のbugくさい。
・やねうら王2016Midにユーザー定跡機能追加。(user_book1.db～user_book3.dbまで)
・gensfenの動作テスト → gensfenうまく動いている。
・makebook thinkのときに思考対象局面のsfenを表示するように。
・makebookコマンドで無効なパラメーターが来たときのエラー出力追加。
・解説.txtのmakebookコマンドの説明がmoveとなっていたのでmovesに修正。
・makebookコマンドでMOVE_WIN/MOVE_RESIGNの処理してなかったので追加。
・局後学習機能 → 対局中にsfenを出力しておけばいいのだが、将棋所等でcsaファイル出力すればいいから…要らないか…。
・bookの生成モード動作テスト → うまく動くようになった。
・2016Midがconfig.hでLONG_EFFECT_LIBRARYをdefineしたままだったので修正。
・探索による定跡を生成して配布する。(準備中)
→ 4手目までdepth 24,MultiPV = 7
8手目までdepth 18,MultiPV = 5
の定跡ファイル作った。
■ 2016/07/03 V3.30
・gensfenで定跡を用いる機能追加。→ うまく動いている。
・ASYNC_PRNG追加。
・Mutexのtypedefをconfig.hに移動。
・gensfenで任意二駒をときどき入れ替える機能追加。USE_SWAPPING_PIECES → 動いてるっぽい。
・Position::do_move_by_swapping_pieces()追加。→ 書けた。うまく動いている。
・USIオプションの簡略入力のときに大文字小文字の区別をしないように変更。
・gensfenしたファイルを読み込む機能追加。(learnコマンドの一部) → テストコードはうまく動いているようだ。
・learnコマンド追加。→ 作業中
・定跡の自動生成機能追加。
・makebook from_sfen のほうのコマンド、from_sfenを指定せずに動いていたの修正。
・sfenを与えて思考させるためのmakebookコマンド追加。
> makebook think 2016.sfen yaneura_book.db move 16 depth 32 multipv 3
→ コード書けた。デバッグまだ。
■ 2016/07/02 V3.29
・sfen圧縮機能追加。(かきかけ)
・Position::sfen_from_rawdata()追加。
・sfen packer、misc/に移動。
・USE_SFEN_PACKER追加。
・USIで直接 Threads 1 とやったとき、setoption name Threads value 1と等価なようにする。
・公式のトップページに書いていた更新履歴、邪魔なので消す。
・sfen packer完成。
・gensfenコマンド、とりあえず完成。
・gensfenコマンド、packed_sfenで書き出す機能追加。
■ 2016/07/01 V3.28
・evalコマンドで呼び出すのをcompute_eval()に変更。
(root nodeではStateInfo::previousがnullptrなので差分計算できない)
・StateInfo::previousのところのコメント修正。
・YANEURAOU_2016_MID_ENGINE_LEARN 追加。
・learn/learner.cpp追加。
・test gensfenコマンド削除。gensfenコマンド追加。
・sfenのpacker/unpacker書いた。
・BitStreamクラス書いた。
・sfenの圧縮出力追加。(かきかけ)
・2016Midの定跡選択部がgccでコンパイルエラーが出るようになっていたの修正。
・Makefile修正。CFLAGSに-flto追加。
■ 2016/06/30 V3.27
・KPPTの評価関数、学習のときに使うのでKPPのmirrorを考慮したKPP配列の要素を参照するモードを用意。
・EVAL_LEARN追加。
・KPPTのLEARN用として、mirror_piece(),inv_piece()追加。初期化コード追加。
・Mir(Square)関数追加。
・kpp_write(),kkp_write()追加。
・棋譜生成のためのSearchのスタブにmulti pv、aspiration window searchを導入する。
・2016Midに定跡ファイルの選択機能追加。
・read_book()で二度目はskipするように変更。
・プロジェクトからToDo削除。
■ 2016/06/29 V3.26
・qsearch()のassertを、ASSERT_LV3(abs(bestValue) <= mate_in(ss->ply));に変更。
・Apery(WCSC26)のKPP配列のp=0にゴミが入っているので、それをクリアするコード追加。(ただしコメントアウトしてある)
・KPPTを、KKPTだけにするテストコード追加。
・null move時のprefetch()削除
・2016Midでeval hashの使わないように変更。
■ 2016/06/28 V3.25
・EVAL_KPPT_FAST導入。
・KPPT型の超高速な評価関数、開発開始。(とりあえず非公開)
・Makefileに2016Late用の記述追加。
・Mid以外がbuildできなくなっていたの修正。VALUE_NOE_VALUATE→VALUE_NOT_EVALUATED
・nano/nano plusでassertで落ちるの修正。
・USE_TT_PVのときに置換表の指し手をpseudo_legal()でチェックしていなかったの修正。(nano/nano plus)
・MidでMovePickerから取得した指し手に対してpsudo_legal()のassert追加。
・nono plusでdraw_value返すときにvalue_from_tt通してなかったの修正。
・miniでOptions["Param1"]をextra_option()で追加していなかったの修正。
■ 2016/06/27 V3.24
・捕獲から逃れる指し手のところ、コメント追記。
・to_sq()をmove_to()のaliasとして、いまあるto_sqはsqww_to_sqに名前変更。
・HashTableにaligned_as(32)追加。
・KPPTの評価値の未計算値、VALUE_NOT_EVALUATEDに変更。フラグ位置をp[2][0]ではなくp[0][0]に変更。
・evaluate_nullmove()削除。
・KPPTの評価関数、リファクタリング。(Apery、魔女風にした)
・s32、s64等のtypedef追加。
■ 2016/06/26 V3.21～V3.23
・Position::moved_piece_after_ex()廃止。
・やねうら王2016MidではUSE_DROPBIT_IN_STATSなしに変更。
・ソースコード中にtabが混じっていたの修正。
・MakefileのPGO版のビルドプロセスで、quitコマンドの手打ちが必要だと
ビルドプロセスを自動化出来ないので、bench終了後にquitするようにMakefile修正。
・improvingの値比較、ひとつの条件をコメントアウト。(ひとつ前の式が暗黙的に含んでいるので)
・PV nodeをcutnodeで呼ぶことはなくなったのでpv && cutNodeという条件式は無駄なので省略。
・探索部、cmh,fmhまわりにコメント追加。
・long_effect.cppがg++でbuildが通らなかったの修正。
・mate1ply_with_effect.cppがg++でwarningが出ていたの修正。
・nanoがbuild通らなくなっていたの修正。
・棋譜の自動生成ルーチンを書く。(新学習メソッドで用いるので)
→ searchのrootMovesのセット、Learner::search()に移動させる。
・test gensfenのqsearch()のPVがきちんと得られるようにした。
・ENABLE_OPERATORS_ONをENABLE_BASE_OPERATORS_ONとENABLE_FULL_OPERATORS_ONに分離
・ENABLE_FULL_OPERATORS_ONにintとの割り算追加。depth / ONE_PLYが出来るように。
・fail low時のbonusを与える条件、変更。
・PARAM_IID_MARGIN_ALPHA追加。
・PARAM_FUTILITY_AT_PARENT_NODE_MARGIN、256に戻す。
・check extensionの条件、単純化。
・やねうら王2016Midでehash有効にする。
・capture_or_pawn_promotion() 高速化
・movegenで金相当の駒の指し手、Moveの上位16bitに金としてしまっていたバグ修正。
・gensfenコマンド、修正。
■ 2016/06/25 V3.20
・PVの出力の抑制。(出力が詰まるため)
・USIオプションに"PvInterval"追加。
・旧SEE、min_attacker()をtemplate化。min_attacker()での馬と龍の式を簡略化。
・新SEE周り、occupiedの初期化がされてない実行経路があったの修正。
・やねうら王2016Mid、新see()を使うように変更。
・_mm_alloc()を使うのにg++では*intrin.hをincludeしないときにmm_alloc.hをincludeする必要があるので修正。
・CapturePieceValue[KING]=VALUE_ZEROに変更。これで問題ない。
・Makefile PGOがかけられるように修正。
・misc.cppにprefetch()追加。
・do_null_move()のときにはprefetch()するように変更。
■ 2016/06/24 V3.19
・Macのg++でbuild出来るようにbitop.hにSSE/AVX用のincludeを集めた。
・USE_SSE4廃止。USE_SSE41追加。
・kpptのevaluate()でSSE4の命令をUSE_SSE2で使っていたの修正。
・std::round()、C++11では使えるが、C++14だと使えない…？！msys64でコンパイルしたのがいけないのか…そうか。
・g++でコンパイルしたほう、2割ぐらい速くなった。
・SSE4.2用のinclude headerは<nmmintrin.h>か。追加した。実行ファイル差し替え。
・AVX512対応考える。
・extra/config.hでターゲットCPUの選択、下位CPUのdefineは自動的に選択されるようにした。
・Makefileを使ってビルドするときは、config.hを変更しなくともターゲットCPU用の実行ファイルがビルド出来るように。
・やねうら王2016Mid以外もmakeでbuild出来るようにする。
・探索部のファイル名、*-search.cppで統一する。
■ 2016/06/23 V3.18
・利きを用いないmate1ply()、離し飛車・角に対して合駒判定間違えていたの修正。
・利きを用いないmate1ply()、歩の移動による詰み、歩の開き王手による詰みを間違えていたの修正。
・#includeするときのfolder separatorが"\"になっていたものを"/"に修正。(thx.もりたにさん)
・文字コードがcp932になっていたファイルをutf8に修正。(thx.もりたにさん)
・INT_MAXにclimits、offsetofにはcstddefが必要だそうで追加。(thx.ingkさん)
・評価関数の未計算値をINT_MAXにしているの、VALUE_NOT_INITとかにしたほうがわかりやすい気はしなくもないが..。まあいいか。
・g++でvalueが未初期化かもというwarningが出るのを回避するコードを追加。
・Ubuntu16.04でmake avx2が通ることは確認した。
・parameters.h → 2016-mid-param.hにリネーム
■ 2016/06/22 V3.16～V3.17
・razoring margin調整。
・王手延長の単純化
・IIDのとき、常にcut nodeにするのではなく、そのnodeのcutNodeを伝播させる
・Makefile、フォルダを自動的に掘るように修正。(thx. tanuki-さん)
・Moveが32bitにともない、MemoryBookが16bitでMoveを持っていると合致しないことになる。
MemoryBookをstructに変更して、なんとかする。
・noSSE/SSE2/SSE4/SSE4.1/AVXの命令を分けた。SSEなしでも動くはず。
・gcc用の64bit環境の判定、一箇所抜けてた。そこを使わないようにリファクタリングした。
・評価関数の格納されているフォルダ名のセパレータ、"\"ではなく"/"を使うように変更。(Linux/Mac対応)
■ 2016/06/21 V3.12～V3.14
・qsearch()を直接呼び出せるようにした。(学習で用いるので)
・教師棋譜を自動生成するtest gensfenコマンド追加。(書きかけ。まだ正しく動作しない)
・IID時のkillerをセットするコード削除。
・KPPT用のevaluate hashtableを実装。
・razoring margin、1秒対戦で自動調整。
・paramters_master.h読み込み時にparamの要素の数が足りないときに詳細エラーを表示するようにした。
・Msys2上のg++でコンパイルが通るようにした。Makefile追加。
・struct名ymmだとg++でコンパイルが通らないので変更。
■ 2016/06/20 V3.11
・history、駒打ちを区別するかどうかをUSE_DROPBIT_IN_STATSで切り替えられるようにした。
・ExtMove、Move32を格納するように変更。
・MovePickerのkillerまわり修正。
・evalのフォルダをUSIのsetoptionで変更できるように。
・指し手生成段階で移動先での駒種 + 打ち駒なら32 をしたものを上位bitに格納するように変更。Moveの32bit化
・#define KEEP_PIECE_IN_COUNTER_MOVE 削除。
・駒打ちの駒(+32)を cout << pc;のようにして表示できるように拡張。
・Move move_from_usi(const std::string& str)に、Move16が返るというコメント追加。
■ 2016/06/18 V3.10
・更新履歴が見にくいので実験記録を分離。
・ここまでの古い更新履歴は old/更新履歴2016Q2まで.txtに移動。
・予定はToDoのリスト.txtに移動。
・長い持ち時間のときの勝率upのためのチューニング(長い持ち時間において+R120)
・ONE_PLY_EQ_1を定義するとONE_PLYが1になるようにした。
・静止探索でのmate1ply()のタイミング少し早めにする。
・PieceValueCapture名前おかしいのでCapturePieceValueに変更。
・update_stats()するの、capture or pawn promotionであるべきか…。そうか。
・駒打ちに対するmove_from()にassert追加。
・駒打ちの駒を得るのにmove_from()を使っていたところ、move_dropped_piece()を使うように変更。
・MovePickerのGOOD_RECAPTURESにassert追加。
・Apery風のSEE()も実装した。USE_SIMPLE_SEEをdefineすると使える。
・min_attackerの引数からpiece_bb削除。
・SEE()で、と金で駒を取るときにそれがKING+1で王がとられる扱いになっていたの修正。
・SEE()のordering修正。
・historyのupdate()を呼び出すときに打ち駒で+32していないところがあったのを修正。
やねうら王 更新履歴 2016Q2まで
・公式のトップページに書いていた更新履歴、邪魔なので消す。
※ 括弧のなかの+Rは、自己対局時の勝率から計算されるもので、0.5手延長などは顕著に勝率が上がりますが、自己対局以外では効果に乏しいです。
- [x] 2016/07/02・sfen packer追加。
- [x] 2016/06/27・KPPT evaluate()リファクタリングと高速化。
- [x] 2016/06/26・やねうら王2016Midの探索部、調整。
- [x] 2016/06/26・指し手生成部のバグ修正。
- [x] 2016/06/26・やねうら王2016Mid、historyで駒打ちを区別しないように変更。
- [x] 2016/06/25・やねうら王2016Mid、新SEEに差し替え。
- [x] 2016/06/24・MacOS、Ubuntu16.04でコンパイル出来ました。
- [x] 2016/06/23・利きを用いないmate1ply()、離し飛車・角に対して合駒判定間違えていたの修正。
- [x] 2016/06/23・利きを用いないmate1ply()、歩の移動による詰み、歩の開き王手による詰みを間違えていたの修正。
- [x] 2016/06/23・#includeするときのfolder separatorが"\"になっていたものを"/"に修正。(thx.もりたにさん)
- [x] 2016/06/23・文字コードがcp932になっていたファイルをutf8に修正。(thx.もりたにさん)
- [x] 2016/06/22・やねうら王2016Midの定跡の指し手ささなくなっていたの修正。
- [x] 2016/06/22・やねうら王2016Midの開発終了。(ひとまず)
- [x] 2016/06/22・やねうら王2016Mid、noSSE/SSE2/SSE4/SSE4.1/AVX用バイナリを公開。
- [x] 2016/06/22・noSSE/SSE2/SSE4/SSE4.1/AVX2の命令を分けた。SSEなしの環境でも動くはず。
- [x] 2016/06/22・やねうら王2016Mid、g++でコンパイルしたWindows用実行ファイルも配布。
- [x] 2016/06/21・やねうら王2016Mid、Msys2上のg++でコンパイルが通るようにした。Makefile追加。
- [x] 2016/06/21・教師棋譜を自動生成するtest gensfenコマンド追加。(書きかけ。まだ正しく動作しない)
- [x] 2016/06/21・KPPT用のevaluate hashtableを実装。
- [x] 2016/06/20・やねうら王2016Mid、大改造。
- [x] 2016/06/20・評価関数格納フォルダをUSIのsetoptionで変更できるように。
- [x] 2016/06/18・長い持ち時間での勝率upのためのチューニング各種。
- [x] 2016/06/17・利きを用いないmate1ply()実装。
- [x] 2016/06/16・どの探索部でもすべての評価関数が使えるように抽象化した。
- [x] 2016/06/15・MovePickerのquietの指し手返すところのバグ修正。
- [x] 2016/06/14・Bonanza6風の1手詰めルーチンを追加。
- [x] 2016/06/14・やねうら王2016Mid、singular extensionまわり調整。(長い持ち時間において強いはず)
- [x] 2016/06/13・やねうら王2016Mid用のMovePicker追加。history、counter moveまわり大改造。
- [x] 2016/06/13・MovePicker、探索部ごとに変更できるように。
- [x] 2016/06/13・singular extensionの係数を初期のものに戻す。長い時間ではそちらのほうが勝率が高い。(長い持ち時間において+R70)
- [x] 2016/06/13・入玉判定のときに手駒の金を足してなかったの修正。
- [x] 2016/06/02・Apery(WCSC26)の評価関数の読み込み対応完了。(+R105)
- [x] 2016/06/01・Apery(WCSC26)の評価関数の読み込み対応作業中。
- [x] 2016/05/20・EvalListまわり、SIMD化しやすいように修正。
- [x] 2016/04/19・やねうら王2016(Mid) パラメーター自動フレームワーク関連の作業中。
- [x] 2016/04/15・やねうら王classic-TCE(TimeControlEnabled)版を正式公開する。
- [x] 2016/04/15・やねうら王2016mid、ハイパーパラメーターの動的な読み込み部書いた。
- [x] 2016/04/14・depthの3乗ボーナスやりすぎだったようなので修正。(+R10)(thx.woodyringさん)
- [x] 2016/04/14・浅い探索のときでも、killerがないならkillerぐらい更新したほうが得なのでは。(+R33)(thx.読み太の作者)
- [x] 2016/04/14・skipEarlyPruning時にkillerとhistoryを更新しない。(+R25)(thx.読み太の作者さん)
- [x] 2016/04/14・MAX_PLYとmax_game_plyの判定を一本化
- [x] 2016/04/14・ponder消失問題に対応。
- [x] 2016/04/14・自己対戦フレームワークで定跡データベース中の対局の手数が指定した手数より少ない場合クラッシュするっぽいバグ修正。(thx. tanuki-)
- [x] 2016/04/14・やねうら王2016 MidとLateに分離。
- [x] 2016/04/13・singularのときkiller,historyを更新しない。(+R10)(thx.読み太の作者さん)
- [x] 2016/04/13・ehashの仕組み追加したが速くならなかった。
- [x] 2016/04/12・historyとか、成りの指し手のときは、成り駒のhistoryを見ないといけないのにそういう処理になってなかった。(thx. 読み太の作者さん)
- [x] 2016/04/11・classic-tce、aspiration depth間違っていたの修正＆調整。(+R8)
- [x] 2016/04/08・王手がかかっていないときはstaticEvalをVALUE_NONEに。(+R4)
- [x] 2016/04/07・history等に駒打ちの情報を追加。(+R20)
- [x] 2016/04/07・dynamic margin実験。
- [x] 2016/04/07・go infiniteでstopが送られて来ていないのにbestmoveを返すことがあったのを修正。
- [x] 2016/04/07・優等局面のVALUE変更。
- [x] 2016/04/07・counter moveには、先手用の指し手に後手の指し手が混じらないように変更。
- [x] 2016/04/07・自己対戦サーバーでStateStack、1局ごとにクリアするように修正。
- [x] 2016/04/07・MaxMovesToDrawの設定が無視されていた問題を修正。
- [x] 2016/04/06・やねうら王classic-tceにsingular extension追加。(+R40)
- [x] 2016/04/06・やねうら王classic-tce。counter moveに駒種を入れる。
- [x] 2016/04/06・やねうら王classic-tceに。bestmove changed のカウンター、インクリメントしてなかったの修正。(+R20)
- [x] 2016/04/06・やねうら王classic-tceに。alpha更新のタイミングでeasy moveをクリアしていなかったの修正。
- [x] 2016/04/06・やねうら王classic-tceに。qsearch()のfutilityでcaptureを考慮するように変更。
- [x] 2016/04/06・VALUE_WINまわりの処理、色々修正。
- [x] 2016/04/06・byoyomiが指定されていないときの動作修正。
- [x] 2016/04/04・やねうら王classic-tceに、Options["NetworkDelay2"]を追加。
- [x] 2016/04/04・やねうら王twig→やねうら王classic-tceに名前変更。
- [x] 2016/04/04・やねうら王twigに持ち時間制御入れる。(+R50)
- [x] 2016/04/04・やねうら王twigにEasyMoveの判定追加。
- [x] 2016/04/03・やねうら王twig、終局までの手数に対応。
- [x] 2016/04/03・やねうら王twig、フィッシャールールに対応
- [x] 2016/04/03・やねうら王twigにponder対応。(+R50)
- [x] 2016/04/03・思考時間の計算用のクラス追加。
- [x] 2016/04/03・benchコマンド時に2個目以降の局面で正しくnpsが表示されなかった問題を修正。
- [x] 2016/04/03・やねうら王twigからタイマースレッド削除。
- [x] 2016/04/03・やねうら王classicからやねうら王twigにfork。
- [x] 2016/04/03・mate1ply修正。(thx. tさん) (+R3)
- [x] 2016/04/02・やねうら王classicのnonPV時のreduction定数、調整。(+R10)
- [x] 2016/04/02・kppファイル読み込み時の変換するためのメモリを動的に確保するように変更。
- [x] 2016/04/02・やねうら王classic、local-game-server、入玉宣言勝ちに対応。
- [x] 2016/04/02・MovePickerのevasion、capture時のordering調整。(+R13)
- [x] 2016/04/02・やねうら王classicのPV時のreduction定数、調整。(+R20)
- [x] 2016/04/01・MovePickerにfollowup move追加。
- [x] 2016/04/01・やねうら王classicのhistory bonus考えなおす。
- [x] 2016/04/01・やねうら王classicにsingular extension調整してみる。
- [x] 2016/04/01・やねうら王classicのRecaptureのオーダリング調整。
- [x] 2016/03/31・see()高速化。(thx. tさん) (+R5)
- [x] 2016/03/31・mate1ply修正。(thx. woodyringさん) (+R15)
- [x] 2016/03/30・やねうら王2015から評価関数ファイルの変換に失敗していたので読み込み時に修正するコード追加した。(+R40)
- [x] 2016/03/30・classicでevaluate()を毎node呼び出しておかないとevaluate()の差分計算がなされないので修正。(thx. tさん、わるおさん) (+R40)
- [x] 2016/03/30・mini,classicでNULL MOVEの前のcheck_info_update()が抜けていたので修正。
- [x] 2016/03/30・classicでcheckinfoのupdateが抜けている経路があったので修正。
- [x] 2016/03/30・depth 4手浅いものより大きいなら置換表のエントリー書き換えるように変更。
- [x] 2016/03/30・置換表格納のときにkeyのcastが間違っていたの修正。(棋力に影響なし)
- [x] 2016/03/30・Positionクラス、eval_list()関数は、戻り値はEval::EvalList型ではなくEval::EvalList*型を返すように修正。(thx. わるおさん)(+R15)
- [x] 2016/03/25・CounterMoveHistoryStateの更新と取得に失敗していた件、修正。(thx. tさん) (+R55)
- [x] 2016/03/25・置換表にDEPTH_MAX書き出せなくなってた件、修正。(thx. tさん)
- [x] 2016/03/25・mate1ply()でpinnedを使っているので先行してcheck_info_update()が必要なので修正。(thx. tさん)
- [x] 2016/03/25・pseudo-legalのチェックで、counter moveの手は手番に関係ない(ような実装になっている)ので、
違法手のチェックが必要だったのでその修正。(thx. woodyringさん)
- [x] 2016/03/25・mate1ply()でpinnedを使っているので先行してcheck_info_update()が必要。(thx. tさん)
・classic、mini、nano plus修正。
- [x] 2016/03/25・classicで1手詰めを呼び出すときに王手がかかっているかのチェックするの忘れていたの修正。(thx. woodyringさん)
- [x] 2016/03/25・古いほうの置換表実装削除。(置換表が弱くなる原因ではなかったようなので)
- [x] 2016/03/25・nanoで常にfull depth searchになっていたバグを修正。(thx. kazuさん)
- [x] 2016/03/25・seeのバグ修正。(thx. tさん、woodyringさん) (+R15)
- [x] 2016/03/04・打ち歩詰めの判定修正。(thanks to tanuki-さん)
- [x] 2016/03/01・やねうら王classic、悪いhistoryにreduction量を増やす枝刈り追加。
- [x] 2016/03/01・やねうら王classic、引き分け時のスコア、value_from_tt()を通すようにした。
- [x] 2016/03/01・やねうら王mini、引き分け時のスコア、value_from_tt()を通すようにした。
- [x] 2016/02/29・fail lowを引き起こした直前のcounter moveに加点するようにした。
- [x] 2016/02/29・1手詰めを見つけたときのスコアがおかしかったの修正。
- [x] 2016/02/29・やねうら王miniに定跡のnarrow book機能入れた。
- [x] 2016/02/29・やねうら王classicに定跡のnarrow book機能入れた。
- [x] 2016/02/29・思考エンジンごとにUSIのOptionを追加できるようにした。
- [x] 2016/02/29・やねうら王miniの静止探索で駒取りにならないevasionの枝刈り追加。(+R100)
- [x] 2016/02/29・やねうら王classicの静止探索で駒取りにならないevasionの枝刈り追加。(+R100)
- [x] 2016/02/29・やねうら王miniの静止探索にfutilityによる枝刈り追加。(+R70)
- [x] 2016/02/29・やねうら王classicの静止探索にfutilityによる枝刈り追加。(+R70)
- [x] 2016/02/29・やねうら王classicに親nodeでSEE負の指し手を枝刈り追加。(+R40)
- [x] 2016/02/29・やねうら王classicに親nodeでのfutility枝刈り追加。(+R40)
- [x] 2016/02/29・やねうら王miniにhistoryに基づく枝刈り追加。(+R20)
- [x] 2016/02/29・やねうら王miniで通常探索時の1手詰め判定削除。
- [x] 2016/02/29・やねうら王classicにhistoryに基づく枝刈り追加。(+R150)
- [x] 2016/02/29・やねうら王miniのソースコード、整理。効果の薄い枝刈り削除。
- [x] 2016/02/29・やねうら王miniにmoveCountベースのfutility追加。(+R150)
- [x] 2016/02/29・やねうら王classicにmoveCountベースのfutility追加。(+R150)
- [x] 2016/02/28・やねうら王classicに王手延長追加。(+R50)
- [x] 2016/02/28・やねうら王classicに多重反復深化追加。(+R12)
- [x] 2016/02/28・やねうら王classicにProbCut追加。(+R70)
- [x] 2016/02/28・やねうら王miniにProbCut追加。(+R70)
- [x] 2016/02/28・MovePickerにProbCut用の指し手生成を追加。
- [x] 2016/02/28・やねうら王classicの開発開始。
- [x] 2016/02/28・やねうら王miniの思考エンジンの実行ファイルを公開。
- [x] 2016/02/28・やねうら王miniの開発終了。
- [x] 2016/02/28・local game serverでCreateProcessに失敗したときに復帰できるように修正。
- [x] 2016/02/28・やねうら王miniで定跡の指し手が指せていなかったの修正。
- [x] 2016/02/28・やねうら王miniにrazoring追加。(+R20)
- [x] 2016/02/28・やねうら王miniにnull move search追加。(+R60)
- [x] 2016/02/28・Position::do_null_move()/undo_null_move()追加。
- [x] 2016/02/28・MovePickerで置換表の指し手とcounter moveにおいて歩や大駒の不成などを除外するようにした。
- [x] 2016/02/28・Position::moved_piece()で後手の駒打ちのときに後手の駒が返るように変更。
- [x] 2016/02/28・QUITE_CHECKで歩の不成が生成されていた問題を修正。
- [x] 2016/02/27・Position::pseudo_legal()修正。
- [x] 2016/02/26・やねうら王miniでmain threadでfail high/lowが起きたときにGUIに読み筋を出力するようにした。
- [x] 2016/02/26・やねうら王miniのaspirationのdelta調整。(+R20)
- [x] 2016/02/26・やねうら王miniにlazy SMP実装。(4コア時+R220程度)
- [x] 2016/02/26・やねうら王miniにPV line実装。(-R10)
- [x] 2016/02/26・やねうら王miniにss->moveCount追加。これによるhistoryへのbonus追加。(+R30)
- [x] 2016/02/26・やねうら王miniにaspiration windows search実装。(+R10)
- [x] 2016/02/25・やねうら王miniの思考オプションにMultiPV追加。
- [x] 2016/02/25・やねうら王miniの思考オプションにContempt(引き分け時スコアの設定)追加。
- [x] 2016/02/25・nano plusをベースにしてやねうら王miniの探索部書いていく。
- [x] 2016/02/25・nano plus、開発終了。(R2500相当)
- [x] 2016/02/25・nano plus、bad captureをkillerの直後に。(+R25)
- [x] 2016/02/25・nano plusのMovePickerにEVASIONSのオーダリング追加。
- [x] 2016/02/25・nano plusのMovePickerにCAPTURESのオーダリング追加。(+R30)
- [x] 2016/02/25・nano plusにhistory,counter move,counter move historyを追加。(+R120)
- [x] 2016/02/24・nano plusのMovePicker、別ファイルに分離。
- [x] 2016/02/24・劣等局面の判定追加。(+R5)
- [x] 2016/02/24・nano plusの枝刈りにfutility pruning追加。
- [x] 2016/02/24・nano plusのMovePickerで静止探索時に置換表の指し手がpseudo-legalでないときに落ちていたの修正。
- [x] 2016/02/23・nano plusのMovePickerで置換表の指し手がpseudo-legalでないときに落ちていたの修正。
- [x] 2016/02/23・local game serverの子プロセスの起動タイミングをばらつかせる。(乱数seedをばらけさせるため)
- [x] 2016/02/22・nano plus、"go infinite"に対応させる。
- [x] 2016/02/22・PRNGのデフォルトの乱数seedの精度を上げる。
- [x] 2016/02/22・Position::is_draw()→is_repetition()に名前変更。2手遡るの忘れていたの修正。
- [x] 2016/02/22・test autoplayコマンド追加。
- [x] 2016/02/22・nano plusにサイレントモード追加。
- [x] 2016/02/22・打ち歩詰めの指し手生成、生成条件が間違っていたの修正。
- [x] 2016/02/22・やねうら王nano plus、search()に一手詰め判定追加。(+R10)
- [x] 2016/02/22・やねうら王nano plusに千日手判定追加。(+R20)
- [x] 2016/02/22・Position::is_draw()実装
- [x] 2016/02/21・打ち歩詰め関係、ソース整理。
- [x] 2016/02/21・指し手生成で打ち歩詰め除外したときに、pseudo_legal()に打ち歩詰め判定入れるの忘れていたので修正。
- [x] 2016/02/21・Position::capture()の処理間違っていたの修正。
- [x] 2016/02/21・やねうら王nano plus、full depth searchの処理修正と調整。(+R100)
- [x] 2016/02/21・やねうら王nano plus、improvingフラグ用意。(+R5)
- [x] 2016/02/21・やねうら王nano plus、通常探索でevaluate()を呼び出すように変更。(+R50)
- [x] 2016/02/21・local game server、エンジン側から非合法手が送られてきたときにMOVE_RESIGN扱いにするように。
- [x] 2016/02/21・打ち歩詰めの判定、高速化。(+R10)
- [x] 2016/02/21・pos.legal()、玉の影の利きがあるときの処理間違っていたので修正。
- [x] 2016/02/21・local game serverでserver側の負荷が高かったのを修正。
- [x] 2016/02/21・local game serverで思考エンジンがbestmoveを返さないとハングしていたでタイムアウト処理追加。
- [x] 2016/02/21・やねうら王nano plusのMovePickerのRECAPTUREの処理、修正。
- [x] 2016/02/20・やねうら王nano plusの静止探索の指し手生成を色々調整。(+R180)。
- [x] 2016/02/20・やねうら王nano plusの静止探索で置換表絡みの処理追加。
- [x] 2016/02/19・やねうら王nano plusにLMRの導入。(+R140程度)
- [x] 2016/02/11・起動時にファイルからコマンドを受け付ける機能追加。
- [x] 2016/02/11・起動時にargvとして複数行を実行する機能追加。
- [x] 2016/02/10・自己対局サーバー、1スレッド×同時対局(マルチスレッド)に対応させる。
- [x] 2016/02/09・Threadクラス大改修。→ thread絡みの問題が起きなくなった。(ようだ)
- [x] 2016/02/09・_mm_mallocが失敗する件、さらに調査。→ std::thread絡みの問題くさい。
- [x] 2016/02/09・_mm_malloc()自作した。→これでも失敗する。newに失敗しているのか。ランタイム腐ってるのか…。
- [x] 2016/02/09・ローカルサーバー機能、ときどき対戦が開始しないので原因を調査する。→_mm_mallocが高負荷状態で失敗するようだ…。
- [x] 2016/02/09・やねうら王nano plusにkiller moveの導入。
- [x] 2016/02/09・nano plusで1手詰めなのに探索局面が多すぎるのでmate distance pruning追加した。
- [x] 2016/02/09・ベンチマークコマンド書けた。
- [x] 2016/02/08・やねうら王nano plusでMovePickerでの指し手生成を逐次生成に変更。
- [x] 2016/02/08・やねうら王nano plusで1手詰め判定を呼び出すように。
- [x] 2016/02/08・gcc/Clangでコンパイル通るようにする→Clangは無理。gccは行けそうだが、時間かかりそうなので保留。
- [x] 2016/02/08・やねうら王nano plusの開発開始。
- [x] 2016/02/08・やねうら王nano、floodgateでR2000を超えたので、nanoの開発終了。
- [x] 2016/02/08・実行ファイルをプロジェクトの一部として配布する。
- [x] 2016/02/07・やねうら王nanoをnonPV/PVの処理をきちんと書く。(これでR2000ぐらいになっていればnanoの開発は終了)
- [x] 2016/02/07・KPPの評価関数の差分実装完了。
- [x] 2016/02/06・やねうら王nanoで定跡の採択確率を出力するようにした。
- [x] 2016/02/06・やねうら王nanoの定跡を"book.db"から読み込むように変更。
- [x] 2016/02/06・定跡の読み込み等をこのフレームワークの中に入れる
- [x] 2016/02/06・定跡生成コマンド"makebook"
- [x] 2016/02/05・やねうら王nanoの探索部
- [x] 2016/02/05・やねうら王nano秒読みに対応。
- [x] 2016/02/04・やねうら王nanoに定跡追加。
- [x] 2016/02/01・新しい形式に変換した評価関数バイナリを用意する → 用意した → CSAのサイトでライブラリとして公開された。
- [x] 2016/01/31・やねうら王nanoの探索部(WCSC26用)
■ 2016/06/17 V3.10
・qsearch()での宣言勝ち判定やめる。
■ 2016/06/17 V3.09
・mate1ply()に離し飛車・角での詰みを実装する
DIRECTIONS_CROSS
DIRECTIONS_DIAG
追加。
more_than_one_cr()削除。
秒読み1000[ms]
50.4%
#191
やねうら王2016mid V309
利きなしsmate/qmate。離し飛車・角。1スレッド
#190
やねうら王2016mid V308a
利きなしsmate/qmate搭載。1スレッド
114-10-112(42.1% R3.1)
ほぼ変わらない。もう少し長い時間では..？
秒読み3000[ms]
52.8%
#191
やねうら王2016mid V309
利きなしsmate/qmate。離し飛車・角。1スレッド
#190
やねうら王2016mid V308a
利きなしsmate/qmate搭載。1スレッド
113-7-101(18.7% R19.5)
離し角・飛車、判定があるほうがややいいのかも知れない。
■ 2016/06/17 V3.08
・MATE_1PLY→USE_MATE_1PLYに変更したときに、変更忘れてたところがあって、
mate1ply()用のビットボード初期化されてなかった。mate1ply()そのあと意味成してなかった。ワロタ。
・file,rank、負の値が取れるようにenum : int32_tにする。
・利きを使わないmate1plyの作業
→ 何も考えずにやねうら王2014のコードをコピペしまくったら完成した。2000行もあった。吐きそう。
1手詰め呼び出さないとき
===========================
Total time (ms) : 178391
Nodes searched : 116770147
Nodes/second : 654574
1手詰めを通常探索で呼び出すとき
===========================
Total time (ms) : 62710
Nodes searched : 41126951
Nodes/second : 655827
速度ダウンほとんどなしに(探索ノードが違うから厳密な比較はできないが)
通常探索での1手詰めを搭載出来た。儲け儲け？
V3.08a
qmate(静止探索)でのmate1ply()もあり。
2<Error : engine timeout , engine name = engines\YaneuraOu-2016-midV308a.exe
2< □ □ □ □^玉 □^桂 □ □
2< □ 玉 銀 □ □^角 銀 □ □
2< □ □ □ □ □ □ □ □ 龍
2<^香 □ □^角^歩^金 □ □ □
2<^金 □ □ 桂 □^歩^歩 桂^歩
2< □ 歩^歩 □ 歩 □ □ □ □
2< □ □ □^杏 □ 銀 □ □ □
2< □ 香 □ □ □ □ □^歩 □
2< □ □ □ □ □ □ □ 飛 香
2<先手 手駒 : 歩2 銀 , 後手 手駒 : 歩8 桂 金2
2<手番 = 先手
2<sfen 4k1n2/1KS2bS2/8+R/l2bpg3/g2N1ppNp/1Pp1P4/3+l1S3/1L5p1/7RL b 2PS8pn2g 175
落ちた。
more_than_one()がcross_over()前提としてなかった。
more_than_one_cr()追加
また落ちた。
5<手番 = 先手
5<sfen ln1g2g2/1r7/p1p4+Sp/1pkp5/4N1B2/2PPPPP2/PP2KbS1P/1G2L4/LN1r1G2L b 5PSns 77
can_legal_drop()ではなかったのか。修正。
1,3秒でV3.08とV3.08a
静止探索あるほうがやや得か？
秒読み1000[ms]
51.9%
#190
やねうら王2016mid V308a
利きなしsmate/qmate搭載。1スレッド
#189
やねうら王2016mid V308
利きなしsmate搭載。1スレッド
431-20-399(12.6% R13.4)
秒読み3000[ms]
52.0%
#190
やねうら王2016mid V308a
利きなしsmate/qmate搭載。1スレッド
#189
やねうら王2016mid V308
利きなしsmate搭載。1スレッド
194-11-179(20.4% R14.0)
秒読み3000[ms]
50.0%
#190
やねうら王2016mid V308a
利きなしsmate/qmate搭載。1スレッド
#0
silent_majority_V1.1公式
1スレッド
59-1-59(53.7% R0.0)
魔女公式とほぼ互角。assertなしにしてPGOかけると+R30ぐらいなのかな。
■ 2016/06/17 V3.07
・
> && pos.see(make_move(move_to(move), move_from(move))) < VALUE_ZERO)
このSEE値、ちゃんと自分側から見た値が返るのか？
→ 返っていない。手番側ではなく、最初に動かす駒側の手番として考えるべき。
+ stm = is_drop(m) ? sideToMove : color_of(piece_on(move_from(m)));
+ // 相手番(stm側の攻撃駒を列挙していく)
+ stm = ~stm;
さらにこうかな？
→ 修正したのでV3.03aと0.1秒対戦
秒読み100[ms]
48.4%
#188
やねうら王2016mid V307
futility marginテスト。1スレッド
#184
やねうら王2016mid V303a
0.5手延長, mateなし。1スレッド
248-6-264(77.4% R-10.9)
特にバグっていないようだが、強くもなってなさげ…？
・これで魔女と5秒で対戦させておく。
・futility marginのテスト
return Value(d * (90 + param1*27) );
秒読み5000[ms]
34.7% 33.0% 31.3% 29.5% 23.1%
#188
やねうら王2016mid V307
futility marginテスト。1スレッド
#0
silent_majority_V1.1公式
1スレッド
105-8-198(100.0% R-110.2) 97-8-197(100.0% R-123.1) 95-13-209(100.0% R-137.0) 92-10-220(100.0% R-151.5) 63-9-210(100.0% R-209.2)
やはり、そうか…。
評価関数が同じで探索部が近いから、自己対戦成績に近い結果になるはずで、
自己対戦のときも短い時間と長い時間とでfutilityなどは相関があったので、納得の結果。
V3.07a
・futlity pruningの前提depthも5..7で1手10秒で試す
// && depth < PARAM_FUTILITY_RETURN_DEPTH * ONE_PLY
&& depth < (param1 + 5) * ONE_PLY
秒読み5000[ms]
37.7% 34.0% 32.7%
#188
やねうら王2016mid V307a
futility前提depthテスト。1スレッド
#0
silent_majority_V1.1公式
1スレッド
84-11-139(100.0% R-87.5) 72-8-140(100.0% R-115.5) 48-9-99(100.0% R-125.8)
これも1手5秒の持ち時間ではやはりdepth = 5がベストのようだ。長い時間ではわからないが。
0.1秒でやったときと似た結果だと言える。
■ 2016/06/17 V3.06
・MovePickerのkillers、COUNTER_MOVEにしないと下位16bitしか入ってなくて
killer、除外できてなかった。なんだこれ。そら弱くなるわ…。
これで再度futilityのチェックを行う。
・千日手の検出等を、静止探索でやるのはコスト的に無駄なのでは…。これ結構重い気がする。
// 連続王手による千日手、および通常の千日手、優等局面・劣等局面。
// 連続王手による千日手に対してdraw_value()は、詰みのスコアを返すので、rootからの手数を考慮したスコアに変換する必要がある。
// そこで、value_from_tt()で変換してから返すのが正解。
- auto draw_type = pos.is_repetition();
- if (draw_type != REPETITION_NONE)
- return value_from_tt(draw_value(draw_type, pos.side_to_move()),ss->ply);
→ やねうら王 classic-tceにもこの修正を反映させる。
・killer、非適用になったときに、そのあとのquietsの指し手から除外してなかった。
// 今回移動させる駒種が一致するかを確認する。
// このチェックにより先手/後手の指し手であることが担保される。
if (move32 != make_move32(move))
{
+ // このkiller、非適用なのであとでquietsのときに除外されると困るからnullを書き込んでおく。
+ *((Move32*)currentMoves - 1) = 0;
break;
}
上のひどいバグだな…。V3.03aとテスト。
秒読み500[ms]
49.1%
#187
やねうら王2016mid V306
futility marginテスト。1スレッド
#184
やねうら王2016mid V303a
0.5手延長, mateなし。1スレッド
104-7-108(63.4% R-6.6)
こんなに致命的なバグを取ったのに、少し負け越した。まあ、短い時間ではあまり関係ないのだろう…。
■ 2016/06/16 V3.05
・depthボーナスおかしくないか？
(ss - 2)->counterMoves->update(prevPc, prevSq, -bonus - 2 * (depth + 1) / ONE_PLY - 1);
depth + 1って、ONE_PLY = 2のときこれでいいのだろうか..
(ss - 2)->counterMoves->update(prevPc, prevSq, -bonus - 2 * (depth + ONE_PLY) / ONE_PLY - 1);
こうが正しい気もするのだが..
・assertなし、利きなし、mate1plyなし
===========================
Total time (ms) : 113506
Nodes searched : 78131111
Nodes/second : 688343
遅すぎ。仮想環境だからか…。にしても遅いな…。
・futility marginのテスト
return Value(d * (90 + param1*27) );
長い時間でパラメーター再考。
param1 = 0..4
3秒でテスト。
・参考記録
秒読み3000[ms]
36.8% 39.1% 36.8% 28.3% 31.3%
#186
やねうら王2016mid V305
futility marginテスト。1スレッド
#0
silent_majority_V1.1公式
1スレッド
56-4-96(100.0% R-93.6) 59-5-92(99.7% R-77.2) 56-4-96(100.0% R-93.6) 43-4-109(100.0% R-161.6) 47-5-103(100.0% R-136.3)
■ 2016/06/16 V3.04
・静止探索のrecap、5までに変更。
- DEPTH_QS_RECAPTURES = -3*(int)ONE_PLY,
+ DEPTH_QS_RECAPTURES = -5*(int)ONE_PLY,
・evasion、LVA通したほうがいいような…。
if (pos.capture(m))
m.value = (Value)Eval::PieceValueCapture[pos.piece_on(move_to(m))]
- - Value(type_of(pos.moved_piece_before(m))) + HistoryStats::Max;
+ - Value(LVA(type_of(pos.moved_piece_before(m)))) + HistoryStats::Max;
・ここ、prevPcだわ。間違えてた。駒打ちのときに違ってくる。
if ((ss - 2)->counterMoves)
- (ss - 2)->counterMoves->update(pos.piece_on(prevSq), prevSq, -bonus - 2 * (depth + 1) / ONE_PLY - 1);
+ (ss - 2)->counterMoves->update(prevPc, prevSq, -bonus - 2 * (depth + 1) / ONE_PLY - 1);
・どの探索部でもすべての評価関数が使えるように抽象化。
void evaluate_with_no_return(const Position& pos);
を追加。
秒読み1000[ms]
45.7%
#185
やねうら王2016mid V304
オーダリング改善, mateなし。1スレッド
#184
やねうら王2016mid V303a
0.5手延長, mateなし。1スレッド
134-8-159(93.6% R-29.7)
なんか弱くなっとる。よく考える。
■ 2016/06/16 V3.03
・moveCount == 1(置換表)の指し手、必ず延長したほうがいいな。YSSの0.5手延長と同じ。
// 王手となる指し手でSEE >= 0であれば残り探索深さに1手分だけ足す。
if (givesCheck
+ && (moveCount == 1
→ これ、Stockfishでなんでやってなかったんだろう。はてはて。
・popcnt8()とか使わないから削除
・popcnt16()
// popcount16() counts the non-zero bits using SWAR-Popcount algorithm
unsigned popcount16(unsigned u) {
u -= (u >> 1) & 0x5555U;
u = ((u >> 2) & 0x3333U) + (u & 0x3333U);
u = ((u >> 4) + u) & 0x0F0FU;
return (u * 0x0101U) >> 8;
}
これも使わないから要らないや。
・bsf、テーブル使うと速いのか？
// De Bruijn sequences. See chessprogramming.wikispaces.com/BitScan
return BSFTable[(b * 0x3F79D71B4CB0A89ULL) >> 58];
みたいな？遅そう..。bsf使えない環境向けだな。
秒読み5000[ms]
36.8%
#183
やねうら王2016mid V303
0.5手延長, 1スレッド
#0
silent_majority_V1.1公式
1スレッド
25-0-43(99.0% R-94.2)
V3.03a mate1plyなし、利きなし。
秒読み10000[ms]
29.2%
#184
やねうら王2016mid V303a
0.5手延長, mateなし。1スレッド
#0
silent_majority_V1.1公式
1スレッド
33-2-80(100.0% R-153.8)
なんか弱くなった気がする。おかしい。
秒読み1000[ms]
46.2%
#184
やねうら王2016mid V303a
0.5手延長, mateなし。1スレッド
#180
やねうら王2016mid V299c
search、魔女化(), 1スレッド
72-6-84(85.1% R-26.8)
秒読み3000[ms]
47.5%
#184
やねうら王2016mid V303a
0.5手延長, mateなし。1スレッド
#180
やねうら王2016mid V299c
search、魔女化(), 1スレッド
201-12-222(85.8% R-17.3)
なんか弱くなってる感。
■ 2016/06/16 V3.02
・Limits.depthだけ回るとき、Threads.main()->rootDepthと比較すればいいのか..そうか..
・利きあり MATE1PLYあり。静止探索でのmate1plyなし。
秒読み20000[ms]
29.9%
#181
やねうら王2016mid V301
MovePickerバグ修正, 1スレッド
#0
silent_majority_V1.1公式
1スレッド
107-15-251(100.0% R-148.1)
まあ、こんなものなのか…。静止探索でのmate1plyありにして20秒で。
秒読み20000[ms]
26.8%
#182
やねうら王2016mid V301a
MovePickerバグ修正、Qmateあり, 1スレッド
#0
silent_majority_V1.1公式
1スレッド
56-13-153(100.0% R-174.6)
■ 2016/06/16 V3.01
・LazySMPにおいてinsert_pv_in_tt()は意味がないらしい。
// 探索中に置換表のPV lineを破壊した可能性があるので、PVを置換表に
// 書き戻しておいたほうが良い。(PV lineが一番価値があるので)
for (size_t i = 0; i <= PVIdx; ++i)
rootMoves[i].insert_pv_in_tt(rootPos);
→ 削除。(全エンジン共通)
・StockfishのLazySMP、バグってる。
if (!mainThread)
- break;
+ continue;
MultiPVのとき、mainThread以外が2番目以降のMultiPVの指し手を読まずに
次のiterationに行ってしまっていた。
・Stockfishの最新のimprovingFactorに変更する。
・MovePickerで
// ※ これ、指し手の数が多い場合、AVXを使って一気に削除しておいたほうが良いのでは..
if ( move != ttMove
- && move != killers[0]
- && move != killers[1]
- && move != killers[2])
+ && move != (Move)killers[0]
+ && move != (Move)killers[1]
+ && move != (Move)killers[2])
return move;
このとき、killerが32bit化しているときに一致せずに
重複して同じ指し手を調べていた。
・これで1手20秒で魔女公式と対局させておく。
■ 2016/06/14 V3.00
・利きを用いない1手詰め判定ルーチンを用意する。(やねうら王2014からporting)
extra/mate1ply_with_effect.cpp
extra/mate1ply_without_effect.cpp
・MATE_1PLY → USE_MATE_1PLYに名前変更。
extra/mate1ply_without_effect.cpp
→ コンパイルエラー218個。死にそう..
→ 205[16:10]..189[16:21]..181[16:28]..165[16:38]..休憩。
・利きのない一手詰めの移植だけで丸一日かかりそう..こりゃ大変だ。
・Position::pinned_piece(Color,Square avoidSq)みたいなの必要なので追加。
→ 追加した。
■ 2016/06/14 V2.99
・MovePickerのボーナス値、調整。
・FutilityMoveCounts、ONE_PLYで割るの忘れていた。修正。
bool moveCountPruning = depth < 16 * ONE_PLY
- && moveCount >= FutilityMoveCounts[improving][depth];
+ && moveCount >= FutilityMoveCounts[improving][depth/ONE_PLY];
・V2.90(基準用)と対戦させる。
rtime 500[ms]
54.8%
#177
やねうら王2016mid V299
search、魔女化(), 1スレッド
#171
やねうら王2016mid V290基準用
Apery(WCSC26) evaluate(), 1スレッド
161-6-133(4.5% R33.2)
rtime 1000[ms]
46.7%
#177
やねうら王2016mid V299
search、魔女化(), 1スレッド
#171
やねうら王2016mid V290基準用
Apery(WCSC26) evaluate(), 1スレッド
56-3-64(79.4% R-23.2)
弱い…？魔女とはどうか。
秒読み1500[ms]
55.2%
#177
やねうら王2016mid V299
search、魔女化(), 1スレッド
#0
silent_majority_V1.1公式
1スレッド
100-3-81(6.8% R36.6)
1.5秒だと勝ち越す。
秒読み5000[ms]
32.6%
#177
やねうら王2016mid V299
search、魔女化(), 1スレッド
#0
silent_majority_V1.1公式
1スレッド
30-1-62(100.0% R-126.1)
だいぶ負け越した。singular extensionの前提depthを10→8に変更する。
V2.99a
秒読み5000[ms]
40.8%
#178
やねうら王2016mid V299a
search、魔女化(), 1スレッド
#0
silent_majority_V1.1公式
1スレッド
53-1-77(98.6% R-64.9)
だいぶ良くなった。
V2.99b
- PARAM_DEFINE PARAM_QUIET_SEARCH_COUNT = 72;
+ PARAM_DEFINE PARAM_QUIET_SEARCH_COUNT = 64;
こう変えて、また5秒で回しておく。
秒読み5000[ms]
46.6%
#179
やねうら王2016mid V299b
search、魔女化(), 1スレッド
#0
silent_majority_V1.1公式
1スレッド
48-1-55(78.5% R-23.6)
だいぶ近づいてきた。10秒で回してみる。
魔女相手に長い持ち時間で各種パラメーターをチューニングするほうが良いかも知れない。
秒読み10000[ms]
29.6%
#179
やねうら王2016mid V299b
search、魔女化(), 1スレッド
#0
silent_majority_V1.1公式
1スレッド
21-2-50(100.0% R-150.7)
10秒だとひどいことになった。やる気なくした。
この状態で、1手詰めと利きの更新をオフにしてどれくらいの勝率になるのか計測する。
持ち時間を増やしたときに勝率の差が開くのは良くないチューニング。
つまりは通常探索での1手詰めはあったほうがいい可能性が。
V2.99c
秒読み5000[ms]
38.7%
#180
やねうら王2016mid V299c
search、魔女化(), 1スレッド
#0
silent_majority_V1.1公式
1スレッド
128-14-203(100.0% R-80.1)
---
秒読み10000[ms]
33.5%
#180
やねうら王2016mid V299c
search、魔女化(), 1スレッド
#0
silent_majority_V1.1公式
1スレッド
89-13-177(100.0% R-119.4)
---
秒読み20000[ms]
33.3%
#180
やねうら王2016mid V299c
search、魔女化(), 1スレッド
#0
silent_majority_V1.1公式
1スレッド
56-9-112(100.0% R-120.4)
---
秒読み40000[ms]
31.7%
#180
やねうら王2016mid V299c
search、魔女化(), 1スレッド
#0
silent_majority_V1.1公式
1スレッド
73-19-157(100.0% R-133.0)
持ち時間が増えると勝率の差が広がっていく性質がある。
2.99b、40秒での勝率を調べておく。
秒読み40000[ms]
39.6%
#179
やねうら王2016mid V299b
search、魔女化(), 1スレッド
#0
silent_majority_V1.1公式
1スレッド
129-23-197(100.0% R-73.6)
40秒でそんなに弱くはない。静止探索での1手詰めを呼ばないように
すれば(利きの更新コストがないならば)、おそらく-R50ぐらい。
assertを外して、PGOなどをかければほぼ互角かも。
20秒での勝率も調べておく。
秒読み20000[ms]
39.8%
#179
やねうら王2016mid V299b
search、魔女化(), 1スレッド
#0
silent_majority_V1.1公式
1スレッド
47-5-71(99.0% R-71.7)
対戦数は少ないが、そんなに変わらないという印象。
■ 2016/06/13 V2.98
・探索部、見直す。
・FutilityMoveCounts、ONE*PLY掛けると配列が大きくなるので、やめたほうがいいのでは..
・静止探索のMovePicker、Stockfishの最新のようにhistory渡すのやめる。
・MovePicker、探索部ごとに変えられるようにextraに分離する。
extra/move_picker_2015.h
extra/move_picker_2016Q2.h
…
・捕獲から逃れる指し手のreduction軽減。
・counter moveのボーナス等、変更。
意外と大改造になった。
・Stockfish7の新しいhistoryとかcounter move、効率良さそう。
確かに長い時間で効果が出そうな感じ…。
・bench完走したので、とりあえず良し。
・とりあえず、魔女と1手10秒で対局させておく。
34.8%
#176
やねうら王2016mid V298
search、魔女化(), 1スレッド、10秒設定
#0
silent_majority_V1.1公式
1スレッド、10秒設定
188-29-352(100.0% R-109.0)
以前より弱くなった。まだ何かバグっているのだと思われる。
■ 2016/06/13 V2.97
・MovePicker、よく考える。
いま、Pieceの金の位置が角、飛車の後ろにあるからLVA_Table用意したほうがいいのか…。
以下のように変更。
// MVV-LVAに、歩の成りに加点する形にしておく。
m.value = (pawn_promo ? (Value)(Eval::GoldValue - Eval::PawnValue) : VALUE_ZERO)
+ (Value)Eval::PieceValueCapture[pos.piece_on(move_to(m))]
- LVA(pt);
・MovePickerにコメント少し追加。
■ 2016/06/13 V2.96
・search()を魔女とくらべてみる。
・check_timeを呼び出す周期、もう少し細かくする。
思ったよりnps出ないので、20000 nodeに1回だと0.1秒程度の誤差がでかねないようだ。
→ ここで0.1秒も誤差が出ると、NetworkDelayで0.1秒損をする。
ここをシビアにして、代わりにNetworkDelay,NetworkDelay2のデフォルト値を-80[ms]しておく。
・魔女のprobe()のあとのコード、おかしくないかな。
ttScore = (tte != nullptr ? scoreFromTT(tte->score(), ss->ply) : ScoreNone);
この置換表、entryがないときも tte != nullptr なのでは..
ttScore = (ttHit ? scoreFromTT(tte->score(), ss->ply) : ScoreNone);
これが正しい気がする。
・魔女の1手詰めのあと格納している値がおかしい気がする。
ss->staticEval = bestScore = mateIn(ss->ply);
次のnodeで指し手がなくなって詰むのだから、mateIn(ss->ply +1)のような。
ss->plyを0からカウントしているからこれで合ってるとか？
・魔女の1手詰めを見つけたときに置換表に格納するときのdepth、DEPTH_MAXのほうが
良いような。
・魔女のほう、Search::StackにcounterMovesがある。このへん、新しいStockfishなのか…そうか。
・魔女のほう、パラメーターはStockfishのものから未調整に近いので、これでいいのだとしたら、
singularなどもやはりStockfishの値に戻したほうがいいのかも知れない。
Stockfishのsingularは、やり過ぎだと思っていたのだが、そうでもないのだろう。
・魔女がAperyに長い時間でかなり勝ち越すのは、singular extensionを(本家Stockfishのパラメーターそのままにして将棋にしてみると)
激しくやっているせいで、特殊な状態のような気はする。しかしApery亜種が大量にいる状況では、それが奏功する。
かならずしもいいとは言えない調整だが、singular extension、わりと異種ソフトに対してもわりと妥当な延長である可能性はある。
・短い持ち時間でパラメーターを自動調整するとsingularのパラメーターは縮小される方向(singularを使わない方向)に一方的に向かうが、
これは良くない調整だと思う。singular絡みのパラメーター、持ち時間を大きくしないと調整は危険。
46.8%
#175
やねうら王2016mid V296
search、魔女化(), 1スレッド、5秒設定
#0
silent_majority_V1.1公式
1スレッド、5秒設定
96-5-109(83.6% R-22.1)
魔女にだいぶ並んできた。-R22はあまり正確な数値ではないだろうけども、これが仮に正確な数値だとしたら
利きの更新で損をしている15%(R30相当)が利いて来ている可能性がある。やねうら王のほうassertを入れてる分、
速度的に損をしているのかも知れないし。
同じ条件で10秒でもやってみる。
39.0%
#175
やねうら王2016mid V296
search、魔女化(), 1スレッド、10秒設定
#0
silent_majority_V1.1公式
1スレッド、10秒設定
105-18-164(100.0% R-77.5)
10秒だとずいぶん差が出るな…。なるほど…。確かに魔女は長い時間に対して強いな。
■ 2016/06/13 V2.95
・qsearch()を魔女化したものと魔女とを対局させてみる。
38.1%
#172
やねうら王2016mid V294
qsearch、魔女化(), 1スレッド、5秒設定
#0
silent_majority_V1.1公式
1スレッド、5秒設定
88-7-143(100.0% R-84.3)
ひどくなった気がする。
利きの更新が重いので、やねうら王の場合、1手詰めは呼び出したほうが得なのか。
利きの更新で15%ぐらい損してて、1手詰め判定は通常探索からしか
呼び出されないので、全体の3%ぐらいしか消費していないとすると
結局、12%ぐらい損してることになって、これがレーティングで言うとたぶん
R25ぐらい。逆に言うと、それ以上魔女と差があるならそれについては
原因をよく調べるべき。
ただ、全く同じ評価関数、かつ、ほぼ同じ探索部なのでわずかなnpsの差が
直接勝敗を分けることはありうると思う。この速度差が、思ったより大きな差
なのではないかなと。
・TTがおかしいのか？
if (!tte[i].key16)
return found = false, &tte[i];
→ これよく見るとこの瞬間にgeneration設定していないから
新しい探索部では、まずい。このバグひどいな…。
→ 修正。
if (!tte[i].key16 || tte[i].key16 == key16)
{
// 1.に対してはこのタイミングでrefresh
// 2.に対してはこのタイミングでgenerationを設定しておいてやる。
tte[i].set_generation(generation8);
return found = (bool)tte[i].key16, &tte[i];
}
→ あれ？よく考えたらsave()でgeneration書き出すので、key16 == 0のときは、ここでやらなくて良いのか。
→ じゃあ問題ないや。
・静止探索での1手詰めは、やはり入れるようにして、
上の修正だけ反映させて、それで以前のバージョンと対局させてみる。
50.4%
#173
やねうら王2016mid V295
qsearch、魔女化(), 1スレッド、0.1秒設定
#162
やねうら王2016mid V290
Apery(WCSC26) evaluate(), 1スレッド、0.1秒設定
290-12-285(40.1% R3.0)
変わっていないか。そうか…。
・結論的には、静止探索での1手詰めの呼び出しは強くなるのか怪しいけど、いまそこが問題ではなさそう。
長い持ち時間において弱くなる原因は通常探索部にありそう。
■ 2016/06/13 V2.94
・開発環境が整理できたので、
Silent Majority V1.1と1スレッド2秒/5秒/10秒対局において同じぐらいの勝率になるところまでチューニングする。
cf.
コンピュータ将棋ソフトウェアの時間制御
http://woodyring.blog.so-net.ne.jp/2016-06-05
woodyringさんの上の記事の内容を引き継いで、長い持ち時間におい
てSilent Majorityの棋力が伸びる原因について深く調べる。
まず2秒設定にてやねうら王V2.92と対局させる。
エンジン設定)
#0
やねうら王2016mid V290
Apery(WCSC26) evaluate(), 1スレッド、2秒設定
YaneuraOu-2016-midV290.exe
go btime 0 wtime 0 byoyomi 2000
setoption name Hash value 256
setoption name Threads value 1
setoption name NetworkDelay value 0
setoption name NetworkDelay2 value 0
#169
silent_majority_V1.1公式
1スレッド、2秒設定
SILENT_MAJORITY_AVX2_x64_V110.exe
go btime 0 wtime 0 byoyomi 2000
setoption name Hash value 256
setoption name USI_Hash value 256
setoption name Threads value 1
思考コマンド
> go btime 0 wtime 0 byoyomi 2000
49.7%
#169
silent_majority_V1.1公式
1スレッド、2秒設定
#0
やねうら王2016mid V290
Apery(WCSC26) evaluate(), 1スレッド、2秒設定
281-31-284(56.7% R-1.8)
→ ほぼ互角。
> go btime 0 wtime 0 byoyomi 5000
58.9%
#169
silent_majority_V1.1公式
1スレッド、5秒設定
#0
やねうら王2016mid V290
Apery(WCSC26) evaluate(), 1スレッド、5秒設定
312-19-218(0.0% R62.3)
→ だいぶ負け越した
2秒→5秒にして負け越すようになるということは、
singular extension絡みなどでないなら、これは
短い持ち時間においては終盤絡みで逆転して勝っているだけだと考えられる。
1手詰めが怪しいが、魔女のほうもmateMoveIn1Ply()は呼び出している模様。
やねうら王のほうは、利きの更新で損しているのかも知れない。
・短い持ち時間での対局のときに、リソース削減のためにHashを極力小さく設定しているが
これにより、CPU cacheが少しでも汚染されるようなチューニング(例:nodeのquietの指し手バッファ=64を大きな値に変更するなど)
に対して極めてパフォーマンスが低下する傾向があり、間違ったチューニングとなる可能性がある。
・魔女とqsearch()を比較してみる。
・やねうら王側、宣言勝ちの判定をqsearch()でやっているのがどうなのか。
→ まあいいか。
・やねうら王側、null moveのときの見積りにTempoを加算するように変更。
- : -(ss-1)->staticEval;
+ : -(ss-1)->staticEval + 2 * Tempo;
・やねうら王側、qsearch()では1手詰め呼び出さないように変更。
・やねうら王側、evasionPrunableのフラグ、歩の成りは対象外とする。
bool evasionPrunable = InCheck
&& bestValue > VALUE_MATED_IN_MAX_PLY
- && !pos.capture(move);
+ && !pos.capture_or_pawn_promotion(move);
・魔女側、qsearch()で用いているMovePicker、Stockfishの少し古いバージョンのようだ。
これは関係あるのか？ないのか？
0.1秒で前バージョンと対局。
45.3%
#170
やねうら王2016mid V294
qsearch、魔女化(), 1スレッド、0.1秒設定
#0
やねうら王2016mid V290
Apery(WCSC26) evaluate(), 1スレッド、0.1設定
228-12-275(98.4% R-32.6)
50.0%
#171
やねうら王2016mid V294
qsearch、魔女化(), 1スレッド、5秒設定
#0
やねうら王2016mid V290
Apery(WCSC26) evaluate(), 1スレッド、5設定
104-13-104(52.8% R0.0)
→ 長い持ち時間においては静止探索での1手詰め判定の効果が
相対的に薄れるということなのだと思う。
静止探索中に1手詰めを見つけたところでそれによって
(通常探索時に見つけた1手詰めとは異なり)探索すべきnode数が減るという
効果に乏しく、singular extensionのような効果しかないから。
1手詰め判定を通常探索でしか呼び出さないなら、現状のように
利きを評価関数で使わないのに利きの更新を行うと、そのコスト面において
魔女とくらべてかなり損をしてしまう。利きを用いない1手詰め判定関数を
作成して、かつ、利きの更新を用いないのが得策か。
■ 2016/06/10 V2.93
・魔女が宣言勝ちした局面、やねうら王の自己対戦フレームワークで認められなかった。おかしい。
4<Error : illigal move , move = win , engine name = engines\SILENT_MAJORITY_AVX2_x64_V110.exe
4< □ □ □ □ □ □ □ 飛 □
4< 玉 と □ 馬 □ □ 圭 □ □
4< 圭 と と と □ 歩 と □ □
4< □ □ □ □ □ □ □ 全 □
4< □ □^龍 □ □^と □ 金 □
4< □ □ □^圭^圭^馬 □ □ □
4< □ □ □ □ □ □ □^と^杏
4< □ □ □ □ □ □ □^全^玉
4< □ □ □ □ □ □ □ □ □
4<先手 手駒 :
歩2 香3 銀2 金3 , 後手 手駒 : 歩8
4<手番 = 先手
4<sfen 7R1/K+P1+B2+N2/+N+P+P+P1P+P2/7+S1/2+r2+p1G1/3+n+n+b3/7+p+l/7+sk/9 b 2P3L2S3G8p 243
→ 入玉判定のときに手駒の金を足してなかった。修正した。
- + (hand_count(h,BISHOP) + hand_count(h,ROOK)) * 5;
+ + hand_count(h,GOLD) + (hand_count(h,BISHOP) + hand_count(h,ROOK)) * 5;
■ 2016/06/10 V2.92
・null moveのときの評価値、きちんと計算する。
・evaluate_nullmove(pos)追加。
(ss - 1)->currentMove != MOVE_NULL ? evaluate(pos)
- : -(ss - 1)->staticEval;
+ : -(ss - 1)->staticEval + 70;
V2.92
49.1%
#166
やねうら王2016mid V292
null move後のevaluate()修正, 1スレッド、0.1秒設定
#0
やねうら王2016mid V290
Apery(WCSC26) evaluate(), 1スレッド、0.1秒設定
540-15-560(72.7% R-6.3)
+ : evaluate_nullmove(pos);
V2.92a
48.5%
#167
やねうら王2016mid V292a
null move後のevaluate()修正, 1スレッド、0.1秒設定
#0
やねうら王2016mid V290
Apery(WCSC26) evaluate(), 1スレッド、0.1秒設定
610-24-648(85.8% R-10.5)
■ 2016/06/04～2016/06/05 V2.91
・やねうら王2016 Midの探索パラメーターの自動調整。
・解説.txtに他ソフトとの対局時の設定などを追記。
・パラメーター調整後。
47.6%
#162
やねうら王2016mid V290
Apery(WCSC26) evaluate(), 1スレッド、0.1秒設定
#0
やねうら王2016mid V290 master
Apery(WCSC26) evaluate(), 1スレッド、0.1秒設定
1122-46-1236(99.1% R-16.8)
→ 弱くなるのか…そうか…。
■ 2016/06/01～2016/06/02 V2.90
・Apery(WCSC26)の評価関数の読み込み作業。
SILENT MAJORITYの作者の実装を参考にさせていただきました。
https://github.com/Jangja/YaneuraOu/
・EVAL_KPPT (手番つきKPP)実装
evaluate_kppt.cpp
extra/eval_sum.h
eval_stat()実装完了。
64.6%
#162
やねうら王2016mid V290
Apery(WCSC26) evaluate(), 1スレッド、0.1秒設定
#0
やねうら王2016mid V278master
2016mid first version, 1スレッド、0.1秒設定
858-11-471(0.0% R104.2)
===========================
Total time (ms) : 66637
Nodes searched : 42085583
Nodes/second : 631564
・評価関数の載せ替えにより、
+R105ぐらい。R3400弱？
nps 730k→630k , 14%ぐらいダウン。
探索パラメーター未調整。
利きの更新をやっているのがマイナスになっているかも。(3手詰めなどを実装して利きの更新コストを回収すべきか)
魔女より少し弱いのかも。(未検証)
このあと
1) この評価関数のために探索パラメーターを調整する。
2) 魔女と対戦させてみる。
・以前のparameters.h
PARAM_FUTILITY_MARGIN_ALPHA : 87 → 87(50.00%) : ←←(値81,勝率49.25%,1440局,有意68.84%) ,←(値84,勝率49.15%,1440局,有意71.06%) ,→(値90,勝率49.52%,1440局,有意62.78%) ,→→(値93,勝率49.52%,1440局,有意62.82%) ,
PARAM_QUIET_SEARCH_COUNT : 64 → 72(55.05%) : ←←(値56,勝率51.07%,1440局,有意24.62%) ,←(値60,勝率50.27%,1440局,有意42.23%) ,→(値68,勝率50.43%,1440局,有意38.46%) ,→→(値72,勝率55.05%,480局,有意1.30%) ,
PARAM_RAZORING_ALPHA : 16 → 16(50.00%) : ←←(値12,勝率50.27%,1440局,有意42.22%) ,←(値14,勝率49.72%,2880局,有意58.44%) ,→(値18,勝率50.69%,1440局,有意32.37%) ,→→(値20,勝率48.82%,1440局,有意77.39%) ,
PARAM_RAZORING_MARGIN : 448 → 448(50.00%) : ←←(値384,勝率49.73%,1440局,有意57.74%) ,←(値416,勝率49.30%,1440局,有意67.68%) ,→(値480,勝率49.57%,1440局,有意61.59%) ,→→(値512,勝率50.16%,1440局,有意44.80%) ,
PARAM_PRUNING_BY_HISTORY_DEPTH : 4 → 4(50.00%) : ←←(値8,勝率0.00%,0局,有意50.00%) ,←(値8,勝率45.11%,1440局,有意99.88%) ,→(値8,勝率48.94%,1440局,有意75.28%) ,→→(値8,勝率43.19%,480局,有意99.87%) ,
PARAM_REDUCTION_BY_HISTORY : 14724 → 14724(50.00%) : ←←(値14212,勝率46.27%,480局,有意95.18%) ,←(値14468,勝率51.28%,1440局,有意20.74%) ,→(値14980,勝率47.74%,1440局,有意92.08%) ,→→(値15236,勝率50.32%,2880局,有意40.51%) ,
PARAM_SINGULAR_SEARCH_DEPTH : 128 → 64(53.94%) : ←←(値64,勝率53.94%,624局,有意3.96%) ,←(値96,勝率46.20%,480局,有意95.54%) ,→(値160,勝率50.85%,1440局,有意28.96%) ,→→(値192,勝率49.26%,1440局,有意68.75%) ,
PARAM_SINGULAR_MARGIN : 7 → 6(52.27%) : ←←(値5,勝率49.10%,1872局,有意73.59%) ,←(値6,勝率52.27%,1872局,有意5.71%) ,→(値8,勝率49.80%,1872局,有意55.68%) ,→→(値9,勝率51.97%,1872局,有意8.45%) ,
PARAM_SINGULAR_EXTENSION_DEPTH : 10 → 8(53.44%) : ←←(値8,勝率53.44%,624局,有意4.08%) ,←(値9,勝率49.96%,1872局,有意51.14%) ,→(値11,勝率49.06%,1872局,有意74.51%) ,→→(値12,勝率49.63%,1872局,有意60.13%) ,
PARAM_PROBCUT_DEPTH : 5 → 5(50.00%) : ←←(値3,勝率39.35%,624局,有意100.00%) ,←(値4,勝率49.96%,1872局,有意51.14%) ,→(値6,勝率46.54%,1872局,有意99.20%) ,→→(値7,勝率45.23%,624局,有意99.21%) ,
PARAM_NULL_MOVE_DYNAMIC_BETA : 58 → 64(53.36%) : ←←(値52,勝率51.11%,1872局,有意21.99%) ,←(値55,勝率50.41%,1872局,有意38.74%) ,→(値61,勝率52.29%,1872局,有意5.47%) ,→→(値64,勝率53.36%,624局,有意4.46%) ,
PARAM_NULL_MOVE_RETURN_DEPTH : 12 → 11(51.58%) : ←←(値10,勝率49.84%,1872局,有意54.55%) ,←(値10,勝率51.58%,3744局,有意8.77%) ,→(値10,勝率51.11%,1872局,有意21.99%) ,→→(値10,勝率0.00%,0局,有意50.00%) ,
PARAM_NULL_MOVE_DYNAMIC_ALPHA : 871 → 871(50.00%) : ←←(値839,勝率49.22%,1872局,有意70.68%) ,←(値855,勝率49.10%,1872局,有意73.53%) ,→(値887,勝率49.96%,1872局,有意51.14%) ,→→(値903,勝率46.32%,624局,有意96.87%) ,
PARAM_FUTILITY_AT_PARENT_NODE_SEE_DEPTH : 2 → 2(50.00%) : ←←(値2,勝率0.00%,0局,有意50.00%) ,←(値2,勝率0.00%,0局,有意50.00%) ,→(値3,勝率50.00%,1872局,有意50.00%) ,→→(値4,勝率50.55%,3744局,有意31.99%) ,
PARAM_FUTILITY_AT_PARENT_NODE_MARGIN : 173 → 170(52.73%) : ←←(値167,勝率49.10%,3744局,有意77.95%) ,←(値170,勝率52.73%,3744局,有意0.97%) ,→(値176,勝率47.78%,1872局,有意93.91%) ,→→(値179,勝率50.16%,1872局,有意45.46%) ,
PARAM_FUTILITY_AT_PARENT_NODE_DEPTH : 7 → 8(52.15%) : ←←(値5,勝率45.79%,624局,有意98.35%) ,←(値6,勝率50.74%,1872局,有意30.27%) ,→(値8,勝率52.15%,1872局,有意6.76%) ,→→(値9,勝率50.16%,1872局,有意45.43%) ,
PARAM_FUTILITY_MARGIN_QUIET : 129 → 129(50.00%) : ←←(値123,勝率46.64%,624局,有意95.54%) ,←(値126,勝率49.10%,1872局,有意73.59%) ,→(値132,勝率50.25%,1872局,有意43.15%) ,→→(値135,勝率49.80%,1872局,有意55.68%) ,
PARAM_FUTILITY_RETURN_DEPTH : 5 → 5(50.00%) : ←←(値5,勝率0.00%,0局,有意50.00%) ,←(値5,勝率0.00%,0局,有意50.00%) ,→(値6,勝率50.20%,1872局,有意44.32%) ,→→(値7,勝率49.55%,1872局,有意62.39%) ,
PARAM_FUTILITY_MARGIN_ALPHA : 93 → 87(53.42%) : ←←(値87,勝率53.42%,1872局,有意0.86%) ,←(値90,勝率50.00%,1872局,有意50.00%) ,→(値96,勝率50.08%,1872局,有意47.72%) ,→→(値99,勝率47.19%,1872局,有意97.56%) ,
PARAM_RAZORING_ALPHA : 14 → 16(51.97%) : ←←(値10,勝率49.35%,1872局,有意67.61%) ,←(値12,勝率51.89%,1872局,有意9.37%) ,→(値16,勝率51.97%,1872局,有意8.45%) ,→→(値18,勝率46.18%,624局,有意97.36%) ,
PARAM_RAZORING_MARGIN : 448 → 448(50.00%) : ←←(値384,勝率50.77%,3744局,有意25.62%) ,←(値416,勝率51.01%,3744局,有意19.37%) ,→(値480,勝率46.57%,624局,有意95.90%) ,→→(値512,勝率49.02%,1872局,有意75.38%) ,
PARAM_REDUCTION_BY_HISTORY : 14724 → 14724(50.00%) : ←←(値14212,勝率51.11%,1872局,有意21.99%) ,←(値14468,勝率50.82%,1872局,有意28.36%) ,→(値14980,勝率47.55%,3744局,有意98.22%) ,→→(値15236,勝率51.19%,1872局,有意20.29%) ,
PARAM_SINGULAR_MARGIN : 7 → 7(50.00%) : ←←(値5,勝率49.51%,1872局,有意63.43%) ,←(値6,勝率50.94%,1872局,有意25.57%) ,→(値8,勝率48.72%,3744局,有意86.37%) ,→→(値9,勝率50.94%,1872局,有意25.52%) ,
PARAM_NULL_MOVE_DYNAMIC_BETA : 58 → 58(50.00%) : ←←(値52,勝率50.41%,1872局,有意38.71%) ,←(値55,勝率47.02%,1872局,有意98.16%) ,→(値61,勝率50.49%,1872局,有意36.59%) ,→→(値64,勝率50.69%,1872局,有意31.36%) ,
PARAM_NULL_MOVE_DYNAMIC_ALPHA : 855 → 871(51.92%) : ←←(値823,勝率50.49%,1872局,有意36.58%) ,←(値839,勝率47.42%,1872局,有意96.42%) ,→(値871,勝率51.92%,1872局,有意8.98%) ,→→(値887,勝率51.15%,1872局,有意21.12%) ,
PARAM_FUTILITY_AT_PARENT_NODE_MARGIN : 170 → 173(53.72%) : ←←(値164,勝率49.92%,1872局,有意52.28%) ,←(値167,勝率46.72%,624局,有意95.16%) ,→(値173,勝率53.72%,624局,有意3.07%) ,→→(値176,勝率51.99%,1872局,有意8.11%) ,
PARAM_FUTILITY_MARGIN_QUIET : 123 → 129(52.55%) : ←←(値117,勝率50.78%,1872局,有意29.32%) ,←(値120,勝率50.08%,1872局,有意47.72%) ,→(値126,勝率52.19%,1872局,有意6.39%) ,→→(値129,勝率52.55%,3744局,有意1.42%) ,
PARAM_FUTILITY_MARGIN_ALPHA : 93 → 93(50.00%) : ←←(値87,勝率49.92%,1872局,有意52.29%) ,←(値90,勝率46.42%,624局,有意96.54%) ,→(値96,勝率50.29%,1872局,有意42.07%) ,→→(値99,勝率48.82%,1872局,有意79.61%) ,
PARAM_RAZORING_ALPHA : 16 → 14(55.15%) : ←←(値12,勝率48.04%,1872局,有意91.51%) ,←(値14,勝率55.15%,624局,有意0.51%) ,→(値18,勝率51.88%,3744局,有意5.36%) ,→→(値20,勝率51.72%,3744局,有意7.05%) ,
PARAM_RAZORING_MARGIN : 448 → 448(50.00%) : ←←(値384,勝率49.75%,1872局,有意56.82%) ,←(値416,勝率50.37%,1872局,有意39.80%) ,→(値480,勝率50.03%,3744局,有意49.07%) ,→→(値512,勝率50.16%,1872局,有意45.44%) ,
PARAM_REDUCTION_BY_HISTORY : 14724 → 14724(50.00%) : ←←(値14212,勝率48.19%,3744局,有意93.88%) ,←(値14468,勝率50.37%,1872局,有意39.84%) ,→(値14980,勝率49.14%,1872局,有意72.64%) ,→→(値15236,勝率48.04%,1872局,有意91.48%) ,
PARAM_SINGULAR_MARGIN : 8 → 7(51.69%) : ←←(値6,勝率48.94%,1872局,有意77.09%) ,←(値7,勝率51.69%,3744局,有意7.41%) ,→(値9,勝率50.16%,1872局,有意45.45%) ,→→(値10,勝率49.71%,1872局,有意57.95%) ,
PARAM_NULL_MOVE_DYNAMIC_BETA : 61 → 58(53.98%) : ←←(値55,勝率48.01%,1872局,有意91.89%) ,←(値58,勝率53.98%,624局,有意2.18%) ,→(値64,勝率52.49%,1872局,有意4.06%) ,→→(値67,勝率51.18%,1872局,有意20.41%) ,
PARAM_NULL_MOVE_DYNAMIC_ALPHA : 823 → 855(53.43%) : ←←(値791,勝率48.47%,3744局,有意90.50%) ,←(値807,勝率52.52%,1872局,有意3.97%) ,→(値839,勝率48.08%,1872局,有意91.03%) ,→→(値855,勝率53.43%,1872局,有意0.82%) ,
PARAM_FUTILITY_AT_PARENT_NODE_MARGIN : 170 → 170(50.00%) : ←←(値164,勝率49.51%,1872局,有意63.40%) ,←(値167,勝率46.15%,624局,有意97.40%) ,→(値173,勝率50.65%,1872局,有意32.40%) ,→→(値176,勝率49.51%,1872局,有意63.45%) ,
PARAM_FUTILITY_MARGIN_QUIET : 123 → 123(50.00%) : ←←(値117,勝率50.63%,3744局,有意29.57%) ,←(値120,勝率48.75%,3744局,有意85.85%) ,→(値126,勝率50.25%,1872局,有意43.18%) ,→→(値129,勝率50.86%,1872局,有意27.41%) ,
PARAM_FUTILITY_MARGIN_ALPHA : 90 → 93(55.95%) : ←←(値84,勝率47.93%,1872局,有意92.70%) ,←(値87,勝率50.53%,1872局,有意35.55%) ,→(値93,勝率55.95%,624局,有意0.14%) ,→→(値96,勝率47.30%,1872局,有意97.06%) ,
PARAM_PRUNING_BY_MOVE_COUNT_DEPTH : 16 → 16(50.00%) : ←←(値14,勝率47.70%,1872局,有意94.57%) ,←(値15,勝率48.98%,1872局,有意76.27%) ,→(値17,勝率49.09%,3744局,有意78.02%) ,→→(値18,勝率51.03%,1872局,有意23.68%) ,
PARAM_QUIET_SEARCH_COUNT : 64 → 64(50.00%) : ←←(値56,勝率47.11%,1872局,有意97.79%) ,←(値60,勝率50.04%,1872局,有意48.86%) ,→(値68,勝率47.76%,1872局,有意94.20%) ,→→(値72,勝率50.12%,1872局,有意46.58%) ,
PARAM_PRUNING_BY_HISTORY_DEPTH : 4 → 4(50.00%) : ←←(値8,勝率0.00%,0局,有意50.00%) ,←(値8,勝率46.47%,624局,有意96.27%) ,→(値8,勝率50.24%,1872局,有意43.21%) ,→→(値8,勝率47.48%,1872局,有意96.15%) ,
PARAM_SINGULAR_SEARCH_DEPTH : 128 → 128(50.00%) : ←←(値64,勝率51.03%,1872局,有意23.68%) ,←(値96,勝率49.06%,1872局,有意74.48%) ,→(値160,勝率50.29%,1872局,有意42.07%) ,→→(値192,勝率51.06%,1872局,有意22.85%) ,
PARAM_SINGULAR_EXTENSION_DEPTH : 10 → 11(52.83%) : ←←(値8,勝率49.67%,1872局,有意59.04%) ,←(値9,勝率50.16%,1872局,有意45.43%) ,→(値11,勝率52.83%,1872局,有意2.33%) ,→→(値12,勝率50.12%,1872局,有意46.58%) ,
PARAM_PROBCUT_DEPTH : 5 → 5(50.00%) : ←←(値3,勝率39.42%,624局,有意100.00%) ,←(値4,勝率49.13%,1872局,有意72.67%) ,→(値6,勝率47.16%,3744局,有意99.25%) ,→→(値7,勝率46.13%,624局,有意97.44%) ,
PARAM_NULL_MOVE_RETURN_DEPTH : 12 → 12(50.00%) : ←←(値10,勝率50.29%,1872局,有意42.05%) ,←(値10,勝率49.84%,1872局,有意54.55%) ,→(値10,勝率50.41%,3744局,有意36.28%) ,→→(値10,勝率0.00%,0局,有意50.00%) ,
PARAM_FUTILITY_AT_PARENT_NODE_SEE_DEPTH : 4 → 2(57.03%) : ←←(値2,勝率57.03%,624局,有意0.02%) ,←(値3,勝率49.63%,1872局,有意60.16%) ,→(値5,勝率47.83%,3744局,有意96.88%) ,→→(値6,勝率46.15%,624局,有意97.40%) ,
PARAM_FUTILITY_AT_PARENT_NODE_DEPTH : 7 → 7(50.00%) : ←←(値5,勝率50.11%,3744局,有意46.28%) ,←(値6,勝率51.09%,3744局,有意17.54%) ,→(値8,勝率49.18%,3744局,有意75.82%) ,→→(値9,勝率48.90%,1872局,有意77.98%) ,
PARAM_FUTILITY_RETURN_DEPTH : 7 → 5(53.43%) : ←←(値5,勝率53.43%,624局,有意4.10%) ,←(値6,勝率50.04%,1872局,有意48.86%) ,→(値8,勝率51.15%,1872局,有意21.14%) ,→→(値9,勝率49.18%,1872局,有意71.67%) ,
PARAM_RAZORING_ALPHA : 16 → 16(50.00%) : ←←(値12,勝率50.98%,1872局,有意24.65%) ,←(値14,勝率48.93%,1872局,有意77.17%) ,→(値18,勝率50.85%,1872局,有意27.46%) ,→→(値20,勝率47.56%,1872局,有意95.66%) ,
PARAM_RAZORING_MARGIN : 512 → 448(53.51%) : ←←(値448,勝率53.51%,624局,有意3.77%) ,←(値480,勝率52.83%,1872局,有意2.41%) ,→(値544,勝率50.69%,1872局,有意31.37%) ,→→(値576,勝率49.84%,1872局,有意54.55%) ,
PARAM_REDUCTION_BY_HISTORY : 14724 → 14724(50.00%) : ←←(値14212,勝率49.26%,1872局,有意69.70%) ,←(値14468,勝率50.57%,1872局,有意34.44%) ,→(値14980,勝率50.04%,1872局,有意48.86%) ,→→(値15236,勝率50.45%,1872局,有意37.67%) ,
PARAM_SINGULAR_MARGIN : 8 → 8(50.00%) : ←←(値6,勝率50.08%,1872局,有意47.72%) ,←(値7,勝率48.08%,1872局,有意91.03%) ,→(値9,勝率51.44%,3744局,有意10.85%) ,→→(値10,勝率51.00%,3744局,有意19.43%) ,
PARAM_NULL_MOVE_DYNAMIC_BETA : 67 → 61(52.12%) : ←←(値61,勝率52.12%,3744局,有意3.45%) ,←(値64,勝率46.25%,624局,有意97.11%) ,→(値70,勝率52.04%,3744局,有意4.00%) ,→→(値73,勝率50.82%,1872局,有意28.39%) ,
PARAM_NULL_MOVE_DYNAMIC_ALPHA : 823 → 823(50.00%) : ←←(値791,勝率50.90%,1872局,有意26.42%) ,←(値807,勝率47.87%,1872局,有意93.17%) ,→(値839,勝率50.00%,1872局,有意50.00%) ,→→(値855,勝率49.92%,1872局,有意52.28%) ,
PARAM_FUTILITY_AT_PARENT_NODE_MARGIN : 170 → 170(50.00%) : ←←(値164,勝率49.47%,1872局,有意64.53%) ,←(値167,勝率50.04%,1872局,有意48.86%) ,→(値173,勝率49.23%,1872局,有意70.62%) ,→→(値176,勝率49.35%,1872局,有意67.61%) ,
PARAM_FUTILITY_MARGIN_QUIET : 123 → 123(50.00%) : ←←(値117,勝率49.47%,1872局,有意64.50%) ,←(値120,勝率49.02%,1872局,有意75.36%) ,→(値126,勝率49.88%,1872局,有意53.41%) ,→→(値129,勝率47.39%,1872局,有意96.63%) ,
PARAM_FUTILITY_MARGIN_ALPHA : 90 → 90(50.00%) : ←←(値84,勝率50.00%,1872局,有意50.00%) ,←(値87,勝率49.22%,1872局,有意70.70%) ,→(値93,勝率46.33%,624局,有意96.85%) ,→→(値96,勝率46.73%,624局,有意95.13%) ,
■ 2016/05/20 V2.89
・evalList、シーケンシャルにしておかないと、ベクトル系の命令が使いにくいのか…。修正。
■ 2016/05/17
・MaxMovesToDrawが256を指定したときに256手目が指されない？
setoption name MaxMovesToDraw value 4
position startpos moves 7g7f 3c3d 2g2f
go btime 1000 wtime 1000 byoyomi 0
指せている気が？
floodgateでの設定に問題があるのだと思うので、解説.txtに追記。
■ 2016/05/11 V2.88
・tanuki-さんのlocal-game-serverのプロセスの終了まわりのコードをmerge。
■ 2016/05/06 V2.87
・定跡ファイルの読み込みは
void Search::clear()
のほうでやらないと、HDDが遅いPCだとタイムアウトになりかねない。修正。
■ 2016/05/03 V2.86
・ehashで速くなるかも。
cf.
http://yaneuraou.yaneu.com/2016/04/16/%E3%82%84%E3%81%AD%E3%81%86%E3%82%89%E7%8E%8Bclassic-tce%E7%89%88%E3%80%81%E6%AD%A3%E5%BC%8F%E5%85%AC%E9%96%8B%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/#comment-6053
→ 読み太の作者さんの実験ではならなかったみたいなのでehashは諦める。
・local-game-serverで棋譜出力機能追加。
→ book自体が実戦棋譜なので棋譜の進行がそこそこ偏っている意味がある。
計測するのに、8手目ぐらいまでrandom playerのほうが良かったりして…。
ともかく、計測自体は正常に行えていることが確認できた。
・やねうら王2016-mid、paramters.hを最新のものにして、他の実験をやる。
V2.86a
・null moveのときだけはkillerは必ず更新したほうがいい。
null moveしたノードでのkiller手は理想的なkiller手なので、価値が高い。(読み太の作者さん)
+ if ((ss - 1)->currentMove == MOVE_NULL)
+ {
+ // ただし、null move時のkillerは理想的なkillerなので有効だと考えられる。
+
+ // 普通にkillerのupdateを行なう。
+ if (ss->killers[0] != move32)
+ {
+ ss->killers[1] = ss->killers[0];
+ ss->killers[0] = move32;
+ }
+
+ } else {
弱くなった…。
49.3%
#160
やねうら王2016mid V286a
2016mid first version, 1スレッド、0.1秒設定
#159
やねうら王2016mid V286
2016mid first version, 1スレッド、0.1秒設定
2248-105-2316(84.3% R-5.2)
・ByteBoardで指し手生成を行なう → たこっとの作者さんに話を聞いてから。
→ SEEが正確に出来ないので損得微妙だと思い、これは先送り。
■ 2016/04/27 V2.85
・基準バージョンに対する勝率を見ながらパラメーターを動かすべき(かも)
・local-game-serverで用いるbookから32手目で同一の局面の除外
・そうすればrtimeは1手0.1秒固定で問題ない(かも)
→ クラスター化しているのでそれでも同じ乱数を引いて、同じ定跡になることはあるから
1手0.1秒固定はまずいのか…。
■ 2016/04/24 V2.84
・local-game-server、bookファイルがないときに読み込みエラー表示追加。
■ 2016/04/22 V2.83
・結論的にはパラメーターの自動調整は意図通り動いていたようだ。
凸性がないときに勝率がいいからと言って値を大きく動かすの危険。
・gen0 初期パラメーターに戻す
tce-finalに対して -R17.8程度。(あちらはASSERTなしなので)
2859-91-2580(0.0% R17.8)
・自己対戦フレームワークのfront-end、robocopyを使うように変更。
世代が進むにつれて弱くなっていたの、たぶん、共有フォルダだと
sambaプロトコルになってて、cacheが生きていて、変更したパラメーターファイルの
読み込みのときに古いファイルが読み込まれたりしていたせいもあるのではないかと…。
これで1手0.1秒で24時間ほど回す。
■ 2016/04/21 V2.82
・local-game-serverのspin loopのsleepの位置がおかしい気がするので修正。
・結果が思わしくないので、rtime = 300msで自動調整しなおす。
[HISTORY]
PARAM_REDUCTION_BY_HISTORY : 14724 → 14980(53.44%) : ←←(値14212,勝率50.41%,3744局,有意36.28%) ,←(値14468,勝率47.17%,1872局,有意97.60%) ,→(値14980,勝率53.44%,624局,有意4.08%) ,→→(値15236,勝率49.96%,1872局,有意51.14%) ,
PARAM_SINGULAR_MARGIN : 6 → 6(50.00%) : ←←(値2,勝率49.26%,3744局,有意73.58%) ,←(値4,勝率51.19%,1872局,有意20.31%) ,→(値8,勝率49.51%,1872局,有意63.43%) ,→→(値10,勝率51.03%,1872局,有意23.70%) ,
PARAM_NULL_MOVE_DYNAMIC_BETA : 67 → 67(50.00%) : ←←(値59,勝率50.71%,3744局,有意27.14%) ,←(値63,勝率45.71%,624局,有意98.44%) ,→(値71,勝率48.06%,1872局,有意91.14%) ,→→(値75,勝率48.11%,1872局,有意90.61%) ,
PARAM_NULL_MOVE_DYNAMIC_ALPHA : 823 → 823(50.00%) : ←←(値791,勝率50.08%,1872局,有意47.72%) ,←(値807,勝率45.48%,624局,有意98.84%) ,→(値839,勝率50.95%,1872局,有意25.47%) ,→→(値855,勝率50.54%,1872局,有意35.40%) ,
PARAM_FUTILITY_AT_PARENT_NODE_MARGIN : 160 → 150(54.05%) : ←←(値140,勝率49.51%,1872局,有意63.45%) ,←(値150,勝率54.05%,624局,有意2.10%) ,→(値170,勝率50.25%,1872局,有意43.19%) ,→→(値180,勝率50.29%,1872局,有意42.07%) ,
PARAM_FUTILITY_MARGIN_QUIET : 123 → 133(53.03%) : ←←(値113,勝率50.66%,1872局,有意32.34%) ,←(値118,勝率50.55%,3744局,有意31.98%) ,→(値128,勝率49.59%,3744局,有意63.72%) ,→→(値133,勝率53.03%,1872局,有意1.71%) ,
PARAM_FUTILITY_MARGIN_ALPHA : 95 → 95(50.00%) : ←←(値85,勝率49.35%,1872局,有意67.61%) ,←(値90,勝率50.00%,1872局,有意50.00%) ,→(値100,勝率50.65%,1872局,有意32.36%) ,→→(値105,勝率48.05%,1872局,有意91.44%) ,
→ これで値を動かしたところR70ぐらい下がってる。わけわからん…。
初期パラメーターが悪いようだ。NULL MOVEの枝刈りのdepthを極端に下げたのが
主な原因のようだ。一度、完全に元のパラメーターに戻す。
■ 2016/04/16 V2.81
・評価関数、定跡ファイルなどのファイルが読み込めないときのエラーメッセージに"Error"の文字列を埋め込み、
local-game-serverではこの文字列を拾うようにする。
・自己対戦の勝率なんかおかしいときがあると思ったら
(1024MB(1GB) + 評価関数 + 変換用バッファ)×6並列対局×2プロセスが
どうも24GBに収まらないことがあった模様。
→ あと、6並列なのにCPU 30%ぐらいしか消費してないのおかしくないか？
→ まあいいや。6コアでは8並列、4コアでは6並列をデフォとしよう。
・ネットワークごしに共有フォルダの同じファイルに同時にアクセスしたら、アクセス出来ないことが
あった模様。なにこれ…。
・値をいい加減に動かし過ぎ。試行回数500回以上において信頼区間95%で有意になるまでは、
値を動かさないように変更。(試行回数上限3000回)
・V2.81 gen0
parameters.h初期化。再度調整。
・V2.81 gen1
試行回数3000回において信頼区間90%で有意でないときは値を変えないようにした。
それ以上細かいものは手で調整することにした。
計測おかしい。
PARAM_RAZORING_MARGIN : 512 → 576(57.24%) : ←←(448,53.05%,0tries,有意9.17%) ,←(480,46.80%,0tries,有意91.71%) ,→(544,49.43%,1344tries,有意64.48%) ,→→(576,57.24%,0tries,有意0.10%) ,
PARAM_RAZORING_MARGIN : 512 → 448(52.08%) : ←←(値448,勝率52.08%,576局,有意8.09%) ,←(値480,勝率47.18%,0局,有意91.69%) ,→(値544,勝率50.13%,1728局,有意46.44%) ,→→(値576,勝率49.87%,1728局,有意53.55%) ,
・試行回数の1/2以上で80%信頼区間で有意でないならng。
・試行回数の1/3以上で90%信頼区間で有意ならok
・試行回数の1/5以上で95%信頼区間で有意ならok
・最大試行回数3000回。
こういう条件でどうなの。
・信頼区間90%で有意でないなら、パラメーターに関して
-step*2,-step,+step,+step*2
だけ動かした4点をサンプリングして関数(勝率)に凸性があるかどうかを確かめてから手で動かすようにしたほうが良さげ。
・V2.81 gen2
tce final ASSERTなしに-R10ぐらい。(900局)
前バージョンだと-R30ぐらいだったので強くなってきている？
■ 2016/04/16 V2.80
・PARAM_FUTILITY_MARGIN_DEPTHはPARAM_FUTILITY_MARGIN_ALPHAのほうが名前変更。
パラメーター自動調整中。
・思考時間 1手、80ms-120ms、平均100msにして倍ぐらいの速度で対戦させたほうがいいような気がしてきた。
→ とりあえずrtime 50でいいや。
持ち時間長くで調べたほうがいいパラメーターは長い時間を対局させる機能が必要だな。
前のバージョンと対戦させると-R10ぐらい低い。なんなんこれ。
→ 対局回数780回に増やして、rtimeを1～1.5倍のランダム時間に仕様変更して
1手100～150msで再度調整。
→ 強くならん…。パラメーター読み込めてない疑惑。
■ 2016/04/15 V2.79
・local-serverから起動したときにparamteres.hが読み込めてない問題。
local-serverがpath設定しないのがいけないのか…。うーん、そうか…。
・parameters_masterとslaveに分離。
・engine側、これでうまく動いてるっぽい。自動制御側を書く。
→ 書けた。しばらく自動で回す。
→ このあと自動で強くなってると嬉しい。
・PARAM_FUTILITY_MARGIN_DEPTHはPARAM_FUTILITY_MARGIN_ALPHAのほうが名前が良かった気がするが
いまさら変更できないな…まあいいや。何かの機会に変更すれば。
■ 2016/04/15 V2.78
・parameters.hから実行時の読み込みルーチンを書く。
→ 読み込み部書けた。
・razoring marginもparameters.hに追加する。
・local-serverから起動したときにparamteres.hが読み込めてない。根が深そう。あとで調べる。
■ 2016/04/14 V2.77
・2016-mid-engine追加。
・一括パラメーター調整の仕組み、何か考える。
・parameters.h追加。
//
// Internal iterative deepening
//
// IIDの条件
//if (depth >= (PvNode ? PARAM_IID_DEPTH_PV * ONE_PLY : PARAM_IID_DEPTH_NONPV * ONE_PLY)
// && !ttMove
// && (PvNode || ss->staticEval + PARAM_IID_ALPHA >= beta))
// [PARAM] min:3,max:10,step:1
PARAM_DEFINE(int) PARAM_IID_DEPTH_PV = 5;
// [PARAM] min:5,max:12,step:1
PARAM_DEFINE(int) PARAM_IID_DEPTH_NONPV = 8;
// [PARAM] min:100,max:400,step:16
PARAM_DEFINE(int) PARAM_IID_ALPHA = 256;
こんな感じで書いていく。てかIIDは、メモリが潤沢にあれば関係ないのでこの調整はしない。
・ざっと書けた。他の細かい探索パラメーターは調整が難しいので評価関数を書きなおしてからにする。
とりあえずコンセプトプルーフだけでも。
・3乗ボーナスやりすぎであったか…。(thx.woodyringさん)
- Value bonus = Value(((int)depth * (int)depth * (int)depth) / ((int)ONE_PLY*(int)ONE_PLY*(int)ONE_PLY) - 1);
+ Value bonus = Value((depth / ONE_PLY) * (depth / ONE_PLY) + depth / ONE_PLY - 1);
51.4%
#153
やねうら王classic-tce V277
3乗ボーナスを2乗に, 1スレッド、0.1秒設定
#0
やねうら王classic-tce V276
skip-early-pruningでもkillerがないなら更新, 1スレッド、0.1秒設定
357-79-337(21.3% R10.0)
■ 2016/04/14 V2.76
・浅い探索のときでもkillerぐらい更新したほうが得なのでは。(thx.読み太の作者)
if (ss->skipEarlyPruning)
+ {
+ // しかしkillerがないときはkillerぐらいは登録したほうが少しだけ得かも。
+ if (ss->killers[0] == MOVE_NONE)
+ ss->killers[0] = move32;
+ else if (ss->killers[1] == MOVE_NONE)
+ ss->killers[1] = move32;
return;
+ }
54.7%
#152
やねうら王classic-tce V276
skip-early-pruningでもkillerがないなら更新, 1スレッド、0.1秒設定
#0
やねうら王classic-tce V273
skip-early-pruningにおいてhistory,killerを更新しない, 1スレッド、0.1秒設定
519-81-429(0.2% R33.1)
■ 2016/04/14 V2.75
・tce vs Apery(WCSC25) 1スレッド5秒固定。62-3-50。
1スレッドもしくは短い持ち時間ではあまり差がつかない。
・MAX_PLYでの引き分け判定、1本化する。
if (Signals.stop.load(std::memory_order_relaxed) || ss->ply >= MAX_PLY || pos.game_ply() > Limits.max_game_ply)
→
Limits.max_game_ply = std::min(Limits.max_game_ply, rootPos.game_ply() + MAX_PLY -1);
こないして、ss->ply >= MAX_PLYの判定を消す。
- if (ss->ply >= MAX_PLY || pos.game_ply() > Limits.max_game_ply)
+ if (pos.game_ply() > Limits.max_game_ply)
- if (Signals.stop.load(std::memory_order_relaxed) || ss->ply >= MAX_PLY || pos.game_ply() > Limits.max_game_ply)
+ if (Signals.stop.load(std::memory_order_relaxed) || pos.game_ply() > Limits.max_game_ply)
・singular extensionを行うかどうかのsearch()の他に、do_moveせずに呼び出すsearch()が2カ所あって（nullmoveの後ろと、iid)
その内部でも同様にkillerとhistoryを更新しないように抑制する。(その部分で更新されるkiller手はもともと登録されてあったkiller手よりは価値が低いので。)
(thx. 読み太の作者)
// IID、null move、singular extensionの判定のときは浅い探索なのでこのときに
// killer等を更新するのは有害である。
if (ss->skipEarlyPruning)
return;
こう変更してみる。
54.7%
#151
やねうら王classic-tce V273
skip-early-pruningにおいてhistory,killerを更新しない, 1スレッド、0.1秒設定
#0
やねうら王classic-tce V271a
revertした, 1スレッド、0.1秒設定
271-34-224(1.5% R33.1)
効果あがあるっぽい。採用。
Stockfish7でも(本家がこれを採用すれば)たぶん効果があるばす。
・これにてtceの開発終了。
exeフォルダに最新のビルドを入れる。
次はやねうら王2016(Mid)の開発に着手。
■ 2016/04/14 V2.74
・ponder消失問題に対処。
fail low時など、置換表にも2手目がないのイクナイ。
→ 追加した。
・ponder、extract_ponder_from_tt()で置換表あさって返すとき、1手目の合法手集合からcontainsで調べてるの、
Stockfishのコードは、バグだな。なんなのこれ。修正した。
しばらくランニングさせておく。
・HalfDensity、おかしい気がする。
// game_ply()は加算すべきではない気がする。あとで実験する。
const Row& row = HalfDensity[(idx - 1) % HalfDensitySize];
if (row[(rootDepth + rootPos.game_ply()) % row.size()])
→ よくわからないが少なくとも足す必要はないように思えるのだが…。
■ 2016/04/14 V2.73
・YaneuraOu 2016は、Mid(5月時点のバージョン/公開)とLate(11月時点のバージョン/非公開)とに分離。前者は公開する。
・自己対戦フレームワークで定跡データベース中の対局の手数が指定した手数より少ない場合クラッシュするっぽいバグ修正。(thx. tanuki-)
■ 2016/04/13 V2.72
・singular extension等では現在のkillerを更新すべきではない説の検証。(thx.読み太の作者)
exclusion nodeでkiller更新とか、やったらあかんのちゃう仮説。
inline void update_stats(const Position& pos, Stack* ss, Move move,
Depth depth, Move* quiets, int quietsCnt)
{
+ // 特定の指し手を除外して探索したなら、今回の指し手がこのnodeでのベストな指し手ではないから
+ // このときにkiller等を更新するのは有害である。
+ if (ss->excludedMove != MOVE_NONE)
+ return;
→ 何らか現実的な効果があるくさい。singularとの兼ね合いかも知れないが。
これ、効果があるならこのアイデアは本家Stockfishにも取り込まれるべき。
51.4%
#148
やねうら王classic-tce V272
exclusion moveがあるときupdate_statしない, 1スレッド、0.1秒設定
#0
やねうら王classic-tce V271a
revertした, 1スレッド、0.1秒設定
241-49-228(25.9% R9.6)
V2.72a
if (ss->excludedMove != MOVE_NONE)
{
// ただしkillerがないなら、ないよりはマシだろうから今回の指し手を登録する。
+ if (ss->killers[0] == MOVE_NONE)
+ ss->killers[0] = make_move32(move);
return;
}
50.9%
#149
やねうら王classic-tce V272a
exclusion moveあってもupdate_stat,killerは更新する, 1スレッド、0.1秒設定
#0
やねうら王classic-tce V271a
revertした, 1スレッド、0.1秒設定
226-56-218(33.5% R6.3)
V2.72b
// このnodeでは、singular extensionをしているので、置換表の指し手がbestのはずで、
// 二番目の指し手が今回の指し手のはずだから、兄弟nodeのためには、以下のように
// killerを設定してやるのが適切。
if (ss->killers[0] == MOVE_NONE)
{
+ ss->killers[0] = make_move32(ss->excludedMove);
+ ss->killers[1] = make_move32(move);
}
49.0%
#150
やねうら王classic-tce V272b
exclusion moveあってもupdate_stat,killerは更新する, 1スレッド、0.1秒設定
#0
やねうら王classic-tce V271a
revertした, 1スレッド、0.1秒設定
216-50-225(68.3% R-7.1)
よくわからないが勝率下がったので取り入れない。
対局、3000局ぐらいやらないとわからない。
■ 2016/04/13 V2.71
・ehash実装するの忘れてた。(thx.平岡さん)
→ 何も速くならんかった…。
・置換表にstaticEval保存しなくてもnpsほとんど変わらない。
staticEval、置換表が壊れてておかしい値拾ってくるリスクを考えると
保存しないほうがいいような気すらする。勝率変わるかテストする。
49.3%
#146
やねうら王classic-tce V271
置換表にstaticEval保存しない, 1スレッド、0.1秒設定
#0
やねうら王classic-tce V265
駒打ちを Statsに含めてみる実験, 1スレッド、0.1秒設定
138-31-142(61.7% R-5.0)
V2.65とやってほぼ互角。
V2.71a
・revertしてV2.65と対戦。
52.8%
#147
やねうら王classic-tce V271a
revertした, 1スレッド、0.1秒設定
#0
やねうら王classic-tce V265
駒打ちを Statsに含めてみる実験, 1スレッド、0.1秒設定
142-32-127(16.5% R19.4)
ということでrevertする。
■ 2016/04/11 V2.70
・ProbCutのパラメーター調整
- Value rbeta = std::min(beta + 200, VALUE_INFINITE);
+ Value rbeta = std::min(beta + 100 + param1 * 50, VALUE_INFINITE);
param1 = 0..4ぐらいで。
48.6% 52.3% 52.6% 50.5% 50.8%
#145
やねうら王classic-tce V270
probcut調整, 1スレッド、0.1秒設定
#0
やねうら王classic-tce V265
駒打ちを Statsに含めてみる実験, 1スレッド、0.1秒設定
275-58-291(76.3% R-9.8) 298-54-272(12.9% R15.9) 288-76-260(10.8% R17.8) 276-73-270(38.2% R3.8) 185-52-179(35.7% R5.7)
よくわからない。いじらんとこ。
・一括パラメーター調整の仕組み、何か考える。
■ 2016/04/11 V2.69
・historyとか、成りの指し手のときは、成り駒のhistoryを見ないといけないのに
そういう処理になってなかった。(thx. 読み太の作者さん)
Position::moved_piece(),moved_piece_ex()修正。
make_move32()、config.hに移動。
50.5%
#144
やねうら王classic-tce V269a
historyに成り区別, 1スレッド、0.1秒設定
#0
やねうら王classic-tce V265
駒打ちを Statsに含めてみる実験, 1スレッド、0.1秒設定
1277-324-1251(30.3% R3.6)
もっと良くなりそうなものだが、何かまだ書き換え忘れている？
→ わからん...誰かデバッグきぼんぬ。
■ 2016/04/11 V2.68
・電王戦から戻ってきたー。
・aspiration searchにするdepth
- if (rootDepth >= 5 * ONE_PLY)
+ if (rootDepth >= 5 )
これStockfishのソースコード自体が間違ってるんだな。
こうやってparam1 = 0..5ぐらいで回しておく。
if (rootDepth >= 3 + param1)
48.6% 50.5% 50.3% 48.7% 51.1% 50.5%
#142
やねうら王classic-tce V268
aspiration depth調整, 1スレッド、0.1秒設定
#0
やねうら王classic-tce V265
駒打ちを Statsに含めてみる実験, 1スレッド、0.1秒設定
1364-373-1445(93.7% R-10.0) 1424-319-1398(31.2% R3.2) 1374-329-1358(38.0% R2.0) 1350-383-1422(91.4% R-9.0) 1418-337-1355(11.6% R7.9) 1384-384-1357(30.3% R3.4)
param1 = 4で最大。(+R7.9)
if (rootDepth >= 9 + param1)
この条件でparam1 = 0..2でもテストしておく。
50.7% 49.0% 43.3%
#142
やねうら王classic-tce V268
aspiration depth調整, 1スレッド、0.1秒設定
#0
やねうら王classic-tce V265
駒打ちを Statsに含めてみる実験, 1スレッド、0.1秒設定
183-55-178(37.6% R4.8) 178-53-185(66.3% R-6.7) 120-37-157(98.9% R-46.7)
+ if (rootDepth >= 7)
■ 2016/04/08 V2.67
・修正忘れてた…。
if (pos.state()->sumKKP == INT_MAX)
- ss->staticEval = evaluate(pos);
+ evaluate(pos);
これで少しでも強くなってるのか一晩回してみる。
50.7%
#141
やねうら王classic-tce V267
evaluate()のときにstaticEvalに代入やめる, 1スレッド、0.1秒設定
#0
やねうら王classic-tce V265
駒打ちを Statsに含めてみる実験, 1スレッド、0.1秒設定
1067-281-1039(27.1% R4.6)
■ 2016/04/08 V2.66
・評価関数、差分計算するときに
sumKKP == VALUE_NONE
を判定条件にしていると偶然一致することがあるのか。なんてこったい…。
INT_MAXを代わりに使うようにする。(thx. tさん)
■ 2016/04/07 V2.65
・駒打ちを Statsに含めてみる実験。
USE_DROPBIT_IN_STATSを追加。
→ 結構、勝ってるような？
これ、効果あるということならいまからソースコード整理しよう..
moved_piece() 1手前の指し手に対して呼び出すと駒打ちにおいて手番が異なるから
呼び出してはいけないのか。
→ そんなことしてる箇所はなかった。
51.8%
#140
やねうら王classic-tce V265
置換表にeval保存しない, 1スレッド、0.1秒設定
#0
やねうら王classic-tce V261
VALUE_WINの値変更, 1スレッド、0.1秒設定
216-37-201(21.7% R12.5)
ほぼ強くなってないな…。
+ auto& prevCmh = CounterMoveHistory[prevPrevSq][prevPrevPc];
+ prevCmh.update(prevPc , prevSq, bonus);
ここも修正要るのか。忘れてた。
53.0%
#140
やねうら王classic-tce V265
置換表にeval保存しない, 1スレッド、0.1秒設定
#0
やねうら王classic-tce V261
VALUE_WINの値変更, 1スレッド、0.1秒設定
157-25-139(13.5% R21.2)
・とりあえず強くなったのでexeフォルダのtce版、差し替えておく。
■ 2016/04/07 V2.64
・evaluateの値、置換表に放り込む価値はないのでは...
bench
Total time (ms) : 60870
Nodes searched : 44842076
Nodes/second : 736685
毎回evaluate()呼び出してみる。
Total time (ms) : 54219
Nodes searched : 39945800
Nodes/second : 736749
nps変わらないし、置換表効率が良くなったし、こっちのほうがいいような…。
強さは変わらないのか？しばらくランニングさせておいて問題なさそうならこれにする。
置換表効率は4/3倍になっているので33%の改善…。
処理的には等価なはずなのだが、探索node数が変わっている..
置換表衝突で破損していた分なのか..
→
48.2%
#139
やねうら王classic-tce V264
置換表にeval保存しない, 1スレッド、0.1秒設定
#0
やねうら王classic-tce V261
VALUE_WINの値変更, 1スレッド、0.1秒設定
355-83-381(84.0% R-12.3)
弱くなったので戻す。うーん..。
■ 2016/04/07 V2.63
・singular実験やりなおし。
Value rBeta = ttValue - (param1+1) * 4 * depth / ONE_PLY;
param1 = 0..3ぐらいで。
singularのmargin値、少しぐらい変えても強くも弱くもならないということなのか？
・VALUE_SUPERIORとかの関係か、以前と同じ値のはずなのにR10ぐらい強くなってる気が..
1000局ほど対局させとくか。
singular 0.1秒だといまひとつはっきりしないな…。
52.4% 51.2% 52.3% 52.8%
#138
やねうら王classic-tce V263
singular調べ直し, 1スレッド、0.1秒設定
#0
やねうら王classic-tce V261
VALUE_WINの値変更, 1スレッド、0.1秒設定
196-42-178(16.3% R16.7) 193-39-184(30.3% R8.3) 190-53-173(17.2% R16.3) 182-41-163(14.1% R19.2)
Value rBeta = ttValue - (param1+1) * 2 * depth / ONE_PLY;
param1 = 0..10ぐらいで2,3日まわしとくか..
一応、param1=0(2*depth*ONE_PLY)での勝率を確認しておく。
Stockfishがこの設定のはず。
51.1%
#138
やねうら王classic-tce V263
singular調べ直し, 1スレッド、0.1秒設定
#0
やねうら王classic-tce V261
VALUE_WINの値変更, 1スレッド、0.1秒設定
255-65-244(29.6% R7.7)
変わらないのか…。
Value rBeta = ttValue - 40 * depth / ONE_PLY;
これはどうなの。
47.0%
#138
やねうら王classic-tce V263
singular調べ直し, 1スレッド、0.1秒設定
#0
やねうら王classic-tce V261
VALUE_WINの値変更, 1スレッド、0.1秒設定
171-51-193(88.6% R-21.0)
・結論的にはよくわからない。
■ 2016/04/07 V2.62
・DYNAMIC_FUTILITY_MARGINの実験やりなおし。
return (16+param1*4) * futility_margin_sum * (int)d / ONE_PLY / (64 * 8);
これくらいに設定して、param1 = 0..4ぐらいで比較。
+ // 評価関数の返す値の最大値
+ VALUE_MAX_EVAL = int(VALUE_KNOWN_WIN) -1,
49.5% 54.3% 42.2% 47.7% 48.1%
#136
やねうら王classic-tce V262
dynamic futility調べ直し, 1スレッド、0.1秒設定
#0
やねうら王classic-tce V261
VALUE_WINの値変更, 1スレッド、0.1秒設定
180-52-184(60.3% R-3.8) 102-20-86(10.7% R29.6) 79-21-108(98.6% R-54.3) 94-11-103(76.2% R-15.9) 91-19-98(72.0% R-12.9)
param1 = 1で最大
return (20 + (param1-1)*2) * futility_margin_sum * (int)d / ONE_PLY / (64 * 8);
param1 = 0..2ぐらいで
49.2% 49.5% 50.8%
#137
やねうら王classic-tce V262a
dynamic futility調べ直し, 1スレッド、0.1秒設定
#0
やねうら王classic-tce V261
VALUE_WINの値変更, 1スレッド、0.1秒設定
92-21-95(61.5% R-5.6) 96-14-98(58.5% R-3.6) 94-21-91(38.4% R5.6)
強くなってないな…。この実験はまた今度。
・めっさ落ちる。なにこれ。
sfen l+R2lbnnl/3skp1s1/pppp3p1/4pPG1p/3N5/2P1G3P/PP1PP2P1/6S2/+s2G1K1RL b PGpnb 75
> VALUE_KNOWN_WIN = int(VALUE_MATE_IN_MAX_PLY) - 1,
こんな近いと置換表に書き込んで、相手番から見ると
- VALUE_KNOWN_WIN
になって、ここにsingularの判定などでmarginを引くと
VALUE_MATE_IN_MAX_PLY
より下回るのでまずいのか…。そうなのか…。
dynamic marginでおかしくなってたの、これが一因にあるのか。
・dynamic margin、なんか以前のものより勝率よさげ？
・色々考えた結果、優等局面のスコア変更することにする。
{ VALUE_SUPERIOR , VALUE_SUPERIOR }, // REPETITION_SUPERIOR
{ -VALUE_SUPERIOR , -VALUE_SUPERIOR }, // REPETITION_INFERIOR
そしてこう変更する。
VALUE_SUPERIOR = 28000,
VALUE_MAX_EVAL = 25000,
■ 2016/04/07 V2.61
{ VALUE_KNOWN_WIN , VALUE_KNOWN_WIN }, // REPETITION_SUPERIOR
{ -VALUE_KNOWN_WIN , -VALUE_KNOWN_WIN }, // REPETITION_INFERIOR
これ、-1にしたほうが良いのでは..
VALUE_KNOWN_WIN自体はEVALの最大値としてつこてるから…。
{ VALUE_KNOWN_WIN-1 , VALUE_KNOWN_WIN-1 }, // REPETITION_SUPERIOR
{ -VALUE_KNOWN_WIN+1 , -VALUE_KNOWN_WIN+1 }, // REPETITION_INFERIOR
こう変更して比較。
少し強くなってる…気がする。500戦ほどさせておく。
51.2%
#135
やねうら王classic-tce V261
revert, 1スレッド、0.1秒設定
#0
やねうら王classic-tce V260b
revert, 1スレッド、0.1秒設定
306-66-292(27.0% R8.1)
・自己対戦で落ちた模様
sfen ln1l1+R2+P/1k3p3/1pps5/p2p2p1P/2g1p3p/KPsP1rg2/P3P+s3/1B7/LNSG4L b 2PB2p2ng 153
・詰まされる形、投げるタイミング早すぎ。
- && (bestValue - (-VALUE_MATE)) * 3 > rootDepth)
+ && (bestValue - (-VALUE_MATE)) * 2 < rootDepth)
・go infiniteに対して、stopが来ていないのにbestmoveを返してしまう。
- while (!Signals.stop && Search::Limits.ponder)
+ // "go infinite"に対してはstopが送られてくるまで待つ。
+ while (!Signals.stop && (Limits.ponder || Limits.infinite))
→ 一応、意図通りになった模様。
・とりあえず結論的には自己対戦の回数もっとやらないとバグを仕込んで弱くなったときの原因究明に時間がかかる
ということ。
・6c6tと6c12t比較
14-8-22 // 8分切れ負け
28-9-31 // 5分切れ負け
時間が長いと大差？
スレッド数増やしても弱くはならないみたい。R30か40ぐらい上がるのかな？
弱くならないということがわかったからそれでいいや。細かい比較はいまできないし。
■ 2016/04/07 V2.60
・若干弱くなっているのが気になる。
46.8%
#132
やねうら王classic-tce V259
counter move修正, 1スレッド、0.1秒設定
#0
やねうら王classic-tce V253s
singular再テスト, 1スレッド、0.1秒設定
265-42-301(94.0% R-22.1)
・counter move、82,83を使うことない気がしてきた。ちょっと修正。
if (!is_ok(move)) \
{ \
+ sq = (Square)color; \
pc = NO_PIECE; \
} else { \
→ 修正完了。
・これで弱くなってるんではない気がする。
futility margin、やはり変なことするといかんのだな…。
// futility margin with game_ply
// 序盤で小さめの数値。
// 40手以降はd * 90固定でいいや。
// rを進行度とみなして、これで70と90を内分する。
game_ply = min(40, game_ply);
float r = game_ply / 40.0f;
return Value(d * int(((1 - r) * 70 + 90 * r)));
→ これやめて、再度練り直す。
V2.60a
・dynamic futility marginのsampling次のような条件でどうか。
if (newDepth == ONE_PLY
&& eval != VALUE_NONE // evalutate()を呼び出していて
&& !captureOrPromotion // futilityはcaptureとpromotionのときは行わないのでこの値は参考にならない
&& !InCheck // 王手がかかっていなくて
&& abs(value) < VALUE_MAX_EVAL // evalのスコア
&& alpha < value && value < beta // fail low/highしていると参考にならない
)
{
// 移動平均みたいなものを求める
futility_margin_sum = futility_margin_sum * 63 / 64;
futility_margin_sum += abs(value - eval);
static int count = 0;
if ((++count & 0x100) == 0)
sync_cout << "futility_margin = " << futility_margin_sum / 64 << sync_endl;
}
// 14/8ぐらいかけとかないといけない(気がする)
// game ply(≒進行度)とdepth(残り探索深さ)に応じたfutility margin。
Value futility_margin(Depth d, int game_ply) {
// 平均値に 14/8 を掛け算しとく。
return 14 * futility_margin_sum * (int)d / ONE_PLY / (64 * 8);
}
・DYNAMIC_FUTILITY_MARGINはifdefで書くように変更
もうちょっと実験の余地がありそう。
・V2.53sと対戦。なんかちょっと負けてる予感。
ソースコード、差分取って調べるべき。
→ 比較してみたがほぼ変わらない。
staticEval = evaluate()するのでimprovingには影響があるかも。
45.6%
#133
やねうら王classic-tce V260a
counter move修正, 1スレッド、0.1秒設定
#0
やねうら王classic-tce V253s
singular再テスト, 1スレッド、0.1秒設定
182-43-217(96.4% R-30.6)
・VALUE_WIN絡み、MATEスコアとして表示してしまうバグ。
もしかして、VALUE_MATE_IN_MAX_PLY超えてるのか？
- VALUE_KNOWN_WIN = int(VALUE_MATE_IN_MAX_PLY) - 1,
+ VALUE_KNOWN_WIN = int(VALUE_MATE_IN_MAX_PLY) - 100,
こう修正しとく。
・
// 評価値が2手前の局面から上がって行っているのかのフラグ
// 上がって行っているなら枝刈りを甘くする。
// ※ VALUE_NONEの場合は、王手がかかっていてevaluate()していないわけだから、
// 枝刈りを甘くして調べないといけないのでimproving扱いとする。
bool improving = (ss )->staticEval >= (ss - 2)->staticEval
|| (ss )->staticEval == VALUE_NONE
|| (ss - 2)->staticEval == VALUE_NONE;
これ、evaluateを毎回呼び出すようにして、staticEvalに格納するようにしたから
王手がかかっているときにこの条件満たさなくなってしまったのか…。
こんなことで弱くなるのか…。
staticEvalに代入するのやめるか。
これでしばらく回す。
→ 勝率めっさ落ちた。どうなってんの…。
2.53sともう少し厳密に違いを調べていくべき。
44.8%
#133
やねうら王classic-tce V260a
counter move修正, 1スレッド、0.1秒設定
#0
やねうら王classic-tce V253s
singular再テスト, 1スレッド、0.1秒設定
296-75-365(99.7% R-36.4)
・
V2.60b
VALUE_WIN、やっぱり戻す。
レアケースだし、要らん変換が入るし、
置換表に書き出せなくなるし…。
VALUE_KNOWN_WIN_IN_MAX_PLY = int(VALUE_KNOWN_WIN) - MAX_PLY,
VALUE_KNOWN_LOSE_IN_MAX_PLY = -int(VALUE_KNOWN_WIN_IN_MAX_PLY),
// 評価関数が返すであろう最大値
VALUE_MAX_EVAL = int(VALUE_KNOWN_WIN_IN_MAX_PLY) - 1,
→ 削除
- return value_from_tt(draw_value(REPETITION_DRAW, pos.side_to_move()),ss->ply);
+ return draw_value(REPETITION_DRAW, pos.side_to_move());
- // 詰みのスコアに対して、rootからの手数を考慮したスコアに変換する必要があるので、
- // value_from_tt()で変換してから返すのが正解。
→ そうか。連続王手の千日手は詰みのスコアなのでこの処理、正しい。
・これで500対戦ほどさせて勝率がまだ落ちているようなら、色々元に戻していく。
・
endMoves = currentMoves + 2 + (counterMove != killers[0] && counterMove != killers[1]);
ここ、counterMoveがu32なのにkillers[0]はu32として比較していないのでは..
#ifdef KEEP_PIECE_IN_COUNTER_MOVE
counterMove = (Move)counterMove; // 駒種が上位に格納されているのならマスクする。
#endif
これが要るような？
・NULL_MOVEに対してcounterどうせ登録されてないから、このときMOVE_NONEにしておくほうが
オーダリング改善されるのでは…
#define sq_pc_from_move(sq,pc,move,color) \
if (!is_ok(move)) \
{ \
sq = (Square)(color); \
pc = NO_PIECE; \
} else { \
sq = move_to(move); \
pc = pos.piece_on(sq); \
}
// toの升に駒pcを動かしたことに対する応手
auto cm =
is_ok((ss - 1)->currentMove)
? thisThread->counterMoves[prevSq][prevPc]
: MOVE_NONE
;
こうしたほうがマシなのでは..。
これでしばらく放置しておく。
NULL MOVEのあと、糞みたいな指し手がcounter moveに挙がってくると
オーダリングを阻害する(気がする)
43.4%
#134
やねうら王classic-tce V260b
revert, 1スレッド、0.1秒設定
#0
やねうら王classic-tce V253s
singular再テスト, 1スレッド、0.1秒設定
192-36-250(99.8% R-45.9)
それでも負けとる…。
・KEEP_PIECE_IN_COUNTER_MOVEをundefにして比較する。
→ 同様に負けとる..
・もしかしてsingularが悪さしてるのか？
singularオフにしたらもっと大差になった。なんなんこれ…。
原因わかった。
- auto& cmh = CounterMoveHistory[prevSq][prevSq];
- auto& fmh = CounterMoveHistory[prevPrevSq][prevPrevSq];
+ auto& cmh = CounterMoveHistory[prevSq][prevPc];
+ auto& fmh = CounterMoveHistory[prevPrevSq][prevPrevPc];
うわわわわあああ。
→ 直った気がする。
やっと互角に戻った。もっかい実験やりなおし…。
■ 2016/04/07 V2.59
・Position::pseudo_legal_s()に、countermove関連のassert追加。
・ASSERT_LV 4 にして、
> test autoplay
で回しておく。
・ああ、落ちる原因わかった。
dropのときも駒種を入れておいて、それが手番側の駒であるかを確認しないといけないのか…。そうか。
てか、countermove、移動元の駒だけでなく移動元の駒種もあるほうが良いのでは…。
いやー、そもそも後手の駒を動かす指し手に対するcounter moveに対して何故後手の指し手が登録されているのか？
・counter moveに関して次のassert追加。
ASSERT_LV3(color_of(prevPc) == ~pos.side_to_move());
・Limitsのコンストラクタに
enteringKingRule = EKR_NONE;
追加。(test autoplayなどで困るため)
・counter move
auto prevSq = move_to((ss - 1)->currentMove);
auto prevPc = pos.piece_on(prevSq);
こうなっているが、null moveのこと考えてないな、このコード。Stockfishのコード自体がおかしい。
チェスでは駒が上下対称に動くから顕在化しないのだと思うが…。
// 直前のnoddの指し手で動かした駒とその移動先の升を返す。
// ただしNULL_MOVEのときは、SQ_NB_PLUS1 + 0か + 1の地点に動かしたことにする。
#define sq_pc_from_move(sq,pc,move,color) \
if (move == MOVE_NULL) \
{ \
sq = (Square)(SQ_NB_PLUS1 + ((color == BLACK) ? 0 : 1)); \
pc = NO_PIECE; \
} else { \
sq = move_to(move); \
pc = pos.piece_on(sq); \
}
こういうマクロを作って、先手用のcounter moveとして後手の指し手が混じらないようにした。
→ root nodeだと(ss - 1)->currentMove == MOVE_NONEなのであった…。
上の処理、!is_ok(move)と書かないと駄目なのか..
これでしばらく回しておいて問題なさげなら、自己対戦してテスト。
・exe/フォルダのtce版、差し替え。
■ 2016/04/07 V2.58
・自己対戦サーバー、256手到達でその次がタイムアウトになっとる..なんでなの..
4<draw,ln1k1g1nl/2gsp3r/pppp1pbs1/4P1ppp/3P1P3/P5PPP/1PP1S1NG1/1BG4K1/LNS1R3L w - 256
4<Error : engine timeout , engine name = engines\YaneuraOu-classic-tceV257.exe
・MaxMovesToDraw、きちんと機能してない
→ 修正した。
sfen ln1k1g1nl/2gsp3r/pppp1pbs1/4P1ppp/3P1P3/P5PPP/1PP1S1NG1/1BG4K1/LNS1R3L w - 255
・自己対戦サーバーでStateStack、1局ごとにクリアするように修正。
・4台のPC、一晩で自己対戦させたときに2局落ちてる。
CounterMoveのpseudo-legalまわりか？
・KEEP_PIECE_IN_COUNTER_MOVEをデフォルトでdefineしたままになっていたの修正。
・他、原因よくわからん…。
・lazySMP有効時に物理6コアに対して何スレッドが最大強さになるのかテストする。
■ 2016/04/06 V2.57
・futility margin、わからん。こっちのほうが良いのでは..
// futilityは深さに比例するより、少し減衰したほうがいいと思う。
// 実戦では連続して大きな損をしないから。
// f(a,depth) = Σ pow(a ,depth) ≒ integral pow( a , depth ) = a ** depth / log(a) + c
// depth == 1において1になって欲しいから、
// a / log(a) + c = 1
// 積分定数c = 1 - a / log(a)
{
const float a = 0.98f - param1 * 0.2f;
for (int i = 0; i < MAX_PLY; ++i)
futility_rate[i] = pow(a, i) / log(a) + (1 - a / log(a));
}
param1 = 0..4で一晩放置。
49.6% 46.8% 44.8% 39.5% 39.0%
#131
やねうら王classic-tce V257
dynamic-futility margin, 1スレッド、0.1秒設定
#0
やねうら王classic-tce V253s
singular再テスト, 1スレッド、0.1秒設定
737-197-750(63.2% R-3.0) 675-159-766(99.2% R-22.0) 646-157-795(100.0% R-36.1) 560-182-858(100.0% R-74.1) 564-148-881(100.0% R-77.5)
全く強くならんかった。要らんことしたようであった…。そうなのか…。
dynamic marginで、もっかい調整しよ。
■ 2016/04/06 V2.56
・dynamic futility marginの計算、直近の値を重視したいから線形加重移動平均にしたほうがいいな。
もう少し当たりをつけてから変更してみる。
→ 実装が少し面倒なわりに効果あまりない気がしてきたので、もう少し簡単な方法でいいや。
再度調整してみる。
// このときにdynamic futility marginの値をサンプリングする
if (newDepth >= ONE_PLY
&& eval!=VALUE_NONE && abs(value) < VALUE_KNOWN_WIN_IN_MAX_PLY
&& value < beta // fail highしている値は信用ならないので除外
&& value < eval // 静的評価値が探索したスコアより大きく出ている局面(楽観視)を対象とする
)
{
int d = newDepth / ONE_PLY;
futility_margin_sum[d] += (eval >= beta) ? (eval - value) * d : eval - value;
if (futility_margin_count[d]++ == futility_margin_update_interval)
{
// futility_sampling_intervalのfutility_margin_update_count倍の要素の合計がfutility_margin_sum[d]
futility_margin_table[d] = ((param1 + 4) * futility_margin_sum[d] / 4)
/ (futility_margin_update_count * futility_margin_update_interval);
// 1/4が入れ替わったという考え。(本当は古い部分を入れ替えたほうがいいかも知れないが…)
futility_margin_sum[d] = futility_margin_sum[d] * (futility_margin_update_count - 1)/ futility_margin_update_count;
futility_margin_count[d] = 0;
cout << "futility_margin[" << d << "] = " << futility_margin_table[d] << endl;
}
}
param1 = 0..2とかで。
→ ぜんぜんあかん..
// このときにdynamic futility marginの値をサンプリングする
if (newDepth == 1 * ONE_PLY
&& eval!=VALUE_NONE && abs(value) <= VALUE_MAX_EVAL
&& value < beta // fail highしている値は信用ならないので除外
&& alpha < value // fail lowしている値は参考にならないので除外
こうして、depth = ONE_PLYをサンプリングして、これにdepth掛け算するだとか..。
47.6% 46.4% 55.5% 50.7%
#130
やねうら王classic-tce V256
dynamic-futility margin, 1スレッド、0.1秒設定
#0
やねうら王classic-tce V253s
singular再テスト, 1スレッド、0.1秒設定
140-24-154(80.9% R-16.6) 65-20-75(82.4% R-24.9) 76-23-61(8.6% R38.2) 70-22-68(39.9% R5.0)
・統計的にはfutilityのmargin、depthに比例しない感じだな..
3手あれば何らか被害を小さくできたりするが、1手だと取られるものはとられるわけで…。
■ 2016/04/06 V2.55
・dynamic futility margin(案) , inspired by 読み太
最初、
sample_count[depth] = 100; // 100個のサンプルがすでにあるという体裁
sample_sum[depth] = 90 * sample_count[depth]; // 初期futility margin
とかにしといて、
search<PV>(..)
で探索したときに残りdepthとeval-valueをここに突っ込む。
sample_count[depth] ++;
sample_sum[depth] += abs(eval - value);
んで、
futility_margin(depth) { return sample_sum[depth] / sample_count[depth]; }
みたいなことで。
sample_countがある程度大きくなったら、次のようにgarbageすると良さそう
if (sample_count[depth] > 1000)
{
sample_count[depth] >>= 1;
sample_sum[depth] >>= 1;
}
↓書けた。
// このときにdynamic futility marginの値をサンプリングする
if (newDepth >= ONE_PLY)
{
futility_margin_sum[newDepth] += abs(eval - value);
if (futility_margin_count[newDepth]++ == 4096)
{
// 4096 / 2個ごとにmargin値を計算しなおす。
futility_margin_table[newDepth] = futility_margin_sum[newDepth] / 4096;
futility_margin_sum[newDepth] /= 2;
futility_margin_count[newDepth] = 4096/2;
}
}
// game ply(≒進行度)とdepth(残り探索深さ)に応じたfutility margin。
Value futility_margin(Depth d, int game_ply) {
// dynamic futility margin
return futility_margin_table[d];
}
・dynamic futility margin、変動幅の平均で本当に良いのかどうかはよくわからない。
値を変えながら勝率を見るべき..
futility_margin_table[d] = (param1 + 3) * futility_margin_sum[d] / 4 / sampling_interval;
param1 = 0..7ぐらいで対戦させてみる。
param1 == 2あたりがmax。平均より25%増しぐらいがベスト。感覚に合致する。
もうちょっと細かく分割して調整してみる。
38.0% 42.4% 53.1% 44.3% 46.5% 53.8% 42.7% 45.3%
#129
やねうら王classic-tce V255
dynamic-futility margin, 1スレッド、0.1秒設定
#0
やねうら王classic-tce V253s
singular再テスト, 1スレッド、0.1秒設定
73-20-119(100.0% R-84.9) 59-21-80(96.9% R-52.9) 77-15-68(20.3% R21.6) 62-20-78(92.5% R-39.9) 66-18-76(82.2% R-24.5) 77-17-66(15.8% R26.8) 61-17-82(96.7% R-51.4) 67-12-81(89.1% R-33.0)
→ あまりよくない。条件自体を検討すべき。
・評価値計算した以上、ss->staticEvalに保存したほうが得なような気がする。
if (pos.state()->sumKKP == VALUE_NONE)
- evaluate(pos);
+ ss->staticEval = eval = evaluate(pos);
■ 2016/04/06 V2.54
・定跡12手までに制限してfloodgateに投入しておく。
・reduction、int(r)にしてしまうとONE_PLY==2にしている意味がないのでは…。
> reduction_table[pv][imp][d][mc] = int(r) * ONE_PLY;
比較してみる。
+ reduction_table[pv][imp][d][mc] = Depth((int)(r * (double)ONE_PLY));
44.9%
#126
やねうら王classic-tce V254
reductionテスト, 1スレッド、0.1秒設定
#0
やねうら王classic-tce V253s
singular再テスト, 1スレッド、0.1秒設定
343-111-421(99.8% R-35.6)
こんなんぐらいでこんなに勝率落ちるのか…。うわわぁぁぁ。
・dynamic futility marginの実験
// game ply(≒進行度)とdepth(残り探索深さ)に応じたfutility margin。
Value futility_margin(Depth d, int game_ply) {
// 序盤で小さめの数値。
// 40手以降はd * 90固定でいいや。
// rを進行度とみなして、これで30と90を内分する。
game_ply = min(40, game_ply);
float r = game_ply / 40.0f;
return Value(d * int((1 - r) * (30 + param1 * 10) + 90 * r));
}
param1 = 0..5ぐらいでひたすら回しておく。
47.7% 47.0% 47.2% 48.1% 54.8% 46.9%
#127
やねうら王classic-tce V254a
dynamic-futility margin, 1スレッド、0.1秒設定
#0
やねうら王classic-tce V253s
singular再テスト, 1スレッド、0.1秒設定
142-45-156(80.8% R-16.3) 139-24-157(86.5% R-21.2) 141-21-158(85.1% R-19.8) 137-35-148(76.1% R-13.4) 154-39-127(4.7% R33.5) 134-34-152(86.9% R-21.9)
param1 = 4がベストっぽい
V2.54b
return Value(d * int((1 - r) * (30 + 4 * 10) + 90 * r));
これでしばらく回してみる。
// 進行度に応じたmargin
#if 0
// 序盤で小さめの数値。
// 40手以降はd * 90固定でいいや。
// rを進行度とみなして、これで30と90を内分する。
game_ply = min(40, game_ply);
float r = game_ply / 40.0f;
return Value(d * int((1 - r) * (30 + 4 * 10) + 90 * r));
#endif
↓何も良くなかった。とほほほほ。
49.3%
#128
やねうら王classic-tce V254b
dynamic-futility margin, 1スレッド、0.1秒設定
#0
やねうら王classic-tce V253s
singular再テスト, 1スレッド、0.1秒設定
174-38-179(62.5% R-4.9)
■ 2016/04/06 V2.53
・counterの指し手、移動させる駒種入れるとどうか。
+ // MovePickerのなかで使っているCounterMoveにおいて、移動させる駒種も含めるか。
+ // (これを含めると同じ移動をする別の駒をCounterMoveとしてみなさなくなり、ちょっと枝刈り性能が上がるはず)
+ #define KEEP_PIECE_IN_COUNTER_MOVE
・これに伴い、config.hに
KEEP_PIECE_IN_COUNTER_MOVE
追加。
いやー、これをやるならkillerもやらないといけないのか..
効果があるようなら考えるか..
・MovePickerでkillerの指し手もチェックするように。
#ifdef KEEP_PIECE_IN_COUNTER_MOVE
Move32 m = (Move32)*currentMoves;
move = (Move)m;
// 移動させる駒種が一致するかを確認する。
if (!is_drop(move)
&& pos.piece_on(move_from(move)) != (Piece)(m >> 16))
break;
#else
move = *currentMoves++;
#endif
・これに伴い、Position::pseudo_legalのほう、簡略化。
→ R150も下がった。何かバグっている…。
- && make_move32(move) != (Move)ss->killers[0]
+ && make_move32(move) != ss->killers[0]
これかな？
→ 勝率、まともになった気がする。
互角ぐらいのようなのでしばらく放置。
49.7%
#124
やねうら王classic-tce V253a
counter moveにpiece入れる, 1スレッド、0.1秒設定
#0
やねうら王classic-tce V252
piece_on()→moved_piece(), 1スレッド、0.1秒設定
214-38-217(57.6% R-2.4)
ほぼ互角。
・V2.53s
↑の変更をしたのちにsingularを有効にしたらちょっと勝ち越している気がする。
なぜだかよくわからない。しばらく対局させておく。
57.4%
#125
やねうら王classic-tce V253s
singular再テスト, 1スレッド、0.1秒設定
#0
やねうら王classic-tce V253a
counter moveにpiece入れる, 1スレッド、0.1秒設定
159-33-118(0.6% R51.8)
↓
238-48-188(0.7% R41.0)
よくわからないがちょっと強くなってる。
singularに関しては、あとでもっと調整すべき。
このまわり、何かおかしい。
・定跡未使用のときにINT_MAXにしてるの間違いだった。修正した。
■ 2016/04/06 V2.52
・historyなどの指し手で、以前の指し手以外はpiece_on()ではなく、moved_piece()で判定しないといけない。(駒打ちのときにおかしくなっている) 修正。
→ 合ってた？
→ 下手に変更すると実行時間が余計にかかるようになって弱くなる。
・定跡を採用する手数制限が出来るようにする。
BookMoves のオプション追加。
・tceエンジン、フォルダ変更してなかった。
・何か弱くなっている気がするのでrollbackする。
3乗bonus、ONE_PLYで割りながらにしているのとか、どうも怪しい気がする。
→ なんかこのへん怪しい。bonus、慎重に調整すべき。
52.1%
#122
やねうら王classic-tce V252
piece_on()→moved_piece(), 1スレッド、0.1秒設定
#0
やねうら王classic-tce V251
bestMoveChanged修正, 1スレッド、0.1秒設定
596-93-548(7.8% R14.6)
今度は弱くなってなかった。よしよし。
■ 2016/04/06 V2.51
・reduction自体は 残りdepthに応じて行なうが、そのときにONE_PLYで割っているので、結局、
bonusもONE_PLYで割ったあとの形で2乗ボーナスとかにしないと辻褄があわない。
- Value bonus = Value((int)depth*(int)depth / ((int)ONE_PLY*(int)ONE_PLY) + (int)depth / (int)ONE_PLY + 1);
- if (ss->ply >= MAX_PLY || pos.game_ply() >= Limits.max_game_ply)
+ if (ss->ply >= MAX_PLY || pos.game_ply() > Limits.max_game_ply)
game_ply()、初期局面が1だから、初期局面からN手指したあとはN+1。
・null moveのとき、評価値反転させるの、差分計算する必要、ないのでは…。
→ do_null_move()でStateInfo丸ごとコピーしているから、合ってる。
・Stockfishのrazor marginのコード
&& depth < 4 * ONE_PLY
&& eval + razor_margin[depth] <= alpha
&& ttMove == MOVE_NONE)
{
if ( depth <= ONE_PLY
&& eval + razor_margin[3 * ONE_PLY] <= alpha)
ひとつ目のところもONE_PLY掛けるべきでは..うーん..
・VALUE_KNOWN_WINを使っているところVALUE_KNOWN_WIN_IN_MAX_PLYに変更しておく。
・bestmove changed のカウンター、インクリメントしてなかったの修正。
+ if (moveCount > 1 && thisThread == Threads.main())
+ ++static_cast<MainThread*>(thisThread)->bestMoveChanges;
・alpha更新のタイミングでeasy moveをクリアしていなかったの修正。
・色々いじったが、この時点で弱くなっていなければまずは良し。
53.4%
#121
やねうら王classic-tce V251
bestMoveChanged修正, 1スレッド、0.1秒設定
#0
やねうら王classic-tce V248a
tce版, 1スレッド、0.1秒設定
238-38-208(7.1% R23.4)
→ 弱くはなってなさげ。よしよし。
■ 2016/04/06 V2.50
・最大手数に到達して引き分けになるとき、qsearchで引き分けのスコアを返すように。
if (ss->ply >= MAX_PLY || pos.game_ply() >= Limits.max_game_ply)
・qsearchでVALUE_WINもrootからの深さに応じた値を返すべきなのか…。そうか…。
+ VALUE_KNOWN_WIN = int(VALUE_MATE_IN_MAX_PLY) - 1,
+ VALUE_KNOWN_WIN_IN_MAX_PLY = int(VALUE_KNOWN_WIN) - MAX_PLY,
+ VALUE_KNOWN_LOSE_IN_MAX_PLY = -int(VALUE_KNOWN_WIN_IN_MAX_PLY),
inline Value value_to_tt(Value v, int ply) {
ASSERT_LV3(-VALUE_INFINITE < v && v < VALUE_INFINITE);
+ return v >= VALUE_KNOWN_WIN_IN_MAX_PLY ? v + ply
+ : v <= VALUE_KNOWN_LOSE_IN_MAX_PLY ? v - ply : v;
}
value_from_tt()も同様の修正。
・qsearch()のfutility、成りも考慮する
+ + (is_promote(move) ? (Value)ProDiffPieceValue[pos.moved_piece(move)] : VALUE_ZERO) ;
50.1%
#120
やねうら王classic-tce V250
ValueWin修正, 1スレッド、0.1秒設定
#0
やねうら王classic-tce V248a
tce版, 1スレッド、0.1秒設定
573-101-571(47.6% R0.6)
→ 強さ変わらん
■ 2016/04/06 V2.49
・singular、持ち時間を変更しつつ試す。
V2.49
singular判定の係数を非常に大きくしてみる。(thx. tさん)
- Value rBeta = ttValue - 8 * depth / ONE_PLY;
+ Value rBeta = ttValue - 50 * depth / ONE_PLY;
→ 0.1秒対局で確かに5%ぐらい勝ち越している感じ..
marginが、こんなに大きいと終盤でのone replyっぽいところだけが延長されるような気が..
でも効果があるということなのか…。
rtime = 0.5秒で試してみる。
48.8%
#118
やねうら王classic-tce V249
singular調整, 1スレッド、0.1秒設定
#0
やねうら王classic-tce V248a
tce版, 1スレッド、0.1秒設定
335-61-351(74.2% R-8.1)
負けとる。やはりsingular、判定か何かがおかしいのか？
V2.49a
singular、8に戻してやってみる。
+ Value rBeta = ttValue - 8 * depth / ONE_PLY;
rtime = 500
52.8%
#119
やねうら王classic-tce V249a
singular調整, 1スレッド、0.1秒設定
#0
やねうら王classic-tce V248a
tce版, 1スレッド、0.1秒設定
180-49-161(13.9% R19.4)
確かに少し長い時間においてはR20ぐらい上がりそうではあるが、もう少し条件を変えてテストしてから考えよう。
■ 2016/04/06 V2.48
・rtime指定しているのにtce版のほうがR50ほど高い。タイマーの判定の問題？
V2.48a
・秒読み、ゼロ初期化忘れていた。これが送られてこないときにおかしくなっていた。
LimitsType() {
- nodes = time[WHITE] = time[BLACK] = inc[WHITE] = inc[BLACK] = npmsec
+ nodes = time[WHITE] = time[BLACK] = inc[WHITE] = inc[BLACK] = byoyomi[WHITE] = byoyomi[BLACK] = npmsec
= depth = movetime = mate = infinite = ponder = rtime = 0;
timeman.cpp
+ // remain_timeにもこれを代入しておかないとround_up()が正常に出来なくて困る。
- minimumTime = optimumTime = maximumTime = limits.rtime + (int)prng.rand(limits.rtime * 2);
+ remain_time = minimumTime = optimumTime = maximumTime = limits.rtime + (int)prng.rand(limits.rtime * 2);
・それでもまだ強そう..わけわからん…。タイマーの判定の問題とかありそうだが…。
56.6%
#117
やねうら王classic-tce V248a
tce版, 1スレッド、0.1秒設定
#0
やねうら王classic V238
mate1ply()修正, 1スレッド、0.1秒設定
703-100-540(0.0% R45.8)
■ 2016/04/04 V2.47
・singular率、表示させてみる。
・check_time()に統計情報を表示するためのdbg_print()追加する。
// singular extentionが生じた回数の統計を取ってみる。
dbg_hit_on(extension == ONE_PLY);
とか書くと1秒ごとに統計情報が表示されるようになった。これは便利。
Value rBeta = ttValue - 8 * depth / ONE_PLY;
においてsingular率は10%程度のようだ。
なんでこれで意味ないんやろか…。わけわからん…。
・定跡抜けたところでいきなり悪くなってる局面ありすぎ。なんなの、この定跡。
定跡の指し手、16手ぐらいまでにすべき。
・最小思考時間設定1秒において、Time.minimum()の値がマイナスになっている？修正。
・ minimumを間違えて minimalって書いてたの修正。
・MinimumThinkingTimeの最小値を1000に変更。
・合ってた。Options[".."] = "1000"; って書くとboolの代入になるのか…なにこれ。
Options[".."] = std::string(1000);
って書かないといけない。マジか。なんなのこれ。
怖いからコピーコンストラクタ追加しておく。
Option& operator=(const char* ptr) { return *this = std::string(ptr); };
・singular extensionもっと原因を調べる
・singular率 以下のようにした場合20%程度。
- Value rBeta = ttValue - 8 * depth / ONE_PLY;
+ Value rBeta = ttValue - 2 * depth / ONE_PLY;
正しく動いているようだが…。
・floodgate、NetworkDelay2 = 1000ぐらいにしないと切れ負けする。なにこれ。
■ 2016/04/04 V2.46
・go ponderなのにbestmove返してる…。修正。
position startpos moves 7g7f 1c1d 2g2f 7a6b 3g3f 8c8d 2f2e 4a3b 3i4h 8d8e 8h7g 3c3d 7i8h 6c6d 2e2d 2c2d 2h2d 6b6c 6i7h 6c5d 2d3d P*2h 3d2d 2h2i+ 2d2i 2b7g 8h7g 3a2b 5i6h 9c9d P*2d 4c4d B*2c 3b3c 2c5f+ 4d4e 5f6f B*5e 6f5f 6d6e 5f5e 5d5e 2d2c+ 3c2c B*4c 2a1c 4c6e+ 5e4d 6e6f 2c3c P*2c 2b3a 4g4f B*5d 4i3h 4e4f 3h3g 8b6b 3g4f 8e8f 8g8f 6b6f 7g6f B*3h 2i3i 3h2g+ 2c2b+ 3a2b 4f5e 4d5e 6f5e 5d3f S*4g P*3h 4g3f 2g3f 3i2i P*2h 2i2h P*2f 2h3h P*3g 4h3g 3f4g 3h3i N*6e 5e6f 1c2e 3g2f S*3h B*9f 7c7d 3i5i 8a7c 6h7i 4g4h 9f7d G*3a R*8a 4h5i 7d6c+ 5a4b 2f2e 4b3b P*3d R*2i 8a8b+ 3b2a 3d3c+ 5i1e 7i8h 1e3c P*3d 3c6f 6g6f P*3b N*4c 2i2e+ 4c3a+ 2b3a 3d3c+ S*5b 6c5b 6a5b 8b5b S*2b B*4c 2b3c 4c2e+ P*8g 8h8g N*9e 8g9h B*4e R*6a 4e3d 2e3d 3c3d
go ponder btime 0 wtime 38000 byoyomi 10000
if (!Limits.mate
&& bestValue >= VALUE_MATE_IN_MAX_PLY
&& (VALUE_MATE - bestValue) * 2 < rootDepth)
- Signals.stop = true;
+ break;
■ 2016/04/04 V2.45
・floodgateに投入している版、time upで負けた。
勝ちを読みきっているが、将棋所の表示が追いつかずに、将棋所がフリーズしていて、その間の時間ロスで
負けてる感じ。これはひどい。
mateを読みきったとき、そのmateの倍以上、iterationを回しても仕方ないのでは…。
position startpos moves 2g2f 4a3b 7g7f 8c8d 2f2e 8d8e 6i7h 8e8f 8g8f 8b8f 2e2d 2c2d 2h2d P*2c 2d2f 8f8b P*8g 7a7b 3i3h 3c3d 1g1f 7c7d 3g3f 7b7c 3h3g 7c6d 4i3h 8a7c 5i5h 6a7b P*2d 2c2d 2f2d 5a5b 3g4f 8b8a 1f1e P*2c 2d3d 2b8h+ 7i8h 4c4d 8h7g 2a3c 3d4d 3a4b P*2d 4b4c B*1f P*3d 4d3d 4c3d 1f3d 5b6b 2d2c+ 3b2c 3d2c+ R*2e P*2g 2e2c S*3d 2c2a 3d3c+ P*2f 2g2f 2a2f G*2g 2f2d P*2f 6d6e 2i3g P*8h 7h8h 7c8e 3g4e 8e7g+ 8i7g 6e5d N*6e 5d4e 4f4e 6c6d 3c3d 2d2b 3d4c 6d6e N*6d 6e6f 6g6f S*6g 5h4h N*7c 6d7b+ 6b7b 4c5c N*7a 1e1d B*6d 1d1c+ 2b2a 1c1b 2a4a 1b1a 4a4e L*8f 8a8f 8g8f 6d5c S*5d S*5i 4h3i S*4h 3i2i L*3g 2g3g 4h3g+ 3h3g 5c2f R*2b N*6b 2b2f+ G*2e L*8d P*8b B*3d 7b8a 5d6c+ 7a6c 3d6a+ S*7a
go btime 0 wtime 0 byoyomi 10000
・秒読み10秒として、
9.4秒で指すけど、切れ負けの瞬間でないなら、X.8秒ぐらいまで思考するのは有りなのでは…。
NetworkDelayMinとNetworkDelayMaxみたいな感じで前者として200、後者として600を指定する、みたいな？
NetworkDelay : 通信時の平均遅延時間[ms]
これを例えば200に設定しておくと、4.2秒で指さずに、4.8秒(200ms早め)まで考えるようになります。
NetworkDelay2 : 通信時の最大置換時間[ms]
これを例えば600に設定しておくと秒読み10秒で、切れたら負けという瞬間に限り、9.4秒(600ms早め)に指し手を返します。
こう変更する。
・exeフォルダにclassic-tce関連のファイル追加。
・goでrtimeが指定されているときにbyoyomiを設定するのまずいのか..修正。
・
> test timeman
そこそこうまく動いているように見える。
もっかいfloodgateに投入しておく。
・詰まされている形でiteration回し過ぎ。
if (!Limits.mate
&& bestValue <= VALUE_MATED_IN_MAX_PLY
&& (bestValue - (-VALUE_MATE)) * 3 > rootDepth)
Signals.stop = true;
■ 2016/04/04 V2.44
・あるところから思考時間が倍になったときのレーティング上昇がゆるやかになっていくだろうから、
持ち時間が長い場合、ponderとか時間制御とかが勝率に及ぼす影響は軽微になっていくはず。
・時間制御うまく動いてるなら、classic-TCE版として別途公開するか。
・TCEでR100上がったとしてR3170ぐらいなのか…。評価関数に手番がない分だけ低そう。R70ぐらい損しているのかな。
そして、TCEでR100も上がってなさげ…。
8-3-14
9-1-12
5-1-13
4-1-3
1-0-11
3-0-5
------
58-6-88 0.65%
AperyTwigでR3250ぐらいなので計算合うな。手番入れるとR50-70ぐらい上がるということで…。
・持ち時間制御のハイパーパラメーター、実験で改善するのはちょっときついような。
短い持ち時間だと正確ではないし、定跡の質にも左右されるし…。
定跡部もう少し作ってからにする。
・将棋所でhangしていたログ
<1:readyok
>1:usinewgame
>2:usinewgame
>1:position startpos
>1:go btime 480000 wtime 480000 byoyomi 0
<1:info pv 4g4f 4c4d (0.00%) score cp 0 depth 32
<1:info pv 4i5h 8c8d (0.00%) score cp 0 depth 32
// omit
<1:bestmove 3g3f
>2:position startpos moves 3g3f
>2:go btime 479000 wtime 480000 byoyomi 0
<2:info depth 22 seldepth 23 score cp -2162 nodes 4302298 nps 15875638 time 271 pv G*3c 2c3c 3b3c 1d2e 3c8h 4e4f P*4d 4f4g+ 4d4c+ 2f2g 8h3c 1g2f 4c4d 3e4d 3c4d 2f4f 5c5d G*4e 4d5c 4f5f 5c8f 5f8f
<2:info depth 23 seldepth 26 score cp -2069 lowerbound nodes 7153667 nps 1405988 hashfull 30 time 5088 pv 1b2c+
前の探索が終わってない感じ？
>2:position startpos moves 7g7f 8b5b 3i4h 5c5d 5i6h 5a6b 6h7h 3c3d 8h2b+ 3a2b 9g9f 6b7b 7h8h 2b3c 7i7h 7b8b 9f9e 9a9b 4h5i 8b9a 5i6h 7a8b 6g6f 4a5a 2g2f 3c4d 2f2e 4d3e B*4e 5b3b 4e5d 5a5b 5d4e 4c4d 4e5f 2a3c 2e2d 3e2d 5f3d 3b2b 4i5h 6a7a 4g4f 5b5c 3d6g 5c4c 6h7g 2d2e 8g8f 2c2d 2h4h B*2g 4f4e 2g4e+ 6g4e 3c4e P*4f 4e3g+ 2i3g 2e2f B*6e B*5d 6e5d 4c5d B*3c 2b3b 3c1a+ 3b3g+ 1a2a 5d5c N*9d 9c9d 9e9d P*9f L*9c 8a9c 9i9f N*8d 9f9e P*5f 9d9c+ 9b9c 9e9c 8b9c L*9e P*9d N*8e L*9b 2a6e 9c8b 6e5f N*6d P*9c 9b9c 5f8c 8d7f 8h9h L*9b 8e9c+ 9b9c P*9b 9a8a L*8e 9d9e 8c9c L*9f L*9g 8a7b 8e8b+ 7a8b 9c8b 7b8b 9b9a+ 9f9g+ 8i9g L*9f L*8e 8b7b S*8g N*7e P*7d 7e8g+ 7h8g 3g4h 8e8c+ 7b8c N*7e 8c7b 5h4h 9f9g+ 9h9g R*9i L*9h 9i6i+ R*9b L*8b 7d7c+ 7b7c P*7d 7c7d G*6e 7d7c P*7d 7c6b 9b8b+ 6b5a 8b8a 5a4b 8a9b 4b3c 9b9e B*5i 7d7c+ 5i7g+ 9g9f 7g8g 9f8e 6i1i 7e6c+ 5c6c 7c6c S*8c 8e7e P*6b 6c7c P*9d 9e8e S*8d 8e8d 8c8d 7e8d R*6h 6e5d 6h4h+ S*4c 3c2c G*1f 4h4f S*3b 2c1d 4c3d G*2b 1f2f 4f2f L*1f 2f1f 1g1f 1i1f R*4b B*6g 3b4c S*3c 4b6b+ 3c3d 6b2b G*2c 2b5b 8g8f 8d9c 3d3e 6f6e P*3f 6e6d 3f3g+ 6d6c+ 1d2e 9c9b 7f8h+ 4c3b G*3c P*8d 8f7f 8d8c+ 3c3b N*2i S*2h P*1g 2h1g+ S*5f 6g5f+ 5g5f 3b3c 2i1g 1f1g P*4c S*4e 5d5c 8h9h 4c4b+ S*3d B*4a L*2f 4b3b L*5a 5b5a 3c3b L*7h 7f6e 6c6d 6e6d 4a3b+ 9h8h G*5e 6d8f 7h7d 2f2h+ 9b8a 2e2f 5e4e 4d4e S*1b G*3c 1b2c 3c2c S*1b S*1d
>2:go ponder btime 105000 wtime 149000 byoyomi 0
<1:bestmove S*1d
>1:gameover draw
>2:gameover draw
<2:info depth 20 seldepth 20 score cp -2196 nodes 1310050 nps 600389 hashfull 13 time 2182 pv 1b2c+ 1d2c 3b5d 2f2g G*3c 2g3h G*4d S*2e 4d4e 3d4e 5d4e G*3d 4e5e 3e4d 3c3d 4d5e 3d2c 5e4d 2c2d 8h8g 2d2e
ponder中に引き分けが確定したときにgameover drawが送られてくるが、これに対して探索が終了していないのか。
USIではgameoverの前にstop送らなくて良いことになっているのか…。
修正。
+ if (token == "quit" || token == "stop" || token == "gameover")
・AperyTwigの評価関数portingしてくるのは、あとにしよう。5月の選手権終わったら新しいバイナリが公開されるかも知れないし。
・twig-engine名前変えよう。classic-tce-engineに変更。
■ 2016/04/04 V2.43
・USI拡張コマンド.txtの説明間違っていたの色々修正。
・やねうら王classic、floodgate、6コアPCにてR3072。もう少し放流しておく。あとで正式に公開する。
・ponderが解除された瞬間、elapsed > Time.maximum()の条件を満たすのか…。修正。
・USI_Ponder、設定項目じゃないから要らないのか。そうか…。
- // ponder設定。
- o["USI_Ponder"] << Option(false);
・思考エンジン側からponderモードなのかどうかの判定が出来ないのか…。UCIなら問題ないのに…。
仕方ないのでLimitsにponder_modeを追加。
・時間の使い方のうまい下手を調整するには自己対戦フレームワークで消費時間の処理が出来ないといけないのか…。そうか…。
その部分の改造を考える。
・詰みの局面、ponderhitしたときに指し手返さないのおかしい。
position startpos moves 5i6h 8c8d 6h7h 8d8e 7i6h 8e8f 8g8f 8b8f P*8g 8f8b 7g7f 7a6b 3i3h 7c7d 3g3f 6b7c 3h3g 7c6d 6h7g 3c3d 3g4f 7d7e 7f7e 5a4b 7g6f 3a3b 3f3e 3d3e 2h3h 3e3f 3h3f 6a5b P*3d P*8f 8g8f 8b8f P*8g 8f7f 7h6h P*8f 6i7h 7f7h+ 6h7h 6d7e R*7a 8f8g+ 7h8g G*7f 8g7h P*8f 7h6h 8f8g+ 6h5h 8g8h 6f7e 8h8i 7a8a+ B*1d 3d3c+ 3b3c N*3d 3c3d 3f3d P*3a 3d7d 2b9i+ S*6a N*5d 6a5b+ 4a5b 4f4e 7f6g 5h6g 1d4g+ 7d7a+ S*6f 6g7f 6f7e 7a7e P*7d S*3c 9i3c G*4a 4b3b 4a3a 3b2b 3a2a 2b1b G*2b 3c2b 2a2b 1b2b B*3c 2b3c 8a3a P*3b 4e4d 4c4d 7e3e B*3d S*2b 3c4c N*5e
go ponder btime 127000 wtime 49000 byoyomi 0
ponderhit
+ // 詰みの局面が"ponderhit"で返ってくることがあるので、ここでのpv[0] == MOVE_RESIGNであることがありうる。
+ if (!is_ok(pv[0]))
+ return false;
→ 修正した。
・ponder有効にしてランニングさせておく。
・切れ負けルールのときに長考するのまずいな。
float max_ratio = 5.0f;
// 切れ負けルールにおいては、5分を切っていたら、このratioを抑制する。
if (limits.inc[us] == 0 && limits.byoyomi[us] == 0)
{
// 3分 : ratio = 3.0
// 2分 : ratio = 2.0
// 1分以下 : ratio = 1.0固定
max_ratio = std::min(max_ratio, std::max(float(limits.time[us])/(60*1000),1.0f));
}
int t2 = minimumTime + remain_estimate * max_ratio / MTG;
・Timer回すから、Limits.startTimeって要らないのでは…。Stockfishの設計もこの部分おかしい。
→ 削除した。
・ponderhitしたときの思考時間がおかしい。
position startpos moves 2g2f 5a4b 2f2e 4b3b 7g7f 3c3d 2e2d 2c2d 2h2d 2b8h+ 7i8h 3a2b 2d3d 2b3c 3d3f P*2c 5i6h B*2g 3i3h 2g3f+ 3g3f 7a6b 2i3g R*2f 4i3i 2f3f 8h7g 3c4d 3i2h 3f3e B*4f 3e8e 8g8f 8e9e 3h2g 8c8d 9g9f 9e6e B*5f 6e6d 4f6d 6c6d 2g3f B*7d 4g4f 7d5f 5g5f 4d3c P*3d 3c2b 3g2e 6a5b 2h3h 8d8e 8f8e 7c7d 3h4g 5b4b B*6f B*4d 6i7h 4d6f 6g6f B*3h 8e8d 8b8d 6h7i 8d8b P*8c 8b8c P*8g 3h2i+ B*5e 2i1i 5e6d L*8d 7i8h P*3e 3f3e 1i2i 6d9a+ 2i4g L*3c 4b3c 3d3c+ 2b3c 2e3c+ 2a3c P*3d G*6g 3d3c+ 3b3c 9a5e 3c4b N*8f 6g7h 8h7h
go ponder btime 199000 wtime 113000 byoyomi 0
ponderhit
- const int MoveHorizon = 70;
+ const int MoveHorizon = 80;
// goコマンド、デバッグ時に使うが、そのときに"go btime XXX wtime XXX byoyomi XXX"と毎回入力するのが面倒なので
// デフォルトで1秒読み状態で呼び出されて欲しい。
+ if (limits.byoyomi[BLACK] == 0 && limits.inc[BLACK] == 0 && limits.time[BLACK] == 0)
limits.byoyomi[BLACK] = limits.byoyomi[WHITE] = 1000;
条件間違ってた。切れ負けを、秒読み1秒と解釈してた。
・以上の修正をして5分切れ負け、ponder有りでclassicと対戦させておく。
・floodgateにclassicのTCE(Time-Control Enabled)版として放流しておく。
6スレッド、narrow book、ponder有り。hash = 4096MB。
■ 2016/04/03 V2.42
・将棋ではstopOnPonderhit自体がおかしい。ponderhitしても2秒は思考したほうが良いのだから…。
- // 思考は終了しているからponderhitが送られてきたらSignals.stopをtrueにして欲しいときに使う。
- std::atomic_bool stopOnPonderhit;
- // 一応、思考はいつ止めても良いのだが、キリの良い時間(最小思考時間を超えた瞬間だとか、
- // ちょうど一秒として計測される手前とか)になったら停止させたいの意味。
- std::atomic_bool weak_stop;
/*
// もしponder中であるなら、ponderhitが来れば停止。
if (Limits.ponder)
Signals.stopOnPonderhit = true;
else
Signals.stop = true;
*/
・check_time()で統計情報みたいなのを出力する機能、要るかなぁ…。
#if 0
static TimePoint lastInfoTime = now();
int elapsed = Time.elapsed();
TimePoint tick = Limits.startTime + elapsed;
// 1秒ごとにdbg_print()を呼び出して統計情報などを出力する用。
if (tick - lastInfoTime >= 1000)
{
lastInfoTime = tick;
dbg_print();
}
#endif
・ponderhitまわり、きちんと書けた(気がする)
それにしてもStockfishのコード、相変わらずバグっていて、ponderhit待ちになった瞬間にponderhitすると(極めてレアケースだが)
ハングするような…。このコード、2年も経つのにまだなおってないのか…。
・ponder、独自にやっても将棋所がponderの局面を送ってこない…。そうか…。
■ 2016/04/03 V2.41
・やねうら王twig、タイマースレッドの廃止。
・Timerクラス、reset()とinit()と分ける。
従来のinit()→reset()
init()→理想的な思考時間を得るためのTimeManger。
・config.hにUSE_TIME_MANAGEMENT追加
・benchコマンド時に2個目以降の局面で正しくnpsが表示されなかった問題を修正。
・解説.txtに書いてなかったファイルの説明追加。
・TimeManagerのテスト用のコマンドを追加
> test timeman
→ そこそこうまく使っているように見える。
■ 2016/04/03 V2.40
・やねうら王classicは開発終了。6コア時、floodgateでR3000を超えているようだったので。
・やねうら王classic、exe/フォルダに放り込む。
・やねうら王classic、exe/フォルダにreadme追加。
・やねうら王twigにfork。
・やねうら王twigにponder機能入れるための準備。
・singular延長で強くなるのは、あるnodeで1手だけが特別に良い場合、相手のプレイヤーもそのnodeでは
その指し手を選択する可能性が高く、それゆえ、相手のPVもそこである可能性が高いから、そこを相手よりわずかにでも
読んでいて詰みを回避などできるなら、その相手に対する勝率は上がるという理屈。
いわば、0.5手延長が自己対戦で(のみ)強くなるのの拡張。
そう考えるとベストな指し手のスコアと2番目にベストな指し手のスコアとの差に応じて1手延長するのが正しいのだが、
2番目にベストな指し手のスコアを小さなコストで求めることは出来ないので…。
・Positionのkey()まわりの名前が気持ち悪い。
board_key()とかのほうが良いのでは…。
→ せっかくなので全部変更する。
■ 2016/04/03 V2.38 classic版final
・mate1ply修正。(thx.tさん)
const uint8_t long_effect8_table[PIECE_NB] = {
0,0,DIRECTIONS_U/*香*/,0,0,BISHOP_DIR/*角*/,ROOK_DIR/*飛*/,0,0,0,0,0,0,BISHOP_DIR/*馬*/,ROOK_DIR/*龍*/,0, // 先手
0,0,DIRECTIONS_D/*香*/,0,0,BISHOP_DIR,ROOK_DIR,0,0,0,0,0,0,BISHOP_DIR,ROOK_DIR,0, // 後手
};
inline Directions long_effect_of(Piece pc) { return (Directions)long_effect8_table[pc]; }
追加。mate1ply()では、long_effect16_of()ではなく、こちらを呼び出すように修正。
修正前
> test rp
Random Player test , loop_max = 100000000
mate found = 10000 , mate miss = 747 , mate found rate = 93.0492%
mate found = 20000 , mate miss = 1471 , mate found rate = 93.1489%
mate found = 30000 , mate miss = 2201 , mate found rate = 93.1648%
mate found = 40000 , mate miss = 2969 , mate found rate = 93.0904%
mate found = 50000 , mate miss = 3792 , mate found rate = 92.9506%
mate found = 60000 , mate miss = 4659 , mate found rate = 92.7945%
mate found = 70000 , mate miss = 5444 , mate found rate = 92.7841%
mate found = 80000 , mate miss = 6270 , mate found rate = 92.7321%
mate found = 90000 , mate miss = 6959 , mate found rate = 92.8227%
mate found = 100000 , mate miss = 7754 , mate found rate = 92.804%
修正後
> test rp
Random Player test , loop_max = 100000000
mate found = 10000 , mate miss = 745 , mate found rate = 93.0665%
mate found = 20000 , mate miss = 1460 , mate found rate = 93.1966%
mate found = 30000 , mate miss = 2180 , mate found rate = 93.2256%
mate found = 40000 , mate miss = 2937 , mate found rate = 93.1597%
mate found = 50000 , mate miss = 3755 , mate found rate = 93.0146%
mate found = 60000 , mate miss = 4612 , mate found rate = 92.862%
mate found = 70000 , mate miss = 5379 , mate found rate = 92.8641%
mate found = 80000 , mate miss = 6197 , mate found rate = 92.8107%
mate found = 90000 , mate miss = 6876 , mate found rate = 92.9023%
mate found = 100000 , mate miss = 7665 , mate found rate = 92.8807%
詰み発見率が0.1%弱増加
50.5%
#115
やねうら王classic V238
mate1ply()修正, 1スレッド、0.1秒設定
#0
やねうら王classic V237
nonPVのreduction調整, 1スレッド、0.1秒設定
767-141-753(36.0% R3.2)
■ 2016/04/02 V2.37
・singularのテスト
bool singularExtensionNode = !RootNode
+ && depth >= (param1 + 2)*2 * ONE_PLY // 8 * ONE_PLY
singularの条件を調べる。param1 = 0..3で。
35.8% 44.6% 43.9% 51.4%
#114
やねうら王classic V237b
singularの調整, 1スレッド、0.1秒設定
#0
やねうら王classic V237
nonPVのreduction調整, 1スレッド、0.1秒設定
343-83-614(100.0% R-101.1) 346-96-430(99.9% R-37.8) 325-92-415(100.0% R-42.5) 392-69-371(21.3% R9.6)
depth >= 10 * ONE_PLY
のときにはわずかに効果がありそうだが、効果が乏しすぎるので怪しい。
何か他の条件がおかしいのかも。
singularについては、もう少し他の部分を作りこんでからさらにテストすべき。
■ 2016/04/02 V2.36
・non PV時のreduction調整。
0.1ずつ 動かしてみる。
double K[][2] = { { 0.799 + (param2-1)*0.1 , 2.281 + (param1 - 1)*0.1 },{ 0.484 + 0.1 , 3.023 + 0.05 } };
param1,2 = 0..2の範囲で。
・position sfen 3S+R+P3/3R1K+P+LP/1gp1+B+P2+P/p2+b2gS1/g8/1P1kp4/P2+p2n+p1/7+s1/+p1+l1+s4 b 5P2L3NG 245
49.7% 48.9% 51.4%
50.8% 49.5% 51.2%
49.2% 50.7% 50.1%
#112
やねうら王classic V236
nonPVのreduction調整, 1スレッド、0.1秒設定
#0
やねうら王classic V235
宣言勝ち, 1スレッド、0.1秒設定
647-155-654(57.7% R-1.9) 639-149-668(78.9% R-7.7) 686-121-649(15.6% R9.6)
671-134-651(29.1% R5.3) 655-119-669(65.0% R-3.7) 583-110-555(20.3% R8.6)
546-138-564(70.5% R-5.6) 577-109-562(32.8% R4.6) 575-101-572(46.5% R0.9)
param1 = 2 , param2 = 0が最適。
double K[][2] = { { 0.799 - 0.1 , 2.281 + 0.1 },{ 0.484 + 0.1 , 3.023 + 0.05 } };
・local server、よく考えたらbestmove winのwinをparseできてない可能性が…。
+ if (str == "win")
+ return MOVE_WIN;
あらら。ということは、入玉宣言で強くなったと思っていたのは間違っていた…。
■ 2016/04/02 V2.35
・入玉宣言勝ちまわりの処理
・MOVE_WIN追加
・extra/entring_king_win.cpp追加。
・local-server、入玉判定に対応。
・mate1ply()で宣言勝ちを1手詰めの指し手として返すように。
#ifdef USE_ENTERING_KING_WIN
// 宣言勝ちであるならそれを1手詰めの指し手として返す。
return DeclarationWin();
#else
→ mate1ply毎nodeで呼ばないから、これは良くない。
classicで、宣言勝ち、毎node調べるように変更。
・入玉宣言勝ちのテスト
position sfen Kn1g1gsnl/+Pl7/2ppppppp/9/9/9/P+p+p+p+p+p+p+p+p/3g1+bs+rk/+l+nsg2+s+n+l w rbp 1
宣言勝ちを含むmate 3
position sfen K+N+S3+S+N+L/+P+R5+B1/1+P+P+Pppppp/9/9/2P6/PPBPPPPPP/9/LNSG1GSNk b RL2gl 1
position sfen +L2+B+B+R+L1+P/6+P2/p2K+P1S+L1/5p2g/5g3/2S3+rk1/PP1P2+p2/3+p1P1g+n/LN2+p1+p2 b 3P2NS2psg 247
・classicでrootで1手詰め判定を呼び出すように変更。
・3駒のテーブル、コンバート間違えてた件で、読み込み時に変換するために
確保している配列、動的に確保するように変更。(メモリがもったいないため)
・宣言勝ちによって勝率が変わっているかどうか調べる。
いままで宣言勝ちを逃していた局面において効果が出るはず…。
V2.35 vs V2.34b
52.3%
#111
やねうら王classic V235
宣言勝ち, 1スレッド、0.1秒設定
#0
やねうら王classic V234b
captureのオーダリング修正, 1スレッド、0.1秒設定
482-83-440(7.8% R15.8)
■ 2016/04/02 V2.34
V2.34a
・evasionのorderingで、駒を打つのをSEE<0なのにゼロ扱いしているのはさすがにおかしいな。
ただで取られるところへの合駒をしている指し手とかがあるわけで…。
- // 駒を打つ指し手であるならゼロ扱い
- if (is_drop(m))
- m.value = VALUE_ZERO;
V2.34a vs V2.34
199-44-192(+R6.2)
ほぼ変わらず。レアケースなので影響はほぼ無いのか？
V2.34b
・captureのorderingも、歩のとき、成り + 捕獲する駒の値になっているほうが良いな…。
m.value = (pawn_promo ? (Value)(Eval::GoldValue - Eval::PawnValue) : VALUE_ZERO)
+ (Value)Eval::PieceValueCapture[pos.piece_on(move_to(m))];
これもレアケースなので勝率に影響はなさげ。
51.8%
#110
やねうら王classic V234b
captureのオーダリング修正, 1スレッド、0.1秒設定
#0
やねうら王classic V234
reduction定数調整後, 1スレッド、0.1秒設定
780-154-725(7.8% R12.7)
そこそこ上がってた。
■ 2016/04/01 V2.33
・MovePickerにfollowupのhistory追加。
const CounterMoveStats* followupMoveHistory;
→ nano plusのほうは、まあ、コンパイル通るだけでいいや。
・followupのhistoryに基いてquietの指し手のオーダリングを行なう。
score_quiet()
m.value = history[move_to(m)][pos.moved_piece(m)]
- + (*counterMoveHistory)[move_to(m)][pos.moved_piece(m)];
+ m.value = history[move_to(m)][pos.moved_piece(m)]
+ + (*counterMoveHistory) [move_to(m)][pos.moved_piece(m)]
+ (*followupMoveHistory)[move_to(m)][pos.moved_piece(m)];
・これに伴い、update_stats()も修正。
V2.33 vs V2.30
231-30-236
→ ほぼ互角
V2.33a
・LMRのreduction tableの定数をStockfishに倣う。
double r = log(d) * log(mc) / 2;
if (r < 0.80)
continue;
reduction_table[NonPV][imp][d][mc] = int(std::round(r)) * ONE_PLY;
reduction_table[PV][imp][d][mc] = std::max(reduction_table[NonPV][imp][d][mc] - ONE_PLY, DEPTH_ZERO);
V2.33a vs V2.30
186-22-236
-R41
他のパラメーターが以前のreduction tableの値に依存しているのでここだけ変えても逆効果のようだ。
もうちょっと調整頑張る。
・Stockfishのreductionのテーブル、おかしいな。
> template <bool PvNode> Depth reduction(bool i, Depth d, int mn) {
> return Reductions[PvNode][i][std::min(d, 63 * ONE_PLY)][std::min(mn, 63)];
> }
return Reductions[PvNode][i][std::min(d / ONE_PLY, 63 )][std::min(mn, 63)];
こうが正しい。
V2.33b
・reduction定数、grid searchしてみる。
double r = log(d) * log(mc) / (1.25 + param1 * 0.25);
として、param1 = 0..6ぐらいで。
いやー、grid search、こうやるか。
double r = (param2 * 0.25) + log(d) * log(mc) / (1.25 + param1 * 0.25);
param2 = 0..4
38.2% 35.5% 46.4% 35.2% 38.3% 41.8% 49.2%
31.6% 46.4% 36.8% 40.2% 38.1% 43.0% 37.6%
28.7% 34.4% 39.7% 44.1% 35.9% 37.8% 41.6%
26.2% 44.0% 39.5% 42.4% 41.0% 38.1% 36.9%
29.4% 31.7% 37.9% 42.7% 43.4% 37.6% 42.5%
#104
やねうら王classic V233b
reduction定数調査用, 1スレッド、0.1秒設定
#0
やねうら王classic V230
新標準, 1スレッド、0.1秒設定
73-17-118(100.0% R-83.4) 70-11-127(100.0% R-103.5) 89-16-103(86.1% R-25.4) 68-15-125(100.0% R-105.8) 75-12-121(100.0% R-83.1) 76-26-106(98.9% R-57.8) 96-13-99(61.3% R-5.3)
62-12-134(100.0% R-133.9) 90-14-104(85.9% R-25.1) 70-18-120(100.0% R-93.6) 76-19-113(99.7% R-68.9) 75-11-122(100.0% R-84.5) 83-15-110(97.8% R-48.9) 74-11-123(100.0% R-88.3)
56-13-139(100.0% R-157.9) 65-19-124(100.0% R-112.2) 79-9-120(99.9% R-72.6) 86-13-109(95.7% R-41.2) 70-13-125(100.0% R-100.7) 73-15-120(100.0% R-86.3) 79-18-111(99.2% R-59.1)
50-17-141(100.0% R-180.1) 85-15-108(95.8% R-41.6) 77-13-118(99.9% R-74.2) 81-17-110(98.5% R-53.2) 82-8-118(99.6% R-63.2) 72-19-117(100.0% R-84.3) 73-10-125(100.0% R-93.4)
57-14-137(100.0% R-152.3) 63-9-136(100.0% R-133.7) 75-10-123(100.0% R-85.9) 82-16-110(98.2% R-51.0) 82-19-107(97.1% R-46.2) 71-19-118(100.0% R-88.2) 71-18-96(97.8% R-52.4)
param1が6だと1.25+6*0.25 = 2.75。以前のがPVのときに3で割っていたので、もうちょっと大きくないといけなかったのか。
V2.33c
double r = (param2 * 0.1) + log(d) * log(mc) / (2.70 + param1 * 0.1);
とりあえずparam1 = 0..4ぐらいであたりをつけるか。
42.8% 44.7% 38.8% 34.4%
#105
やねうら王classic V233c
reduction定数調査用, 1スレッド、0.1秒設定
#0
やねうら王classic V230
新標準, 1スレッド、0.1秒設定
83-14-111(98.1% R-50.5) 88-11-109(94.2% R-37.2) 78-7-123(99.9% R-79.1) 62-12-118(100.0% R-111.8)
param==1が最適みたいだけど、PV時とnonPV時と分かれてないのでパラメーターの調整が困難。
これに変えるぐらいなら以前のコードでパラメーターの調整をしたほうがよさ気。
V2.33d
元のコードに対してPV時に0.1ずつ動かして調整してみる。
double K[][2] = { { 0.799, 2.281 },{ 0.484 + (param2-1)*0.1 , 3.023 + (param1-1)*0.1 } };
param1,2 = 0..2で。
48.4% 45.4% 45.6%
51.1% 48.3% 45.2%
44.5% 51.5% 52.1%
#106
やねうら王classic V233d
reduction定数調査用, 1スレッド、0.1秒設定
#0
やねうら王classic V230
新標準, 1スレッド、0.1秒設定
184-39-196(74.8% R-11.0) 171-39-206(96.8% R-32.3) 175-32-209(96.3% R-30.8)
201-23-192(30.7% R8.0) 189-25-202(76.1% R-11.6) 175-29-212(97.3% R-33.3)
171-32-213(98.6% R-38.2) 201-26-189(25.5% R10.7) 201-30-185(19.3% R14.4)
param1 = param2 = 2がベストっぽい。
V2.33e
・もう少し細かくしてみる。
double K[][2] = { { 0.799, 2.281 },{ 0.484 + 0.1 + (param2-1)*0.05 , 3.023 + 0.1 + (param1-1)*0.05 } };
param1,2 = 0..2で。
勝率が低いのは、0.1秒だとこのテーブルの初期化に要する時間が無視できないからかも。
47.5% 49.9% 45.9%
52.6% 50.7% 49.1%
48.7% 47.9% 51.6%
#107
やねうら王classic V233e
reduction定数調査用, 1スレッド、0.1秒設定
#0
やねうら王classic V230
新標準, 1スレッド、0.1秒設定
364-65-403(92.6% R-17.7) 385-61-386(52.9% R-0.5) 360-48-424(99.0% R-28.4)
409-55-368(6.6% R18.4) 387-68-377(34.5% R4.5) 379-60-393(70.5% R-6.3)
380-51-401(78.4% R-9.3) 372-55-405(88.9% R-14.8) 380-57-357(18.8% R10.8)
Param1 = 0,Param2 = 1で最大。
double K[][2] = { { 0.799, 2.281 },{ 0.484 + 0.1 + (1-1)*0.05 , 3.023 + 0.1 + (0-1)*0.05 } };
double K[][2] = { { 0.799, 2.281 },{ 0.484 + 0.1 , 3.023 + 0.05 } };
ゆえに、こう変更しておくる
■ 2016/04/01 V2.32
・やねうら王classicの探索部、もう少し調整する。
singluar extensionのパラメーター調整する。
else if (singularExtensionNode
&& move == ttMove
+ && !extension // 延長が確定しているところはこれ以上調べても仕方がない。
&& pos.legal(move))
↑この条件忘れてた。
Value rBeta = ttValue - (param1 + 1) * depth / ONE_PLY; // margin = 2 * depth / ONE_PLY
今日は、param1 = 0..9でひたすら回しておく。
44.9% 44.0% 43.5% 45.5% 46.9% 49.5% 48.0% 49.7% 48.1% 50.3%
#100
やねうら王classic V232
singularのテスト, 1スレッド、0.1秒設定
#0
やねうら王classic V230
新標準, 1スレッド、0.1秒設定
263-38-323(99.4% R-35.7) 253-49-322(99.8% R-41.9) 253-42-329(99.9% R-45.6) 189-40-226(96.9% R-31.1) 179-34-203(90.0% R-21.9) 190-32-194(60.1% R-3.6) 184-33-199(79.3% R-13.6) 188-38-190(56.1% R-1.8) 188-25-203(79.1% R-13.3) 190-38-188(43.9% R1.8)
どうやっても良くならない。評価関数の質が悪いのか、singularに関連する処理の何かがバグっているのか…。
singularのときにdo_move()せずにsearch()を再帰的に呼び出すと
ss->moveCountが破壊されてしまうのでmoveCountベースの枝刈りがきちんと機能しない？
→ そうでもないような…。ローカル変数にあるしな..
V2.32a
ss->skipEarlyPruning = false;
+ ss->moveCount = moveCount; // 破壊したと思うので修復しておく。
ss->excludedMove = MOVE_NONE;
これを追加して、param1 == 7固定で
Value rBeta = ttValue - (7 + 1) * depth / ONE_PLY; // margin = 2 * depth / ONE_PLY
として対戦させてみる。これであかんかったらsingularはしばらくおあずけ。
これでうまくいくなら他の値もgrid searchする。
376-68-383
-R3.2
やらないほうがマシか…。仕方ない。コメントアウトしておく。
■ 2016/04/01 V2.31
・update_stats()でのボーナス、ONE_PLYで正規化すべき。
// depthの二乗に比例したbonusをhistory tableに加算する。
- Value bonus = Value(depth*(int)depth + (int)depth + 1);
+ Value bonus = Value((int)depth*(int)depth / ((int)ONE_PLY*(int)ONE_PLY) + (int)depth / (int)ONE_PLY + 1);
V2.31 vs V2.30
250-42-250
ほぼ変わらず。
・update_stats()、1手前がNULL MOVEかどうかで場合分けしたほうがソースコードがすっきりするので修正。
・bench走らせるごとにnode数が変わるようになってしまった…。
何かやらかしている。
→ 今回の修正コメントアウトしても一致しない。
→ benchで何かクリアしていないものがあるのでは。
→ そうでもなさげ。
→ mate1も関係なさげ。
→ recaptureでスコアつけてないのにpick_best()してた。
case GOOD_RECAPTURES:
endMoves = generateMoves<RECAPTURES>(pos, moves, recaptureSquare);
+ score_captures(); // CAPTUREの指し手の並べ替え
break;
→ よし、修正できた。再度、V2.30と対戦。
■ 2016/04/01 V2.30
・Visual Studio 2015 Update2が出たので以前、内部エラーが出てコンパイルできなかったものをshogi.hに移動させる。
inline int hand_count(Hand hand, Piece pr) { ASSERT_LV2(PIECE_HAND_ZERO <= pr && pr < PIECE_HAND_NB); return (hand >> PIECE_BITS[pr]) & PIECE_BIT_MASK[pr]; }
inline int hand_exists(Hand hand, Piece pr) { ASSERT_LV2(PIECE_HAND_ZERO <= pr && pr < PIECE_HAND_NB); return hand & PIECE_BIT_MASK2[pr]; }
inline void add_hand(Hand &hand, Piece pr, int c = 1) { hand = (Hand)(hand + PIECE_TO_HAND[pr] * c); }
inline void sub_hand(Hand &hand, Piece pr, int c = 1) { hand = (Hand)(hand - PIECE_TO_HAND[pr] * c); }
→ Update2ではコンパイルできた！！
・LONG_EFFECT_LIBRARYをオフにして1手詰めをオフ、ASSERT_LV 0にするとclassicでbenchが960Knps程度。
・LONG_EFFECT_LIBRARYをオフにして1手詰めをオフ、ASSERT_LV 0にするとclassicでbenchが800Knps程度。
LONG_EFFECT、なぜにこんなに遅いのか…。evaluate()の差分計算の何かを潰している可能性すらある。
前実験したときこんな遅くなかったはず…。
benchにおけるevaluate()の全計算 / 呼びだされたい回数
109940 / 19000000
→ LONG_EFFECTありでもなしでも変わらなかった。うむむ？
例)
static u64 c1 = 0;
static u64 c2 = 0;
c1++;
if ((c1 % 100000) == 0)
cout << c2 << " / " << c1 << endl;
if (...)
{
c2++;
}
さすがにおかしい。LONG_EFFECT有りの時にどこがボトルネックになっているのかプロファイラで調べる。
LongEffect::update_by_capture..()で、先後、2%ぐらい食ってる。
このrewindでも2%。captureだけで8%。うーん。遅すぎ。rewind()やめたほうが良いのでは…。
てか、これならLONG_EFFECTなしにしてmate1なしのほうが強い可能性が…。
最終的に利きを評価関数に使いたいので、そのときは仕方ないとしても。
100-8-140
一応、long effectの分ぐらいは回収できとるのか…。そうか…。
rewind()無くすと利きのある評価関数使うときに戻すのに困るのか。なら仕方ないか…。
以前計測したときはrewind()含んでなかったのか。そうか。
・やねうら王classicのRecaptureのオーダリング考える。
V2.30a
- move = *currentMoves++;
+ move = pick_best(currentMoves++, endMoves);
どうせrecapの指し手が2つ以上あることは稀なのでここでオーダリングしてもあまり意味をなさない気もするが。
生成される指し手が少ないなら、pick_best()のコストはほぼ無視できるのでやらないよりはマシのような。
V2.30a vs V2.30
295-32-295
変わらず。
■ 2016/03/31 V2.29
・see()のコード、Position::effected_to()を使ったほうが簡潔になるのか。修正。
■ 2016/03/31 V2.28
・benchコマンドのdefaultのdepthを15に変更。
・benchコマンドで内部的にis_ready()を呼び出すように変更。
740knps // ASSERT_LV 3
775knps // ASSERT_LV 0
750knps // ASSERT_LV 3 , mate1ply()呼び出さない。
・LONG_EFFECT_LIBRARYがあるときのSEE高速化。(thx. tさん)
===========================
Total time (ms) : 32204
Nodes searched : 23523154
Nodes/second : 730441
↓
===========================
Total time (ms) : 31058
Nodes searched : 23523154
Nodes/second : 757394
2,3%ぐらい高速化した？ほぼ変わらない気もする。
see()のコード、少し整理した。
■ 2016/03/31 V2.27
・mate1ply修正。(thx. woodyringさん)
- auto cut_dirs = cutoff_directions(to_direct, long_effect.directions_of(Us, to) & (Effect8::Directions)~LongEffect::long_effect16_of(type_of(pc)));
+ auto cut_dirs = cutoff_directions(to_direct, long_effect.directions_of(Us, to) & (Effect8::Directions)~LongEffect::long_effect16_of(pc));
二箇所。
225-22-206(+R15.3)
■ 2016/03/31 V2.26
・やねうら王2015とくらべてnps2割ぐらい低くてhashの使用率が1/3ぐらいしかない。
hashまわり、何かやらかしているのでは。
・やねうら王2015、思考時間0.1秒になってなかった疑惑。
やねうら王2015 vs V2.25 , 1手3秒、1スレッド、256MBでの勝負。将棋所。
31-7-41
勝ち越しとる…。
V2.25だけ定跡使ってるのもあるのかも。
・やねうら王2015と1.7秒設定で対戦させる。
#95
やねうら王classic V225
evaluate修正, 1スレッド、1.7秒固定設定
YaneuraOu-classicV225.exe
go btime 2000 wtime 2000 byoyomi 0
setoption name Hash value 1024
setoption name Threads value 1
setoption name NetworkDelay value 300
#94
やねうら王2015
1スレッド、1.7秒固定設定
YaneuraOu2015.exe
go btime 100 wtime 100 byoyomi 0
setoption name USI_Hash value 1024
setoption name Threads value 1
setoption name TimeLimitMs value 700
setoption name MinimumThinkingTime value 1700
1-0-50
local-serverを使うと圧倒的に負け越す。なぜ？
何かがおかしい…。
btimeで指定しているから、そこ60で割り算した分しか思考時間使ってないからか。
go btime 0 wtime 0 byoyomi 10000
に変更して1手10秒固定
0-0-42
これでも圧倒的に負け。なんでだろ…。原因よく調べる。
やねうら王2015 0.1秒 vs V2.25 1秒
0-0-90
おかしい。
いくらなんでもおかしすぎる。やねうら王2015がカレントフォルダを変更するから、V2.25で評価関数が読み込めていないのか？
→ ビンゴくさい。そうか。そうだったのか…。
やねうら王2015 vs V2.25 0.1秒
→ よし、互角ぐらい。問題ない。
→ これにてやねうら王2015の作業は終了。
・historyなどのbonus、レーティングの簡易計算法のほうがいいかも…。
cf. http://www.computer-shogi.org/wcsc26/appeal/NineDayFever/NDF-2016.txt
■ 2016/03/30 V2.25
・やねうら王2015に色々portingして比較実験してみる。
・perftコマンドにEVAL_PERFTモード追加。
・isreadyコマンドに対してPosition.set(HIRATE_SFEN)で初期化するように。
・やねうら王2015にperftとEVAL_PERFT、porting完了。
・perft 3においてeval(sum)の値が一致しない。たぶん成り駒関係で何かおかしい。
あと、perftの速度が違いすぎ。evalの速度差がひどい。evaluate()で何かやらかしてる。
sfenとevalの値を書き出してcompareするか。
→ 指し手生成の順番が異なるから比較しにくい。
→ sfenでsortして調べるか…。
歩を手持ちにしている局面の評価値がおかしいことがわかった。
e.g. sfen 1nsgkgsnl/lr5b1/pppppp+Bpp/9/9/2P6/PP1PPPPPP/7R1/LNSGKGSNL w P 4
-1002
あれ？全計算において一致する。やねうら王2015の差分計算がバグっている可能性が微レ存。
違うな。やねうら王2015の全計算こそがbugっていて、これと等価になるように今回portingしたからおかしいのか。
全計算は、そのあとすべてが差分計算がなされるのであれば(相対的な比較は出来るから)bugってようが関係がないのか。そうか…。
よくこれで動いてたな。
ああ、evalで差分計算をretireしたときに、compute_eval()呼び出してないから関係なかったのか。そうか。
・なんとなくわかってきた。
BonaPieceで先手の手駒の歩1と、それを相手の駒にしたときに後手の歩1にならないといけないのに
そうなっていない。
→ eval_list自体が間違っているのか。
→ やねうら王2015のPosition::set()がバグっていた。
- st->pieceList[piece_no].fb = BonaPiece(kpp_hand_index[color][raw_piece].fb + i + 1);
- st->pieceList[piece_no].fw = BonaPiece(kpp_hand_index[color][raw_piece].fw + i + 1);
+ st->pieceList[piece_no].fb = BonaPiece(kpp_hand_index[color][raw_piece].fb + i);
+ st->pieceList[piece_no].fw = BonaPiece(kpp_hand_index[color][raw_piece].fw + i);
これにより駒番号がおかしくなっていたのか。これを基準に評価関数をコンバートしたからおかしかったのか。
ということは上の局面は-1075が正しいわけか。
・BonaPiece、後手の駒を正しく << で表示できてなかったのを修正。
・evaluate、コンバーター書く。
// 手駒の添字、コンバートするときにひとつ間違えてた。(๑´ڡ`๑)
for (int k = 0; k < SQ_NB_PLUS1; ++k)
for (int i = 1; i < fe_end; ++i)
for (int j = 1; j < fe_end; ++j)
{
int i2 = i < fe_hand_end ? i - 1 : i;
int j2 = j < fe_hand_end ? j - 1 : j;
kpp2[k][i][j] = kpp[k][i2][j2];
}
for (int k1 = 0; k1 < SQ_NB_PLUS1; ++k1)
for (int k2 = 0; k2 < SQ_NB_PLUS1; ++k2)
for (int j = 1; j < fe_end + 1; ++j)
{
int j2 = j < fe_hand_end ? j - 1 : j;
kkp2[k1][k2][j] = kkp[k1][k2][j2];
}
memcpy(kkp, kkp2, sizeof(kkp));
memcpy(kpp, kpp2, sizeof(kpp));
これ書いたら、evalぴったり合った…。
→ やねうら王2015とperft 5でevalの合計合致した。
→ perft6の合計も念のために確認する。
→ 合致していた。
・上の評価関数ファイルの読み込み時の変換、デバッグモードだと時間がかかるので新たに書きだして、更新したほうがよさげ。
次のWCSCが終わったタイミングでライブラリ更新してCSAのサイトに新しい評価関数バイナリ上げよう。
・評価関数を修正したのに、思ったほどはレーティング上がってない。
217-25-174(+R38.4)
・差分計算が出来てないケースがあるのがおかしいのか。いくらなんでもnpsが低すぎるのであとで調査する。
・あとはmate1、呼ばないほうがいい可能性も…。
・これで勝率にまだ差が開くなら、やねうら王2015の対局設定、0.1秒思考にはなっていない可能性を疑ったほうが良いのでは…。
あとで普通に将棋所を使って対局させておく。
■ 2016/03/30 V2.24
・evaluate()毎回呼ばないと差分計算できないケースがある？(thx. tさん、わるおさん)
+ // このあとnodeを展開していくので、evaluate()の差分計算ができないと困るから、evaluate()を呼び出していないなら呼び出しておく。
+ if (pos.state()->sumKKP == VALUE_NONE)
+ evaluate(pos);
変更前 bench 590knps
変更後(静止探索、通常探索に追加)
733knps
331-27-265 (+R38.6)
→ やねうら王2014では1Mnpsぐらい出ていたのでまだ何かやらかしている可能性が微レ存。
■ 2016/03/30 V2.23
・置換表格納のときにkeyのcastが間違っていた。もしかするとこれでエントリーが一致しなかったのか？
→ そうでもなさげ。強さに影響は無いみたい。
tt.h
- key16 = (int16_t)(k >> 48);
+ key16 = (uint16_t)(k >> 48);
・depth 4手浅いものより大きいなら置換表のエントリー書き換えたほうが良いのでは。比較してみる。
tt.h
- || (d > depth() - 2 * ONE_PLY) // ここ、2と4とどちらがいいか。あとで比較する。
+ || (d > depth() - 4 * ONE_PLY) // ここ、2と4とどちらがいいか。あとで比較する。
307-36-277(+R17.9)
4のほうが少しよさ気？よくわからん…。もっと回数対戦させたほうがよさ気。
一通り修正してから再度検証すべき。
・CheckInfoのupdate、段階的に出来るようにPositionクラスのcheck_info_update()修正。
classicのコード、通常探索のほう、check_info_update()が抜けるフローがあったので修正。
・classicでnull moveのときにcheck_info_update()していないの修正。
・miniでも同様。
→ リビルドしてexe/フォルダにコピー
279-25-287
(R-4.9)
ほぼ変わらず。
■ 2016/03/30 V2.22
・Positionクラス、eval_list()関数は、戻り値はEval::EvalList型ではなくEval::EvalList*型を返すように修正。(thx. わるおさん)
コピーに若干時間がかかってました…。(T_T)
207-17-189 (R15.8up)
■ 2016/03/25 V2.21
・CounterMoveHistoryStateの更新と取得に失敗していた件、修正。(thx. tさん)
MovePickerのStatsまわり色々修正した。
・miniも同様の修正をしてビルドしなおしてexe/フォルダにコピー。
・nano plusも。
V2.21 vs V2.18
157-14-114
R55up
■ 2016/03/25 V2.20
・置換表にDEPTH_MAX書き出せなくなってた。(thx. tさん)
例)
bool hit;
auto key = pos.state()->key();
auto tte = TT.probe(key, hit);
tte->save(key, VALUE_ZERO, BOUND_EXACT, DEPTH_MAX, MOVE_NONE, VALUE_ZERO, 0);
auto tte2 = TT.probe(key, hit);
std::cout << tte2->depth();
- depth8 = (int8_t)d / (int)ONE_PLY;
+ depth8 = (int8_t)(d / (int)ONE_PLY);
こうしないとd==256だと0になってからONE_PLY(==2)で割られて0が書き出されてしまう。(しまっていた)
あと、int8_tだから、128以上だと-128扱いされてしまうので、MAX_DEPTHを127*ONE_PLYに変更。
- #define MAX_PLY_NUM 128
+ #define MAX_PLY_NUM 127
→ これで1手詰めの値を置換表に書き出したときに効果が変わるかも。
V2.20 vs V2.18
110-7-101
R14.8 up?誤差?
・local serverで対戦させてたら落ちた。打ち歩詰めではないから、たぶん古いlocal serverのバグ。
1<Error : bestmove = P*1b
1<^香^桂^銀 □ □ □ □ 銀^玉
1< □ □ □ □ と □ 馬^銀 □
1<^歩 □^歩^歩 □^歩^歩^歩^金
1< □ □ □ □ □ □ □ □ 龍
1< □^歩 □ □ □ □ □ □ □
1< □ □ □ □ 玉 □ □ □ □
1< 歩 歩 歩 歩 □ 歩 □ □ □
1< □ 角 □ □^金 □ □^龍 □
1< 香 桂 □ 銀^金 □ □^金 □
1<先手 手駒 : 歩 香 桂 , 後手 手駒 : 歩4 香 桂
1<手番 = 先手
1<sfen lns4Sk/4+P1+Bs1/p1pp1pppg/8+R/1p7/4K4/PPPP1P3/1B2g2+r1/LN1Sg2g1 b PLN4pln 107
■ 2016/03/25 V2.19
・pseudo-legalのチェックで、counter moveの手は手番に関係ない(ような実装になっている)ので、
違法手のチェックが必要だったのでその修正。(thx. woodyringさん)
https://github.com/woodyring/YaneuraOu/commit/43a8770ab77f215e53d1d895d8954091a6fe3534
- template <bool All> bool pseudo_legal_s(const Move m) const;
+ template <bool All , bool CounterMove > bool pseudo_legal_s(const Move m) const;
・classicで1手詰めを呼び出すときに王手がかかっているかのチェックするの忘れていたの修正。(thx. woodyringさん)
https://github.com/woodyring/YaneuraOu/commit/fd2faf079063e2abea6790310bb4ec307386b7f7
・mate1ply()でpinnedを使っているので先行してcheck_info_update()が必要。(thx. tさん)
・classic、mini、nano plus修正。
V2.19 vs V2.18
221-24-234
-R10
少し遅くなった分だけ弱くなった？誤差？
■ 2016/03/25 V2.18
・CODEVS5.0が終わったので作業再開。
・古い置換表でバグる件
https://github.com/woodyring/YaneuraOu/commit/e20edfccb16b384beb0de4b0604d740b1c5c20e3
→ 古い置換表では table[key & hashMask]から4要素をclusterとして使っていたので
keyが1bit違う要素が隣り合って格納されることになり、null moveのときに相手番にするときに
bit0を使うのでここでhash衝突のようなことが起きていた。
・古いほうの置換表実装削除。(置換表が弱くなる原因ではなかったようなので)
・nanoでつねにfull depth searchになっていたバグを修正。(thx. kazuさん)
- bool fullDepthSearch = (PV && moveCount == 1);
+ bool fullDepthSearch = (PVNode && moveCount == 1);
・exe/フォルダのnanoの実行ファイル差し替え。
・seeのバグ修正。(thx. tさん、woodyringさん)
https://github.com/woodyring/YaneuraOu/commit/67a49c9e0420fbc43cbd25d00b7f46bb7c0fc1e2
200-8-182 R15程度up
■ 2016/03/07 V2.17
・古いほうの置換表
- uint64_t size = ClusterSize << MSB64((mbSize << 20) / sizeof(TTEntry[ClusterSize]));
+ uint64_t size = size_t(ClusterSize) << MSB64((mbSize << 20) / sizeof(TTEntry[ClusterSize]));
こんなコードになってた。uint64_tに拡張したときに拡張できてなかった。
やねうら王(2014)で4GB以上の置換表の確保に問題があったのこれか。(いまごろ)
ただ、今回の問題はこれとは関係ない。(確保は出来ている状況で新しいほうの置換表より明らかに弱いというものだから)
■ 2016/03/04 V2.16
・打ち歩詰めの判定、間違っていたようだ。(tanuki-さんよりバグ報告があった。)
// 攻撃駒はすべてpinされていたということであり、
// 王の頭に打たれた打ち歩をpinされている駒で取れるケースは、
// いろいろあるが、いずれも玉の頭方向以外のところから頭方向への移動であるから、pinされている方向への移動ということはありえない。
→ 間違い。
sfen +S5b1l/5gg2/p1+S1p2pp/1pKn4k/4PNS2/2+b3S1+r/PP3G1N1/5P3/L1G5L b P8plnr 119
玉^
歩
飛^
香
こういうケースがある。
■ 2016/03/01 V2.15
・比較実験用に古いStockfishの置換表のコード持ってきた。
sfen lns3snl/1r1gk1gb1/pppp1p3/6pRp/4pN3/6P1P/PPPPPP3/1B3S3/LNSGKG2L w Pp 20
→ insert_pvなんとかで落ちた。
勝率めっちゃ悪い。詰みを読みきったあと、逆転負け。何これ。
insert_pv絡みで何か壊しているのか。そんな馬鹿な…。
probe()のときにgenerationをrefreshするように追加したが、関係なかった。何なのこれ。
見たことのない症例。
■ 2016/03/01 V2.14
・classic
// 捕獲から逃れるための指し手に関してはreduction量を減らしてやる。
// 捕獲から逃れるとそれによって局面の優劣が反転することが多いためである。
if (r
&& !(move & MOVE_PROMOTE)
&& pos.effected_to(~us,move_from(move))) // 敵の利きがこの移動元の駒にあるか
r = std::max(DEPTH_ZERO, r - ONE_PLY);
こういう枝刈り(枝刈らない？)を入れてみた。
50.0%
#82
やねうら王classic V214
捕獲から逃れる手のreduction減らす, 1スレッド、0.1秒設定
#0
やねうら王classic V213
悪いhistoryにreduction追加, 1スレッド、0.1秒設定
185-13-185(52.1% R0.0)
→ 効果乏しい。コメントアウトしておく。
V2.14a
singularのmargin調整してみる。
Value rBeta = ttValue - (param1 + 1) * depth / ONE_PLY; // margin = 2 * depth / ONE_PLY
param1 = 0..4ぐらいで。
47.1% 49.0% 51.2% 40.6% 50.5%
#83
やねうら王classic V214a
singular margin=(param1+1)*depth, 1スレッド、0.1秒設定
#0
やねうら王classic V213
悪いhistoryにreduction追加, 1スレッド、0.1秒設定
140-8-157(85.2% R-19.9) 98-8-102(63.8% R-6.9) 103-7-98(33.6% R8.6) 80-11-117(99.7% R-66.0) 100-10-98(41.6% R3.5)
X=2 だからmargin = depth*15/ONE_PLYで最大になっているがあまり他と差がないので
singularは保留しておく。
・npsそもそもいつこんなに下がったのか。
V1.93で1割ほどダウン
V2.07で1割ほどダウン。→静止探索でfutility入れたからか…。
・枝刈り一通り入れたのに、予想外に弱いな。評価値の差分計算が間違ってないか検証する。
→ 差分計算は合ってた。
・やねうら王2015とやってみる。
やねうら王1手0.1秒固定で..
100.0% 0.0% 0.0% 0.0% 0.0%
#84
やねうら王2015
1スレッド、0.1秒設定
#0
やねうら王classic V213
悪いhistoryにreduction追加, 1スレッド、0.1秒設定
100-0-0(0.0% R∞) 0-0-0(100.0% RNaN) 0-0-0(100.0% RNaN) 0-0-0(100.0% RNaN) 0-0-0(100.0% RNaN)
100戦100敗だった。なにこれ。やはり評価関数か何かがおかしいとしか考えられない。
evalstat同じなのにeval違うだと…？
isready
position startpos
eval
これが正しいのか。
positionをセットしたタイミングでevalの全計算をするが、そのときに評価関数が読み込まれていないとまずくて…。
悔しいがevalも差分も完璧なのに…。
1スレッドで負けてるから、lazy SMP悪くないしな。
やねうら王2015とソース見比べるしかないな。
■ 2016/03/01 V2.13
・classic
// historyの値に応じて指し手のreduction量を増減する。
int rHist = (thisThread->history.get(pos.piece_on(move_to(move)),move_to(move))
+ cmh.get(pos.piece_on(move_to(move)),move_to(move))) / 14980;
r = std::max(DEPTH_ZERO, r - rHist * ONE_PLY);
53.2%
#81
やねうら王classic V213
悪いhistoryにreduction追加, 1スレッド、0.1秒設定
#0
やねうら王classic V212
悪いhistoryにreduction追加, 1スレッド、0.1秒設定
201-15-177(9.9% R22.1)
1回落ちた。なんで…。
sfen l3k2r1/p1g5l/1p1ss2g1/+b4pppp/2+bp5/2N2PPPP/+n1PPP2R1/2S1K4/4SG1NL w PN3plg 134
→ よくわからない。
local-server.exe
で対戦させておくか。
→ 3PCで一晩回したが落ちなかった。前プロセスが悪さしてたのかな…。
・miniの最終とclassicと対戦させてみる。
55.5%
#81
やねうら王classic V213
悪いhistoryにreduction追加, 1スレッド、0.1秒設定
#75
やねうら王mini V208
静止探索での駒得しないevasion枝刈り追加, 1スレッド、0.1秒設定
182-7-146(2.0% R38.3)
あまり強くなっていないが、弱くもなっていないので良しとする。
もうちょっと強くなっているはずだったのだが…。
■ 2016/03/01 V2.12
・classic 悪いhistoryにreduction量を増やす枝刈り追加してみる。
// cut nodeや、historyの値が悪い指し手に対してはreduction量を増やす。
if ((!PvNode && cutNode)
|| (thisThread->history.get(pos.piece_on(move_to(move)),move_to(move)) < VALUE_ZERO
&& cmh.get(pos.piece_on(move_to(move)),move_to(move)) <= VALUE_ZERO))
r += ONE_PLY;
61.3%
#80
やねうら王classic V212
悪いhistoryにreduction追加, 1スレッド、0.1秒設定
#0
やねうら王classic V208
静止探索での駒得しないevasion枝刈り追加, 1スレッド、0.1秒設定
92-1-58(0.2% R80.1)
■ 2016/03/01 V2.11
・singularもっかい試す
46.0%
#78
やねうら王classic V211
singular追加, 1スレッド、0.1秒設定
#0
やねうら王classic V208
静止探索での駒得しないevasion枝刈り追加, 1スレッド、0.1秒設定
426-33-501(99.4% R-28.2)
→ どう見ても悪い。原因よく調べる。
・Signals.stop、探索中にこれを調べるなら、Signals.stop.load(std::memory_order_relaxed)とすべき。修正。
・Signals.stop、searchの前のほうでもやるように。
・静止探索でpos.givesCheck()になっていたところ、givesCheckに修正。
V2.11a
・fail lowを引き起こした直前のcounter moveに加点するようにした。
・searchのなかにassertいくつか追加した。
sfen ln1gk3p/1rs1s4/p2ps1N+B+L/lp3p3/+Rn5P1/2G1PPPl1/3P5/P+b1G1S3/4KG3 b 4P3pn 79
静止探索でassertに引っかかった。
ASSERT_LV3(-VALUE_INFINITE < value && value < VALUE_INFINITE);
おかしい…。
value == -32004
置換表に32004を書き込んだ奴がいる。
TTEntry::saveに次のassertを追加。
ASSERT_LV3((-VALUE_INFINITE < v && v < VALUE_INFINITE) || v == VALUE_NONE);
if (!(-VALUE_INFINITE + ss->ply < value && value < VALUE_INFINITE - ss->ply))
{
pos.do_move(move, st, givesCheck);
value = givesCheck ? -qsearch<NT, true>(pos, ss + 1, -beta, -alpha, depth - ONE_PLY)
: -qsearch<NT, false>(pos, ss + 1, -beta, -alpha, depth - ONE_PLY);
pos.undo_move(move);
}
こう書くと原因わかった。
draw scoreにvalue_from_tt()みたいな変換していないからか…。
連続王手での千日手での負け、詰みスコアより低くするのは違う気がするので
やはりvalue_from_ttみたいなことしないといけないのか。
// -----------------------
// 千日手等の検出
// -----------------------
auto draw_type = pos.is_repetition();
if (draw_type != REPETITION_NONE)
return value_from_tt(draw_value(draw_type, pos.side_to_move()), ss->ply);
// 最大手数を超えている、もしくは停止命令が来ている。
if (Signals.stop.load(std::memory_order_relaxed) || ss->ply >= MAX_PLY)
return value_from_tt(draw_value(REPETITION_DRAW, pos.side_to_move()),ss->ply);
こうだ。miniも同様の修正をしておく。
■ 2016/02/29 V2.10
・1手詰めのときmate_in(ply + 1)でないとおかしいのか。忘れてた。修正した。
この修正で弱くなっていないことを確認しておく。
48.5%
#77
やねうら王classic V210
1手詰めスコア修正, 1スレッド、0.1秒設定
#0
やねうら王classic V208
静止探索での駒得しないevasion枝刈り追加, 1スレッド、0.1秒設定
199-14-211(74.0% R-10.2)
→ たぶん弱くはなってなさげ。
■ 2016/02/29 V2.09
・エンジンごとにUSIのオプションが異なるから、
Option::init()でコールバックするべきか。
→ そうした。
・やねうら王classicにNarrowBookのUSIオプション追加。
・やねうら王mini、R2800程度と思われるのでドキュメント類、書き換えておく。
・やねうら王classic、NarrowBookにしたものと対戦させてみる。
終局図までが同じになることが多々あってあまり意味があるとも思えないが…。
→ miniにもこの機能入れて、floodgateにはそれを投入する。
51.8%
#76
やねうら王classic V209
NarrowBook有効, 1スレッド、0.1秒設定
#0
やねうら王classic V208
静止探索での駒得しないevasion枝刈り追加, 1スレッド、0.1秒設定
174-10-162(23.9% R12.4)
あまり偏ってなかった。持ち時間が短いと序盤のミスを咎めるのが難しいからか…。
そもそも大悪手は含まれてないだろうしな…。
■ 2016/02/29 V2.08
・classicの静止探索で駒得しない王手回避と、なんやかや枝刈りするコード追加。
→ Detect non-capture evasions
62.9%
#74
やねうら王classic V208
静止探索での駒得しないevasion枝刈り追加, 1スレッド、0.1秒設定
#0
やねうら王classic V207
静止探索でのfutility追加, 1スレッド、0.1秒設定
90-1-53(0.1% R92.0)
よくはわからないが、とても効果があるみたい。
miniのほうもこの修正入れる。
64.1%
#75
やねうら王mini V208
静止探索での駒得しないevasion枝刈り追加, 1スレッド、0.1秒設定
#73
やねうら王mini V207a
静止探索の1手詰め復活, 1スレッド、0.1秒設定
166-8-93(0.0% R100.7)
■ 2016/02/29 V2.07
・classicの静止探索にfutility追加。
60.4%
#71
やねうら王classic V207
静止探索でのfutility追加, 1スレッド、0.1秒設定
#0
やねうら王classic V206
futility at parent node3, 1スレッド、0.1秒設定
110-9-72(0.2% R73.6)
→ これずいぶん効果がある。自己対局だからかも知れないが。
この枝刈りをminiに入れて、静止探索の一手詰めを削除するとどうなのか。
43.8%
#72
やねうら王mini V207
静止探索のfutility追加。1手詰め削除, 1スレッド、0.1秒設定
#67
やねうら王mini V204b
miniから静止探索の1手詰めだけ復活, 1スレッド、0.1秒設定
81-6-104(96.1% R-43.4)
1手詰めないと散々だな…。
V2.07a
→ miniの一手詰め戻す
これで2.04bに勝ち越すようなら、これで最終とする。
57.2%
#73
やねうら王mini V207a
静止探索の1手詰め復活, 1スレッド、0.1秒設定
#67
やねうら王mini V204b
miniから静止探索の1手詰めだけ復活, 1スレッド、0.1秒設定
91-7-68(2.8% R50.6)
弱くはなってなさそう。
→ exeフォルダのminiを差し替え
■ 2016/02/29 V2.06
・classicに親nodeで負のSEE値を持つ指し手の枝刈りも入れてみる。
// 次の子nodeにおいて浅い深さになる場合、負のSSE値を持つ指し手の枝刈り
if (predictedDepth < 4 * ONE_PLY && pos.see_sign(move) < VALUE_ZERO)
continue;
56.1%
#70
やねうら王classic V206
futility at parent node3, 1スレッド、0.1秒設定
#0
やねうら王classic V205a
futility at parent node2, 1スレッド、0.1秒設定
351-16-275(0.1% R42.4)
・qsearchにコメント追加。
■ 2016/02/29 V2.05
・classicに親nodeでのfutility追加。
// Futility pruning: 親nodeに関して
if (predictedDepth < 7 * ONE_PLY)
{
futilityValue = ss->staticEval + futility_margin(predictedDepth,pos.game_ply()) + param1 * 85;
if (futilityValue <= alpha)
{
bestValue = std::max(bestValue, futilityValue);
continue;
}
}
こうやってparam1 == 0..4ぐらいで前バージョンと対局させてみる。
46.0% 51.9% 55.4% 53.7% 54.5%
#68
やねうら王classic V205
futility at parent node, 1スレッド、0.1秒設定
#0
やねうら王classic V204
classicにhistoryに基づく枝刈り追加, 1スレッド、0.1秒設定
144-7-169(92.9% R-27.8) 160-12-148(22.9% R13.5) 173-8-139(2.4% R38.0) 169-5-146(8.8% R25.4) 168-12-140(4.9% R31.7)
V2.05a
X=2,すなわち170か。とりあえずそうしとく。
■ 2016/02/29 V2.04
・classicにHistoryに基づいた枝刈り追加。
77.9%
#64
やねうら王mini V203a
miniのほうmoveCountベースのfutility追加, 1スレッド、0.1秒設定
#0
やねうら王mini V202
singluar extension追加, 1スレッド、0.1秒設定
102-3-29(0.0% R218.5)
V2.04a
・miniにこの枝刈り入れて、1手詰め、削除するとどうか。
各種枝刈りを入れると一手詰めをの有無が利いてくるのか…。そうか…。
33.3%
#66
やねうら王mini V204a
miniにhistoryに基づく枝刈り追加 mate削除, 1スレッド、0.1秒設定
#0
やねうら王mini V203
moveCountベースのfutility追加, 1スレッド、0.1秒設定
18-0-36(99.5% R-120.4)
V2.04b
・miniから静止探索の1手詰めだけ復活
51.2%
#67
やねうら王mini V204b
miniから静止探索の1手詰めだけ復活, 1スレッド、0.1秒設定
#0
やねうら王mini V203
moveCountベースのfutility追加, 1スレッド、0.1秒設定
84-1-80(34.8% R8.5)
→ 前のバージョンと互角ぐらいっぽいのでこれですっきり。
■ 2016/02/29 V2.03
・classicにmoveCountベースのfutility追加
85.1%
#63
やねうら王mini V203
moveCountベースのfutility追加, 1スレッド、0.1秒設定
#0
やねうら王mini V202
singluar extension追加, 1スレッド、0.1秒設定
143-9-25(0.0% R303.0)
→ これ結構効果あるみたい。
これ入れて、miniのほう、効果の薄いのざっくり消すか。
・やねうら王mini、ソースコード整理して、exeフォルダの中身差し替えた。
■ 2016/02/29 V2.02
・classicにSingular Extension追加。
50.8%
#62
やねうら王mini V202
singluar extension追加, 1スレッド、0.1秒設定
#0
やねうら王mini V201
extend check追加, 1スレッド、0.1秒設定
215-17-208(34.9% R5.8)
おかしい。excludedMove = MOVE_NONEにしていないからか。初期化追加。
・Singular、バグってないはずなのに強くならない。もう少し条件考えたほうがよさげ…。
51.8%
#62
やねうら王mini V202
singluar extension追加, 1スレッド、0.1秒設定
#0
やねうら王mini V201
extend check追加, 1スレッド、0.1秒設定
379-48-352(15.0% R12.8)
■ 2016/02/28 V2.01
・classicに王手による1手延長を追加。
57.5%
#61
やねうら王mini V201
extend check追加, 1スレッド、0.1秒設定
#0
やねうら王mini V200
IID追加, 1スレッド、0.1秒設定
168-9-124(0.4% R52.8)
見かけ上のRはずいぶん上がるが…。
■ 2016/02/28 V2.00
・classicに多重反復深化を入れてみる。
メモリが潤沢にある(or 指し手が1手0.1秒なら)、これによる勝率の変化はほとんどないはず。
51.7%
#60
やねうら王mini V200
ProbCut追加, 1スレッド、0.1秒設定
#59
やねうら王mini V199
ProbCut追加, 1スレッド、0.1秒設定
1153-59-1076(5.1% R12.0)
→ 思ったより変わった。
■ 2016/02/28 V1.99
・classic開発開始。
・ProbCut入れてみる。
・StateInfoの変数名siではなくstにしてStockfishに合わせておく。
・MovePicker::nextMoveではなくnext_move()のほうがいいのでは…。
・MovePickerにProbCut用の指し手生成を追加。
60.0%
#58
やねうら王mini V199
ProbCut追加, 1スレッド、0.1秒設定
#0
やねうら王mini V192
null move追加, 1スレッド、0.1秒設定
150-7-100(0.1% R70.4)
・miniにもProbCutは入れる。ProbCut 10行程度のわりにR70ぐらい増えるのでお得だ。
■ 2016/02/28 V1.98
・miniのlazy SMP条件を調整。
for (Thread* th : Threads)
if (th->completedDepth > bestThread->completedDepth
&& th->rootMoves[0].score > bestThread->rootMoves[0].score)
bestThread = th;
↓
for (Thread* th : Threads)
if (th->completedDepth > bestThread->completedDepth ||
(th->completedDepth == bestThread->completedDepth && th->rootMoves[0].score > bestThread->rootMoves[0].score))
bestThread = th;
どう考えてもこっちのほうがいいと思うのだが…。
これでV1.95と4スレッド1秒で対戦させてみる。
48.2%
#58
やねうら王mini V198
lazySMP改良, 4スレッド、0.1秒設定
#57
やねうら王mini V195
4スレッド設定, 4スレッド、0.1秒設定
477-42-513(88.0% R-12.6)
この改良は駄目なのか。スコアがいいほうが楽観合議のような効果があるのだろうか。
→ 元に戻す。
exeフォルダのminiを差し替える。
classicのほうの開発進める。
■ 2016/02/28 V1.97
・lazy SMP、言うほど強くなってないな…。再検証する。
・completedDepthの初期化忘れていたの修正。
・resignするときにlazy SMP、bestThreadを探す処理、これrootMoves.size()==0だとアクセス違反なのでは。
Stockfishのコードがおかしいんだな…。
→ 修正した。
・4スレッド設定と対局させておく。
75.7%
#57
やねうら王mini V195
4スレッド設定, 4スレッド、0.1秒設定
#56
やねうら王mini V195
razoring戻す, 1スレッド、0.1秒設定
667-15-214(0.0% R197.5)
■ 2016/02/28 V1.96
・Rootで3秒以上経過しているなら探索手を出力するように。
・思ったより強くならない。旧形式からの評価関数バイナリの変換に失敗している可能性がなくもないな…。
検算しよう。
sfen lnsg1k3/9/pppp+N1G2/4pppp1/3l5/2P6/PPS1PPP2/1Kl1G1S2/LN3S+r2 w BRG4pnb 86
eval = -2047
→ 完全に一致してた。
・持ち時間制御をしていないことによる損失は2倍時間ぐらいで、R200ぐらいあるのかも。
・singular extensionをしていない損とかもあるのか…。
・ProbCutはMovePickerに手を入れないと実装できないしな…。
・やねうら王miniはこんなもんでいいか…。じゃあ、miniはこれで完成。
・exeフォルダにやねうら王miniを追加。
■ 2016/02/28 V1.95
・local serverでCreateProcessに失敗したときに復帰できなくなるの修正。
・V1.95a
razoring戻して、V1.94と対戦させておく。
54.2%
#56
やねうら王mini V195
razoring戻す, 1スレッド、0.1秒設定
#55
やねうら王mini V194
定跡修正, 1スレッド、0.1秒設定
266-18-225(2.9% R29.1)
→ これでいいや。
■ 2016/02/28 V1.94
・miniで定跡の指し手が指せていない。修正。
・miniでrootMovesに定跡の指し手が含まれていない場合、定跡の指し手を選択しないように。
・変な定跡を選択していたので勝率がちゃんと計測できてなかった。あらら…。まあいいや。パラメーターはまた調整しよう。
・floodgateに6コアPCで放流しておく。
55.9%
#55
やねうら王mini V194
定跡修正, 1スレッド、0.1秒設定
#0
やねうら王mini V192
null move追加, 1スレッド、0.1秒設定
100-4-79(5.0% R40.9)
■ 2016/02/28 V1.93
・miniにrazoring追加。
const int razor_margin_table[4] = { 483, 570, 603, 554 };
const Value razor_margin(Depth d)
{
ASSERT_LV3(DEPTH_ZERO <= d && d < 4 * ONE_PLY);
return (Value)(512 + 16 * static_cast<int>(d));
return (Value)razor_margin_table[d / ONE_PLY];
}
53.4%
#52
やねうら王mini V193
razoring追加, 1スレッド、0.1秒設定
#0
やねうら王mini V192
null move追加, 1スレッド、0.1秒設定
205-10-179(8.4% R23.6)
→ あまり強くなってない。
V1.93a
Apery風のrazoringにしてみる。
inline Value razor_margin(const Depth d) {
return (Value)(512 + 16 * static_cast<int>(d));
}
if (!PvNode
&& depth < 4 * ONE_PLY
&& eval + razor_margin(depth) < beta
&& ttMove == MOVE_NONE
&& abs(beta) < VALUE_MATE_IN_MAX_PLY)
{
const Value rbeta = beta - razor_margin(depth);
const Value s = qsearch<NonPV, false>(pos, ss, rbeta - 1, rbeta, DEPTH_ZERO);
if (s < rbeta)
return s;
}
47.9%
#53
やねうら王mini V193a
razoring apery風追加, 1スレッド、0.1秒設定
#52
やねうら王mini V193
razoring追加, 1スレッド、0.1秒設定
236-13-257(83.9% R-14.8)
V1.93b
margin、線形にしてみる。
const Value razor_margin(Depth d)
{
static_assert(ONE_PLY == 2,"static_assert ONE_PLY == 2");
ASSERT_LV3(DEPTH_ZERO <= d && d < 4 * ONE_PLY);
return (Value)(512 + 16 * static_cast<int>(d));
}
50.2%
#54
やねうら王mini V193b
razoring apery+stockfish風追加, 1スレッド、0.1秒設定
#52
やねうら王mini V193
razoring追加, 1スレッド、0.1秒設定
112-9-111(44.7% R1.6)
→ ほぼ変わらないから、これでいく。
■ 2016/02/28 V1.92
・miniにnull move pruning追加。
・Position::do_null_move()/undo_null_move()追加。
→ iterationだいぶ回るようになった。
61.9%
#51
やねうら王mini V192
null move追加, 1スレッド、0.1秒設定
#50
やねうら王mini V191
pseudo_legal修正, 1スレッド、0.1秒設定
166-3-102(0.0% R84.6)
■ 2016/02/27 V1.91
・0.1秒自己対局で4000局で1回落ちたようだ。やはりinsert_pv_in_tt()以外で何かやらかしている。
・リリースビルドであれ、デバッガでアタッチさえできればウォッチでpos.sfen()としてsfen文字列を取り出したり、
to_usi_string(move)とかで、指し手文字列を得たりできるので、デバッグは出来るのだが…。
sfen lnsg1k3/9/pppp+N1G2/4pppp1/3l5/2P6/PPS1PPP2/1Kl1G1S2/LN3S+r2 w BRG4pnb 86
・2PCで8時間回して落ちない。
・残りのPCにもVS入れてテストする。
・local server、pseudo-legalのチェック入れるべきか…。
→ すでに入ってた
・MovePickerがpseudo legalの判定するのだが、check_info_update()が呼び出されていないのでは…。
→ と思ったが、呼びだされていた。
・本格的に原因がわからんので、5PCでlocal-server回しておく。
↓
6時間で1回落ちた。
sfen 2bK1G3/7+L1/6+R2/1G6s/1G7/9/1P7/5ps2/2r1pks1+B w 10P3NG5p3lns 247
→ この局面100%落ちるわ..やったー！
59の歩が一歩進んで61の玉をcaptureしてる…。
ああ、置換表に58->59銀みたいな指し手があると、次にkillerでこれが歩に適用されて
59歩不成みたいな指し手が生成されるということなのか。なるほど、駒種を持っていないとこういうことが起こりえるのか…。
動かす駒を持っていればpseudo-legalの判定でその駒でなければ弾かれるのか。うーん、なるほど…。
→ 調べてみたら、counte moveに登録されてこの手が生じたようだ。counter moveって駒が違うと適用されるべきではないのか..そうか..
pseudo_legal拡張して、かつ、駒種は持つべきなのか…そうか…。
置換表サイズ足りない..。
// これ、駒種を持っておいて、駒種が違うときは適用しないほうがオーダリング効率は上がる。
auto cm = thisThread->counterMoves.get(prevPc, prevSq);
Moveが32bitになるとCounterMoveの配列も倍になるしな…。
そもそもそんなに都合よく別の駒が来ていることって現実的にはほとんどない気もするしな…。
・insert_pv_in_tt()のところ戻して、もう一度、変な指し手が生成されていないか確認する。
・Position::legal<bool All>(),pseudo_legal<bool All>()
みたいなチェック入れたほうがいいのか…。うーん..
// All == true : 歩や大駒の不成に対してはfalseを返すpseudo_legal()
template <bool All> bool pseudo_legal_s(const Move m) const;
追加した。
・どこで不成の指し手が出てくるのか以下のコードを追加して調べる。
if (pos.pseudo_legal_s<false>(move) == false)
{
std::cout << pos << move << std::endl;
pos.pseudo_legal_s<false>(move);
}
"ln4s2/1k5b1/p1pgppp1n/1P2l2g1/1G5p1/4P4/P2P1PP1P/2S2S1R1/+n2K1G3 b S5p2lnbr 75"
この局面に対してQCHECKで歩の不成が生成されている。
case PAWN: GEN_MOVE_NONPRO_CHECK(PAWN, pawnEffect, goldEffect); break;
case LANCE: GEN_MOVE_LANCE_CHECK (LANCE, lanceEffect, goldEffect); break;
このへんが怪しい。
if (((Pt == PAWN || Pt == LANCE) &&
((!All && ((Us == BLACK && rank_of(to) >= RANK_3) || (Us == WHITE && rank_of(to) <= RANK_7))) ||
(All && rank_of(to) != (Us == BLACK ? RANK_1 : RANK_9))))
この条件が間違っている。
↓こうではないかと。
if (((Pt == PAWN) &&
((!All && !canPromote(Us,to)) ||
(All && rank_of(to) != (Us == BLACK ? RANK_1 : RANK_9))))
|| ((Pt == LANCE) &&
((!All && ((Us == BLACK && rank_of(to) >= RANK_3) || (Us == WHITE && rank_of(to) <= RANK_7))) ||
(All && rank_of(to) != (Us == BLACK ? RANK_1 : RANK_9))))
↓
rootPos.set("ln4s2/1k5b1/p1pgppp1n/1P2l2g1/1G5p1/4P4/P2P1PP1P/2S2S1R1/+n2K1G3 b S5p2lnbr 75");
cout << rootPos;
for (auto m : MoveList<QUIET_CHECKS>(rootPos))
cout << " " << m;
うまく動いた
Piece moved_piece(Move m) const { return is_drop(m) ? move_dropped_piece(m) : piece_on(move_from(m)); }
これが後手のときに後手の指し手でないのがおかしいのか。
→ これ修正した。駒打ちに関するオーダリングが少し改善されるかも。
・statのupdateにassert追加した。
・Threadsが変更になってからisreadyが送られてこないとisreadyでthread数だけ初期化しているものはこれではまずいのか…。
sfen ln5nl/6gk1/p1sp1g1s1/1P2ppppp/1p1P5/1bP1PPPPP/PRNSBGNS1/6GK1/L2r4L b p 67
setoption name Threads value 1
isready
go infinite
test autoplay
→ わかった。飛車を成って、その成った駒を動かした指し手がcounter moveに登録されている。
これがまずいので、MovePickerではpseudo_legal_s<false>()を呼び出すようにする。
・これで修正できたと思うのでV1.88と対戦回してみる。
53.7%
#50
やねうら王mini V191
pseudo_legal修正, 1スレッド、0.1秒設定
#0
やねうら王mini V188
並列化版 1スレッド設定, 1スレッド、0.1秒設定
237-21-204(5.3% R26.0)
オーダリング改善されたせいかR25ほど上がっているのかも知れない。
・nano plusのほう、リビルドして差し替えておく。
■ 2016/02/27 V1.90
・value_to_tt()の説明間違っていたので修正。
・go infiniteで8時間回しても落ちないのに連続自己対局で落ちるということは
再戦時の初期化がおかしいのか…。
CounterMoveHistory.clear();
for (Thread* th : Threads)
{
th->history.clear();
th->counterMoves.clear();
}
こんだけは初期化されているのに…。
・local serverで落ちたプロセスをtrapするようにする。
→ C#側から2段にCreateProcessしているのがいけないのか…。
→ C#のCreateProcessが子プロセスのエラーを握り潰しているのかも知れない..
・local server単体ならデバッグ可能みたいなのでこれでやる。
落ちた
→ insert_pv_in_tt()
ASSERT_LV3(MoveList<LEGAL>(pos).contains(m));
で落ちた。PVがおかしくなっているのか…。
pv配列の更新はおかしくないから、おかしいPV渡されていることになる。
pseudo-legalの判定怪しいな…。
このLEGALは、LEGAL_ALLのほうがいいのか…。
LEGALでない指し手が含まれているとここで引っかかって落ちるのか。
修正しておく。
→ しかし、ここで角の不成みたいな手が含まれているのがおかしい気がする。
CAPTUREの指し手に不成が含まれているのがおかしいのでは…。
→ 含まれてないな…。おかしいな…。
→ 銀の不成の指し手をcounter moveとして登録して、この位置に角が来ると
角の不成の指し手を生成することになる。
王のcaptureになっているのはどこか他のバグがあるはず…。
このままランニングさせておく。
・pseudo_legalにASSERT少し追加。
・MovePicker
ASSERT_LV3(pos.pseudo_legal_s<false>(move));
こうしてランニングしてみる。
・miniのsilent modeで定跡のcoutへの出力抑制する。
■ 2016/02/26 V1.89
・miniでmain threadでfail high/lowが起きたときにGUIに読み筋を出力するようにした。
・miniでbook moveまわりの処理、整理。
・静止探索で指し手がないときにそれを保存しないようにして比較実験。
// これ保存したほうがいいかどうかは比較実験が必要。
/*
tte->save(posKey, value_to_tt(bestValue,ss->ply) , BOUND_EXACT,
DEPTH_MAX, MOVE_NONE, ss->staticEval, TT.generation());
*/
42.7%
#47
やねうら王mini V189
並列化版 1スレッド設定, 1スレッド、0.1秒設定
#0
やねうら王mini V188
並列化版 1スレッド設定, 1スレッド、0.1秒設定
205-18-275(99.9% R-51.0)
V1.89a
よくわからんけど、勝率悪いので戻す。
保存することで0.5手延長のような効果があるのだろうか..
50.5%
#48
やねうら王mini V189a
並列化版 1スレッド設定, 1スレッド、0.1秒設定
#0
やねうら王mini V188
並列化版 1スレッド設定, 1スレッド、0.1秒設定
563-46-552(37.1% R3.4)
計測しなおした。
50.2%
#47
やねうら王mini V189
並列化版 1スレッド設定, 1スレッド、0.1秒設定
#0
やねうら王mini V188
並列化版 1スレッド設定, 1スレッド、0.1秒設定
4551-411-4514(34.9% R1.4)
1.89、悪くなかった。
■ 2016/02/26 V1.88
・miniのaspirationでfail highのときの処理入れてなかった。修正した。
・よし、さっきの局面では落ちなくなったのでまたもや1スレッドで対局させておく。
・マルチスレッドのバグ、これで取れたのかも知れないので将棋所で自己対局もさせておく。
→ 50局ほどやったが落ちない。
・fail highの処理入れてないからaspirationのdeltaに対する効果が薄かったのかな。
あとで調整する。
・4スレッド版とV1.82と対局させておく。
79.0%
#46
やねうら王mini V188
並列化版 4スレッド設定, 1スレッド、0.1秒設定
#0
やねうら王mini V182
ss->moveCount更新するようにした, 1スレッド、0.1秒設定
413-25-110(0.0% R229.8)
並列化によって4並列時でR230ほど上がっているようだ。
0.5手延長のような効果が出ているだけかも知れないのでこの数字は
あまりアテにならない。PV splitも実装して比較すべき。
あと上記の対局中に2回落ちているようだ。
sfen l2gk4/2s5g/1pn3rp1/2pp1p2N/8p/pP1P5/P1P1SP3/4KS3/LNBG2+p+rL b B5plnsg 75
sfen 5+S+RG+P/4+NK2+P/4P+P1+B1/S2b4+P/1+R1s5/9/P3+nk+n2/1+l3+p1+n+p/9 w 9PLGp2ls2g 232
単体では落ちないか…そうか…。
■ 2016/02/26 V1.87
・miniでseldepthを出力するためにmaxPlyを更新するようにした。
・miniのsearch(),qsearch()に次のassert追加
ASSERT_LV3(-VALUE_INFINITE<=alpha && alpha < beta && beta <= VALUE_INFINITE);
ASSERT_LV3((PvNode || alpha == beta - 1);
・miniでbookMoveがあるときにRootMoves[0]を参照していたの修正。
・将棋所でminiのDebug buildとランダムプレイヤーとを連続対局させておく。
→ 突然落ちる。デバッグ不可。
・Releaseビルドでtest autoplayだと落ちない。わけわからん。
・1スレッド対局で落ちないかテストしよう。
V1.82と対局させておく。
→ V1.87のほう、一回落ちた…。なんで..
sfen ln1gk4/1r1s2pp1/pppppp1s+R/2b4g1/7NB/2P2g3/PPSP5/4S4/LN1GK4 b 3PLN3pl 77
51.5%
#44
やねうら王mini V187
並列化版 1スレッド設定, 1スレッド、0.1秒設定
#0
やねうら王mini V182
ss->moveCount更新するようにした, 1スレッド、0.1秒設定
1205-114-1133(6.8% R10.7)
■ 2016/02/26 V1.86
・complete depthに反映させてなかったの修正。
・miniのPV表示、もっと限定する。
・ThreadPool::init_for_slave()追加
void init_for_slave(const Position& pos, const Search::LimitsType& limits);
・test autoplayコマンドを並列化されている探索部も呼び出せるようにした。
・nano plusのSearch::clear()に
for (Thread* th : Threads)
{
th->history.clear();
th->counterMoves.clear();
}
これ入れるの忘れてた。落ちる原因は、これか…。
・nano plusの実行ファイル差し替え。
・miniはまだ落ちる。なんぞこれ。
auto playでSearch::clear()呼び出さないからか。修正した。
しかし対局中に落ちたのはこれとは違うはずで…。
わからん。デバッグビルドでauto play回しておく。
→ 一晩回して落ちなかった。
・aspirationのdeltaの初期値の調整
50.9% 50.8% 47.1% 50.3% 46.6% 50.3% 49.4% 51.9% 52.0% 47.5% 51.7% 50.0% 50.6% 50.9% 50.4%
#42
やねうら王mini V184a
aspirationの幅可変 param1 * 5, 1スレッド、0.1秒設定
#0
やねうら王mini V182
ss->moveCount更新するようにした, 1スレッド、0.1秒設定
678-75-655(26.4% R6.0) 678-73-657(28.3% R5.5) 617-65-692(98.1% R-19.9) 588-55-582(43.0% R1.8) 543-66-623(99.0% R-23.9) 591-50-583(40.8% R2.4) 568-75-581(64.9% R-3.9) 605-62-560(9.4% R13.4) 603-73-556(8.4% R14.1) 553-59-610(95.3% R-17.0) 601-63-562(12.6% R11.7) 587-58-587(50.0% R0.0) 587-64-573(34.1% R4.2) 589-70-569(27.8% R6.0) 589-64-579(38.5% R3.0)
X=8、すなわち5*8 = 40がベストっぽい。このへんはもう少し作りこんでから再度調整すべき。
■ 2016/02/26 V1.85
・miniの並列化
→ half density matrix、実装できたかも。
aspirationの幅を30にしてテスト。
→ よくわからんのでこれでfloodgateに放流しておく。
・MovePickerのあとのfutilityで刈らない分とlazy SMPでスレッドの空きが発生しない分かで、
4コアで4.7Mnpsぐらい出ている。HT有効にしたほうが良かったりして…。
■ 2016/02/26 V1.84
・並列化のための準備
・aspiration searchの実装
・RootMoves::insert_pv_in_tt()追加
・MoveList::contains()追加
・tt.hにupdate_pv()を追加する。
Search::Stack::pvを更新するようにした。
・miniは、USE_TT_PVを使わないようにした。
・にわかに信じられないが初手58玉の局面でevaluate()を呼ぶと-1500ぐらいの評価値が返ってくる。
V1.82と対戦させてaspirationによって勝率が落ちていないことを確認する。
50.8%
#41
やねうら王mini V184
aspiration search実装, 1スレッド、0.1秒設定
#0
やねうら王mini V182
ss->moveCount更新するようにした, 1スレッド、0.1秒設定
166-25-161(37.0% R5.3)
よくわからない。調整したほうがよさげ。
PV更新で少し時間かかるようになったのと、aspirationの窓の調整がうまく出来ていなくて
あまり効率が上がっていないっぽい。このへんのパラメーターはもう少し作りこんでから調整すべき。
V1.84a
// aspiration windowの幅
// 精度の良い評価関数ならばこの幅を小さくすると探索効率が上がるのだが、
// 精度の悪い評価関数だとこの幅を小さくしすぎると再探索が増えて探索効率が低下する。
delta = Value(param1 * 5);
aspirationの幅をstep 5ずつ変更してparam1 = 0..15ぐらいで最適値を探してみる。
→ 一晩寝かせておく。
■ 2016/02/25 V1.83
・mini、思考開始時にTimerリセットしないと。
・StockfishのSearch::LimitsがstartTime持っているの仕様としておかしい気がする。
→ やねうら王ではTimerクラスに持たせる。
・Timer.init()でstartTimeを初期化するようにして、明示的にはこれをアクセスしないように変更する。
・searchなどの返し値に次のassert入れた。
ASSERT_LV3(-VALUE_INFINITE < v && v < VALUE_INFINITE);
・aspiration windows search、原型だけ書く。
59.2%
#40
やねうら王mini V182
ss->moveCount更新するようにした, 1スレッド、0.1秒設定
#0
やねうら王nano plus V180
EVASIONSのオーダリング追加, 1スレッド、0.1秒設定
302-23-208(0.0% R64.8)
なぜかR60ぐらい上がっている。moveCount絡みのbonusなのか？
■ 2016/02/25 V1.82
・やねうら王mini開発開始
・やねうら王nano plusの思考エンジンの実行ファイルをGitHubにcommit。
・local-server、CreateProcessするときにデバッグ有効にしとくべきか…。
DEBUG_PROCESS
→ これではないのか。うーむ..
デバッガを自動的に起動する
https://msdn.microsoft.com/ja-jp/library/a329t4ed(VS.80).aspx
レジストリエディタを開き
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\currentversion\image file execution options
に、
新しいキーでデバッグ対象の実行ファイルの名前を入れる。"YaneuraOu-mini.exe"とか。
> 新しい文字列値を右クリックし、ショートカット メニューの [名前の変更] をクリックします。
> 名前を debugger に変更します。
> 新しい文字列値を右クリックし、ショートカット メニューの [変更] をクリックします。
> [文字列の編集] ダイアログ ボックスが表示されます。
> [値のデータ] ボックスに、「vsjitdebugger.exe」と入力します。
→ ビンゴ！これでやっとデバッグできる。4コアで24時間ほど回しておく。
・miniに引き分け時スコア)Contenpt)を設定できるようにした。
・miniの日本語化ファイル
YaneuraOu-mini_ja.txt
をexe/に追加。
・miniをMultiPVに対応
isready
setoption name MultiPV value 5
go
→ PVの表示できた。指し手がないように見えるからmateになってしまうので修正。
→ 表示がおかしいだけだった。修正した。
・miscにTimeManagementクラス追加。
・nano plusのss->moveCountの初期化してないな…。まあ、nano plusではあんまり影響ないからいいか。
nano plusで親nodeのss->moveCountを参照しているところコメントアウトしておく。
→ この効果があるのか調べるために前バージョンと対戦させておく。
■ 2016/02/25 V1.81 nano plus (final)
・BAD CAPTUREにSEE<0の指し手回すと強くなるのか？
ほぼ変わらないっぽい。
→ このまま一晩回してみる。
→ 26コアで回して一晩で2回落ちた。誰か原因調べて欲しい…。
53.8%
#38
やねうら王nano plus V181
BAD CAPTURE実装, 1スレッド、0.1秒設定
#0
やねうら王nano plus V180
EVASIONSのオーダリング追加, 1スレッド、0.1秒設定
6571-626-5634(0.0% R26.7)
+R25程度。
■ 2016/02/25 V1.80
・EVASIONのオーダリングにSSEが必要だしな…。
→ evasionのオーダリングと、QCAPTURES_1,2のオーダリングをするようにした。
静止探索のCAPTURESが改善されたので見かけの勝率が随分あがったが…。
たぶん言うほど効果ないと思う。
73.6%
#37
やねうら王nano plus V180
EVASIONSのオーダリング追加, 1スレッド、0.1秒設定
#0
やねうら王nano plus V179
CAPTUREのオーダリング追加, 1スレッド、0.1秒設定
162-17-58(0.0% R178.4)
■ 2016/02/25 V1.79
・MovePickerに他のオーダリングも導入
captureのときのオーダリング追加。
score_capture()追加。
54.4%
#36
やねうら王nano plus V179
CAPTUREのオーダリング追加, 1スレッド、0.1秒設定
#0
やねうら王nano plus V178
counter move追加, 1スレッド、0.1秒設定
210-31-176(3.7% R30.7)
+R30程度？
■ 2016/02/25 V1.78
・nano plusにCounterStats追加。
・nano plusのMovePickerファイルを分離する。
・Position::moved_piece()追加。
・ThreadにCounterMoveHistoryStatsを持たさないといけないのに..これうまく分離できないな…。
#ifdef USE_MOVE_PICKER
// スレッドごとにhistoryとcounter movesのtableを持たないといけない。
CounterMoveHistoryStats history;
MoveStats counterMoves;
#endif
これ、仕方ないな…。
・nano plusのkillerにcountermoveを入れるようにする。
・historyのupdate()の処理入れる。
67.1%
#35
やねうら王nano plus V178
counter move追加, 1スレッド、0.1秒設定
#0
やねうら王nano plus V176b
思考時間0.1～0.3秒, 1スレッド、0.1秒設定
420-19-206(0.0% R123.8)
・プロセスが落ちないか、26コアで一晩回しておく。
・このバージョンをfloodgateに投入しておく。
■ 2016/02/24 V1.77
・劣等局面の判定追加する。
→ 確かに優等局面を発見したときに早く探索が回るが、思考時間が一定なので
この分の時間が得しなくて時間固定の自己対局では勝率が変わらない。
500局やってほぼ互角。
■ 2016/02/24 V1.76
・nano plusに簡単に導入できそうな枝刈りを追加する。
・futilityまず入れる。
// game ply(≒進行度)とdepth(残り探索深さ)に応じたfutility margin。
Value futility_margin(Depth d,int game_ply) {
// 80手目を終盤と定義して、終盤に近づくほどmarginの幅を上げるように調整する。
game_ply = min(80, game_ply);
return Value(50 * d * (param1+1) + game_ply * param2);
}
こうやって、futilityの幅を調整してみる。
param1 = 0..4 , param2を0..4ぐらいの幅で
dにも比例させるべきなのか…そうか…。
return Value(d * ((param1+1) * 30 + game_ply * param2 / 2));
param1 = 0..5 , param2 = 0..3ぐらいで回しておく。
→ X = 0..5
36.1% 62.7% 70.1% 68.2% 62.0% 60.5%
52.8% 44.7% 63.3% 57.3% 55.3% 61.9%
67.7% 78.3% 67.2% 62.8% 56.2% 59.4%
46.7% 65.7% 64.7% 55.1% 63.3% 62.0%
#32
やねうら王nano plus V176
futility margin調整中 , 1スレッド、0.1秒設定
#0
やねうら王nano plus V175
超安定版 , 1スレッド、0.1秒設定
297-10-525(100.0% R-99.0) 506-25-301(0.0% R90.2) 573-15-244(0.0% R148.3) 552-23-257(0.0% R132.8) 502-22-308(0.0% R84.9) 494-16-322(0.0% R74.3)
428-21-383(5.3% R19.3) 360-27-445(99.9% R-36.8) 518-14-300(0.0% R94.9) 460-29-343(0.0% R51.0) 445-27-360(0.1% R36.8) 501-22-309(0.0% R84.0)
545-27-260(0.0% R128.6) 642-12-178(0.0% R222.8) 548-17-267(0.0% R124.9) 427-10-253(0.0% R90.9) 343-14-267(0.1% R43.5) 365-10-249(0.0% R66.4)
286-12-326(95.1% R-22.7) 401-14-209(0.0% R113.2) 392-18-214(0.0% R105.1) 338-11-275(0.5% R35.8) 391-6-227(0.0% R94.5) 377-16-231(0.0% R85.1)
Y=0ではX=2あたりがピーク。depth*90ってことか。Aperyの130ぐらいになってるの意味があるんだな。
Y方向はなぜかY=2がピーク。Y=1の結果が直感に反するのでnanoとも対戦させてみる。
80.9% 95.9% 93.9% 91.1% 91.3% 92.1%
63.9% 73.1% 88.1% 86.1% 93.1% 87.8%
91.3% 83.1% 92.3% 92.2% 90.0% 86.5%
80.6% 94.1% 93.3% 86.5% 86.8% 81.4%
#32
やねうら王nano plus V176
futility margin調整中 , 1スレッド、0.1秒設定
#30
やねうら王nano V172
テスト用のnano
463-20-109(0.0% R251.3) 560-8-24(0.0% R547.2) 551-5-36(0.0% R473.9) 534-6-52(0.0% R404.6) 538-3-51(0.0% R409.3) 538-8-46(0.0% R427.2)
367-18-207(0.0% R99.5) 413-27-152(0.0% R173.6) 509-14-69(0.0% R347.1) 506-4-82(0.0% R316.1) 543-9-40(0.0% R453.1) 509-12-71(0.0% R342.2)
527-15-50(0.0% R409.1) 468-29-95(0.0% R277.0) 537-10-45(0.0% R430.7) 540-6-46(0.0% R427.9) 505-18-56(0.0% R382.0) 468-19-73(0.0% R322.8)
435-20-105(0.0% R246.9) 526-1-33(0.0% R481.0) 518-5-37(0.0% R458.5) 469-18-73(0.0% R323.1) 478-9-73(0.0% R326.4) 428-9-98(0.0% R256.1)
・まだ落ちる局面があるようだ。詰み絡みのようだが…。静止探索絡みか？
sfen ln4+P1p/9/ppp1kp2R/b2p5/K6+R1/2g6/P3+lg3/3s4+p/L+b7 b S2G9pl3n2s 173
よくわからないのでDebugビルドでtest autoplayで回しておく。
これでバグが発見するのに要する時間は、2時間×5PC*10倍nps = 100時間ぐらい回さないといけないのか。
いくらなんでもひどいな。Releaseモードで回すか。これなら10時間程度で見つかるはず..
→ これ自動テストのなかでもっと効率的に見つけられないのか？
if (param1!=5)
{
}
みたいにすれば特定のパラメータでその処理を省略することは出来るから
一晩寝かせておけばそこそこ原因がわかるはず…。
→ と思ったが3時間ほど回して落ちない…。
・連続自己対局のときに思考時間ばらつかせないとな…。
・V1.76b
連続自己対局のために
go time 100
のようにしたら100ms秒だけ考えるという仕様にするか？
go randtime 100
としたときに100～300ms考えるという仕様にするとか？
go rtime 100
こうするか。実装した。
→ availableTime = Limits.rtime + prng.rand(Limits.rtime * 2);
→ 終局の局面はそこそこバラけるようになったる
■ 2016/02/24 V1.75
・25000局ほど回して、V1.74、1度だけ落ちてる。
1<sfen 1n3k3/1PK2g3/2np5/2+B2+B3/L1pPp4/6p1+p/5G3/2G1GP2+p/1+rS3+r+l1 w 3P2LN3S6pn 142
→ 例によって単体だと落ちない。26コアで8時間かけて1回落ちる程度のバグは探すの大変。
long effect絡みのような気もするが、これ修正するのは容易ではないな…。
QUIET_CHECKがpseudo-legalか確認しておく。
→ 王手がかかっていない局面なので回避手になっているかは調べる必要がない。
ああ、わかった。
MovePickerの静止探索用のほうも、endMoves間違えてた
endMoves += (_ttMove != MOVE_NONE);
↓
endMoves += (ttMove != MOVE_NONE);
これでいいや。よしよし。
■ 2016/02/23 V1.74
・乱数seed、外部から読み込めるようにしたほうがよさげ。
thread idではなくprocess idにしたら解消するか？
→ まあいいや。
・0.1秒で3万局やって47回落ちてた。26並列対局において1時間で6回ぐらい落ちるわけか。10分で1回落ちるな。
対局ログサイズ2.7MB
ASSERTに引っかかったケースなし。うわぁぁぁ。
思考エンジンからログを書きだそうにもバッティングするしな..
local server、思考エンジンからのエラーは先頭にErrorの文字を入れるように。
・ランダマイズやはり何かおかしい気がする。子プロセスだとthread idが固定化されているとしか思えない。
process IDにするか..。定跡局面で定期的にランダム思考させるか。うむむ..
→ thread IDでバラけてた。うわぁぁぁ。
・PRNG、初期化時に乱数まわすようにした。
int n = (int)get_thread_id() & 1024; // 最大1024回、乱数を回してみる
for (int i = 0; i < n; ++i) rand<uint64_t>();
・local serverにメッセージをbypassする仕組みが要るのでは…。
Redirectorのread()で"Error"の文字列をbypassするようにした。
文字列はERRORではなくErrorで統一することにした。
・定跡早い段階で抜けると同じ展開になるというのはあるのか…。
MultiPVで思考するとかしないと同じ展開を抜けられないな。まあ、仕方ないか。
local serverで開始タイミングばらけさせるの意味ないな。
・nano plus、静止探索をreturn evaluate(pos);にしてどうなるかやろう。
→ これでも落ちるのか..
・置換表の指し手、無効化してみる。
// ttMove = ttHit ? tte->move() : MOVE_NONE;
ttMove = MOVE_NONE;
→ これでもないのか。なんなのだ…。
・killerも無効化してみる。
case KILLERS:
move = *currentMoves++;
#if 0
if ( move != MOVE_NONE // ss->killer[0],[1]からコピーしただけなのでMOVE_NONEの可能性がある
&& move != ttMove // 置換表の指し手を重複除去しないといけない
&& pos.pseudo_legal(move)
&& !pos.capture_or_pawn_promotion(move)) // 直前にCAPTURES_PRO_PLUSで生成している指し手を除外
return move;
#endif
break;
→ これも違うのか..
mate1消す
LONG_EFFECT_LIBRARYも使わない。
→ これでもあかんのか。なんなん…。
// (ss + 2)->killers[0] = (ss + 2)->killers[1] = MOVE_NONE;
#if 0
auto draw_type = pos.is_repetition();
if (draw_type != REPETITION_NONE)
return draw_value(draw_type,pos.side_to_move());
#endif
これでどうか。→ あかん。
MovePicker、これでどうか。
// KILLERS, // KILLERの指し手
// BAD_CAPTURES, // 捕獲する悪い指し手
GOOD_QUIETS, // CAPTURES_PRO_PLUSで生成しなかった指し手を生成して、一つずつ返す
// BAD_QUIETS, // ↑で点数悪そうなものを後回しにしていたのでそれを一つずつ返す
これもあかんのか。probeの直後、
ttHit = false; // 置換表にhitしていないことにする。
これでどうか。→ 落ちない？
// -----------------------
// 局面を評価値によって静的に評価
// -----------------------
ttHit = false; // 置換表にhitしていないことにする。
ここならどうか。→ 落ちる
Move ttMove = RootNode ? thisThread->rootMoves[thisThread->PVIdx].pv[0]
: ttHit ? tte->move() : MOVE_NONE;
ttHit = false; // 置換表にhitしていないことにする。
ここは？ → 落ちる
MovePicker mp(pos, MOVE_NONE /*ttMove*/ ,ss);
これは？ → 落ちないくさい。MovePickerの置換表絡み怪しげ。
endMoves += (ttMove_!= MOVE_NONE);
これか。
endMoves += (ttMove != MOVE_NONE);
こうやん..。
→ 2000局やって、落ちない。これだった…。やっと改良に戻れる。
→ V1.70と対局させてみる。
→ 弱くはなってなさげ。
50.2%
#28
やねうら王nano plus V172
落ちる原因調査 , 1スレッド、0.1秒設定
#25
やねうら王nano plus V170
千日手判定追加 , 1スレッド、0.1秒設定
12481-389-12401(30.6% R1.1)
■ 2016/02/22 V1.73
・定跡のrandomizeのため、randのrandomizeの性能を上げる。
→ thread idもseedに用いるように変更。
・local server、終局時のsfen出力して、同一局面でないことを確認したほうがいいのでは..
・てか、どこをいじった結果かは知らんが落ちなくなってる…。
→ と思ったら落ちたようだ。
sfen ln1g4+L/1s4s1P/p1p1pk3/1P4pp1/P8/1B4n1R/2NS1+p3/3GS3K/L4g1N1 b 5PLBG4pr 103
・DrawValue、関数を通すようにする。→ draw_value()
同じところで落ちてるな。単体だとここで落ちないんだよな…。
→ てかrandom playerでも落ちるんか？それを先に確認しないと原因の絞りようがない。
→ random player落ちないな…。test rpで落ちないのだから落ちないか…そうか…。
→ nanoも連続自己対局させてみる。
→ nanoは4000局で落ちないのか…。
つまりpseudo_legal()は正しい。
nano plusのMovePickerとかis_repetitionとかが怪しいのかな？
is_repetition、シンプルだし、たぶん合ってる。
QUIET_CHECKSが怪しい。
case QCHECKS:
// endMoves = generateMoves<QUIET_CHECKS>(pos, moves);
endMoves = moves; // 生成しないと？
break;
→ 生成しなくとも落ちた。なんなんこれ…。
sfen +B+P1S+P1+L2/3+R5/1p1p+Pp+L+R1/1kp6/p6G1/9/P3+p1P2/5+b1K1/L1G6 b 7PL4N3SGg 131
sfen 1s3pR+R1/l3kg2P/p1+Np4+P/4pbl2/P2Pn4/L1P1K4/1P7/1sS2PB+p1/3G5 b PLS5p2n2g 151
nano plusのMovePicker、ちゃんと見なおしたほうがよさげ…。
sfen 3+P2kp+R/l3gl+r2/pppp1pp2/7sB/9/9/PPP2SPPN/1B3P1G1/L1SG2K2 b 3PL2NGpns 105
・nano plus、"go infinite"に対応させる。
is_repetition を 無効化して落ちるかのテスト。
→ 落ちたか。これはきつい。
・ASSERTに関して、errorでも出力できればいいのだが…。
local-serverで"ERROR:"というメッセージをリダイレクトするようにして、
ASSERTでは"ERROR:xxx"と出力できるようにするか。
→ USE_DEBUG_ASSERT追加
#define ASSERT(X) { if (!(X)) std::cout << "\nERROR : ASSERT(" << #X << ")\n"; }
こうした。
・local-serverでgame over時にsfenの出力
・thread idだと同じ番号なのか…？
local-serverの開始タイミングをずらすか。
→ こうした。
for (auto th : Threads.slaves)
{ th->start_searching(); sleep(10); } // 開始タイミングをずらすことで乱数seedをばらけさせる
→ これでもまだ乱数偏るな…なんなの…。
→ thread_idが同じ値なのか？うむむ？
乱数seed調整してみた。
PRNG() : s(now() ^ uint64_t(this) + get_thread_id()*1234567) {}
→ これでも駄目か..
// 乱数のseedなどとしてthread idを使いたいが、
// C++のthread idは文字列しか取り出せないので無理やりcastしてしまう。
inline uint64_t get_thread_id()
{
auto id = std::this_thread::get_id();
if (sizeof(id) >= 8)
return *(uint64_t*)(&id);
else if (sizeof(id) >= 4)
return *(uint32_t*)(&id);
else
return 0; // give up
}
別マシンと同じthread idを引いてくることってありえるのか？わからん..
→ そうでもなさげなのでこれはいいや。
・ASSERTでエラーが出力されるようにしたnano plus、1300局でやっと落ちたが、
ASSERTにはかからず。
sfen ln1g4+L/1s4s1P/p1p1pk3/1P4pp1/P8/1B4n1R/2NS1+p3/3GS3K/L4g1N1 b 5PLBG4pr 103
■ 2016/02/22 V1.72
・また落ちる局面があった。
sfen l+R2+L3+P/g4P2G/pppp3b1/4+r2bk/4p4/P1PSP4/1P1S1G3/2KG5/LNS5+p w 2N6plns 142
→ 落ちない。わからん。
sfen 1G4+L1+S/+r8/1p+S4+P1/2N1+B4/9/4GP2+B/+ln2K2p+R/k5s1p/1g+p1G1+p+p+n w 6PLN4pls 186
sfen +R8/5G3/1p2+B+N1+B1/p1ps5/2k4K1/P1+rP1+sP2/4g4/9/+s1G4+p1 b 5P3L2NS6plng 133
・打ち歩詰めの指し手生成、~UsではなくUsか。修正した。
Bitboard pe = pawnEffect(Us,pos.king_square(~Us));
→ 違った。あってた。
・歩を打つときの判定、legal_pawn_drop()にまとめた。
・nano-plusのmate1ply()、残り深さがONE_PLYより大きいときにのみ呼ぶようにした。
・local game serverでエンジン名ではなく実行ファイル名を表示するように。
・local game serverでtime out時(おそらくエンジンが停止した)に、継続できるように修正。
→ これで永続的にランニングできる…はず。(暴走したエンジンがに残存しなければ)
・floodgateに投入してあるほう、R2200付近の対戦相手が少なくて正確なレーティングがわからない。
たぶんR2200ぐらいなのではあるのだろうけども。もうちょっと強くしないとな。
・この局面の指し手、おかしい
>1:position startpos moves 7i6h 3c3d 8h7i 8c8d 6i7h 8d8e 3i4h 8e8f 8g8f 8b8f P*8g 8f8d 5g5f P*8f 8g8f 8d8f P*8g 8f5f 5i6i 2b4d 6h5g 5f5e 5g4f 5e8e 4h5g 5c5d 5g6f 8e2e 3g3f 2a3c 2i3g 2e8e 7g7f 4a5b 8i7g 8e8b 2h5h P*8f 8g8f 8b8f P*8g 8f7f 5h5d 7f7d 5d5f 4d6b 6f6e 7d9d 5f8f P*8b P*5d 7c7d 8f5f 8a7c 4f5e 7d7e 2g2f 6b2f 4i3h 3a4b 3f3e 2f3e 7i3e 3d3e 5f2f B*1d 2f5f 3e3f B*2b 3f3g+ 3h3g 3c4e 3g4f N*3d 4f3f P*3e 5d5c+ 4b5c 2b3c+ 5c4b 3c4b 5a4b S*2e 3e3f 2e1d 1c1d P*5c 5b6b 6e5d 4e3g+ 6i7i B*8c 5d4c+ 4b4c
・local serverで暴走した局面集
shogi-observer-log.txt(570): 4<sfen ln1g4+L/1s4s1P/p1p1pk3/1P4pp1/P8/1B4n1R/2NS1+p3/3GS3K/L4g1N1 b 5PLBG4pr 103
shogi-observer-log.txt(702): 1<sfen ln1g4+L/1s4s1P/p1p1pk3/1P4pp1/P8/1B4n1R/2NS1+p3/3GS3K/L4g1N1 b 5PLBG4pr 103
shogi-observer-log.txt(1425): 4<sfen +S2+N5/8+R/G8/9/3K+R4/9/4+s+p+p+pg/1+p3+b+p2/1k1+b+p+n+p+p+p b 8PLp3l2n2s2g 157
shogi-observer-log.txt(1745): 4<sfen ln1g4+L/1s4s1P/p1p1pk3/1P4pp1/P8/1B4n1R/2NS1+p3/3GS3K/L4g1N1 b 5PLBG4pr 103
shogi-observer-log.txt(2041): 2<sfen 1b4+LG1/9/2nP1+P2k/1P1+R1K1N1/6PP1/2p2g1+r1/4+p2g1/1S5+p1/+pN4+pb1 b 6PS2p3ln2sg 251
shogi-observer-log.txt(2249): 2<sfen l1n3+L1+S/1kr+B1p3/pp1+Sp1+b2/2p6/9/2PG2P2/P1K2P3/4G4/9 w 4PL3N2SR2G5pl 140
shogi-observer-log.txt(2606): 1<sfen ln1g4+L/1s4s1P/p1p1pk3/1P4pp1/P8/1B4n1R/2NS1+p3/3GS3K/L4g1N1 b 5PLBG4pr 103
shogi-observer-log.txt(2840): 3<sfen lns3+L2/4+R4/ppkpp4/2p3+B2/3N1pK2/8+R/PPPP5/1B4+l2/LNSG2+p2 w 4P2S3G3pn 82
shogi-observer-log.txt(2999): 4<sfen ln4+L1+N/k8/1g2G+B1+S1/p8/6K2/1+r2+p4/+p1+p6/7p+p/2+r5+p w 8P2L2S2G3p2nsb 180
shogi-observer-log.txt(3888): 4<sfen ln1g4+L/1s4s1P/p1p1pk3/1P4pp1/P8/1B4n1R/2NS1+p3/3GS3K/L4g1N1 b 5PLBG4pr 103
shogi-observer-log.txt(4669): 2<sfen 4g1k2/3Ps1p2/R8/2+B3LBL/ppP1SP3/1RN6/6N2/3SK4/3G1GS2 b 5PLN7plng 133
shogi-observer-log.txt(4874): 2<sfen 3+P2+L1+S/1+P4+N+B+P/7+S1/4+rlg1P/4P1p2/1P1GS1g1p/P2P+b+p1+p1/LKS3k2/5P+p1+n w 2P2NR2plg 238
shogi-observer-log.txt(5108): 3<sfen ln1g4+L/1s4s1P/p1p1pk3/1P4pp1/P8/1B4n1R/2NS1+p3/3GS3K/L4g1N1 b 5PLBG4pr 103
shogi-observer-log.txt(5327): 2<sfen lnsg1+L3/9/ppppk4/2N2gpb1/1K4P2/1P4R1s/P1P+r3+p1/2s1p4/L1+b1+n1S2 w P2G6pln 146
shogi-observer-log.txt(5723): 4<sfen ln1g4+L/1s4s1P/p1p1pk3/1P4pp1/P8/1B4n1R/2NS1+p3/3GS3K/L4g1N1 b 5PLBG4pr 103
shogi-observer-log.txt(6331): 4<sfen ln1g4+L/1s4s1P/p1p1pk3/1P4pp1/P8/1B4n1R/2NS1+p3/3GS3K/L4g1N1 b 5PLBG4pr 103
shogi-observer-log.txt(7151): 4<sfen ln1g4+L/1s4s1P/p1p1pk3/1P4pp1/P8/1B4n1R/2NS1+p3/3GS3K/L4g1N1 b 5PLBG4pr 103
shogi-observer-log.txt(7569): 4<sfen ln6+L/2ksg4/pppppp3/3rN4/4+b4/2PPS4/PP1K1PN2/6S2/LNSG1G2+p w BR6plg 70
shogi-observer-log.txt(8258): 1<sfen 5s1+P+B/1rk6/2nss3+N/1p2p3G/9/2+r6/1+b1P3p+p/2PK2+p1+p/+n+l1G2+p+p+p w 5P2Gp3lns 170
shogi-observer-log.txt(9067): 2<sfen ln1g4+L/1s4s1P/p1p1pk3/1P4pp1/P8/1B4n1R/2NS1+p3/3GS3K/L4g1N1 b 5PLBG4pr 103
shogi-observer-log.txt(13072): 4<sfen ln1g4+L/1s4s1P/p1p1pk3/1P4pp1/P8/1B4n1R/2NS1+p3/3GS3K/L4g1N1 b 5PLBG4pr 103
shogi-observer-log.txt(13169): 2<sfen ln1g4+L/1s4s1P/p1p1pk3/1P4pp1/P8/1B4n1R/2NS1+p3/3GS3K/L4g1N1 b 5PLBG4pr 103
shogi-observer-log.txt(13791): 4<sfen ln1g4+L/1s4s1P/p1p1pk3/1P4pp1/P8/1B4n1R/2NS1+p3/3GS3K/L4g1N1 b 5PLBG4pr 103
shogi-observer-log.txt(14215): 4<sfen lnS+S4+P/1n2+R3+P/k+B7/1pp3np1/p7K/6P2/P8/1L2+l1G2/LN6+R w 10P2SB3G 180
shogi-observer-log.txt(15356): 2<sfen ln4+L2/1r1+S+BG2P/pkp1+B3+N/1p1p5/9/2P6/PP1P2+p2/4K2+p+p/LNSG1S2+p b 4PLNRGpsg 87
→ 同じ局面いっぱいある…。定跡、そんなにバラけてないのか…。それは残念…。連続自己対局、思考時間、ランダム化したほうがいいのでは…。
random playerをしばらく回す。
→ 検出できない。nano plusが何かバグっているのか…。そうか…。
→ nano plusを1プロセス内で連続自己対戦させるか。
→ testコマンドにautoplay追加。
・LimitTypeにサイレントモード追加。
・nano plusにサイレントモード追加。
・is_draw()、最初に2手遡るの忘れていたので修正。
・is_repetitionに名前変更。
setoption name Hash value 4
isready
test autoplay
これでしばらく回しておく。
→ 一時間回して落ちない。
ASSERT、引っかかるときにメッセージを出すようなASSERT作るべきかも..
仕方ないので、自己対局で落ちるかのテストをする。
■ 2016/02/22 V1.71
・色々いじったので、search()のなかでmate1有効にしてみる。
// RootNodeでは1手詰め判定、ややこしくなるのでやらない。
// 置換表にhitしたときも1手詰め判定は行われていると思われるのでこの場合もはしょる
if (!RootNode && !ttHit )
{
bestMove = pos.mate1ply();
if (bestMove != MOVE_NONE)
{
// 1手詰めスコアなので確実にvalue > alphaなはず。
alpha = mate_in(ss->ply);
tte->save(posKey, value_to_tt(alpha, ss->ply), BOUND_EXACT,
DEPTH_MAX , bestMove, ss->staticEval, TT.generation());
return alpha;
}
}
こうしておく。なんか前のバージョンに有意に勝ち越す気がしなくもない…。
・V1.71a
if (!RootNode && !ttHit && depth > param1*ONE_PLY)
こうして、param1 = 0 .. 8ぐらいで最適値を調べてみる。PVとnon PVで違ってくるのか..まあいいか…。
49.1% 50.4% 50.7% 50.8% 51.1%
#27
やねうら王nano plus V171a
search()でmate1呼び出すように param1でそのdepth変更 , 1スレッド、0.1秒設定
#0
やねうら王nano plus V170
千日手判定追加 , 1スレッド、0.1秒設定
1613-37-1672(84.8% R-6.2) 1658-51-1630(31.3% R3.0) 1596-47-1550(20.6% R5.1) 1571-45-1521(18.4% R5.6) 1579-31-1511(11.1% R7.6)
depth > ONE_PLY
これぐらいで呼び出さないとリターン小さすぎなのか。そうか。
■ 2016/02/22 V1.70
・Position::is_draw()追加した。
・nano-plusに連続王手の千日手の検出コードを追加する。
・nano-plusでMAX_PLY到達のときのスコアを引き分けのスコアに変更する。
→ 変更した。無駄な探索が減った分と、連続王手でMAX_PLYまで延長していたのが
解消した分だけ強くなっているような…。(+R20)
53.0%
#25
やねうら王nano plus V170
千日手判定追加 , 1スレッド、0.1秒設定
#0
やねうら王nano plus V169c
打ち歩詰め関係の修正 , 1スレッド、0.1秒設定
351-18-311(5.5% R21.0)
■ 2016/02/21 V1.69
・指し手生成に打ち歩詰め入れて、pseudo_legal()で打ち歩詰め判定入れるの忘れていた。修正。
・V1.69a
legal_dropを呼ぶときにその前に敵玉がいるかの判定が要るんだった…。修正。
王手になる打ち歩の指し手生成、修正。
・V1.69b
Square pawn_attack = (sideToMove == BLACK) ? to + SQ_U : to + SQ_D;
if (sq_king != pawn_attack)
return true;
// → この判定の仕方だと、kingが駒落ちでSQ_NBにいるときにSQ_NB - 9の場所に歩を打つとkingの
// 行き場所がないから打ち歩詰めと判定されてしまう。
if (pawnEffect(sideToMove, to) != Bitboard(sq_king))
return true;
こう書くべきなのか…。同様のミス、他はやってなかった。
・V1.69c
pseudo_legal()を以下のように修正。
// 歩のとき
if (pr == PAWN)
if ((pieces(us, PAWN) & FILE_BB[file_of(to)]) // 二歩
|| ((pawnEffect(us, to) == Bitboard(king_square(~us)) && !legal_drop(to)))) // 打ち歩詰め
return false;
legal_drop()に玉の位置に関するASSERT追加。
王手となる打ち歩の指し手生成、以下のように修正。
// 二歩と打ち歩詰めでないならこの指し手を生成。
if (!(FILE_BB[file_of(to)] & pos.pieces(Us,PAWN)) &&
!((pawnEffect(Us, to) == Bitboard(king_square(~Us)) && !pos.legal_drop(to))))
mlist++->move=make_move_drop(PAWN, to);
・勝率の偏りはないと思うが、1000局ほどランニングしておく。
→ 弱くはなってなさそうなのでこれでOk.
4000局やってみたところ、+R10程度上がっていることがわかった。
■ 2016/02/21 V1.68
・nano plus、full depth searchも、nonPVでやるべきでは..
→ 修正した。
・LMRのreduction量、ONE_PLYを引いてからリダクションしないといけないの、間違えていたので修正。
・V1.68a
・full depth searchで探索窓狭くしていなかったの修正。
130ぐらい低いな…。わけがわからん…。
Depth d = max(newDepth - r + (Depth)1, ONE_PLY);
こうしたら、めっちゃ勝率上がった。わけがわからん…。
77.9%
#20
やねうら王nano plus V168
LMR、full depth search修正,1スレッド、0.1秒設定
#
やねうら王nano plus V166
通常探索でevaluate()を呼び出すように,1スレッド、0.1秒設定
187-1-53(0.0% R219.0)
・V1.68b
Depth d = max(newDepth - r , ONE_PLY);
こう戻してみる。
37.1%
#21
やねうら王nano plus V168b
LMR変更テスト,1スレッド、0.1秒設定
#
やねうら王nano plus V166
通常探索でevaluate()を呼び出すように,1スレッド、0.1秒設定
109-3-185(100.0% R-91.9)
→ やはり-R90ぐらいになる。わけがわからん。
・V1.68c
捕獲はreduction減らす。
→ 関係なさげ。
reduction、0.5手延長のようになって強いだけなのか？
一度、nanoと比較してみる。
94.0%
#22
やねうら王nano plus V168c
LMR変更テスト2,1スレッド、0.1秒設定
#1
やねうら王nano V140
やねうら王nanoの最終版1スレッド、0.1秒設定
156-1-10(0.0% R477.2)
88.2%
#21
やねうら王nano plus V168b
LMR変更テスト,1スレッド、0.1秒設定
#1
やねうら王nano V140
やねうら王nanoの最終版1スレッド、0.1秒設定
150-1-20(0.0% R350.0)
→ どうも0.5手延長の効果のような気がしてきた。
ちょっと気分は悪いが、今回のものを採用する。
・Position::capture(),capture_or_promotion()でdrop除外するの忘れていた。修正。
→ これのためにLMRの処理がおかしくなっていたのか？
→ これを修正したが、それでもV1.68bにはかなり負け越す。
30.1%
#
やねうら王nano plus V168c
LMR変更テスト2,1スレッド、0.1秒設定
#21
やねうら王nano plus V168b
LMR変更テスト,1スレッド、0.1秒設定
31-1-72(100.0% R-146.4)
・V1.68d
わかった。
value = depth < ONE_PLY ?
は、まちがい。
value = newDepth < ONE_PLY ?
これが正しい。
1.66と対戦させる。結構勝ち越すようだ。
これでcommitしておく。
floodgateでR2500以上つくなら、これでnano plusは開発終了。
■ 2016/02/21 V1.67
・nano plus、improvingフラグ用意。
→ この改良は微差のようなのでこのままランニングさせておくる
50.5%
#19
やねうら王nano plus V167
improving追加,1スレッド、0.1秒設定
#0
やねうら王nano plus V166
通常探索でevaluate()を呼び出すように,1スレッド、0.1秒設定
934-3-915(32.9% R3.6)
ほぼ変わらない…。なんなの…。
■ 2016/02/21 V1.66
・nano plus、通常探索でeval保存するようにした。
+R50ぐらいup？
通常探索でevalが呼び出されると差分計算が出来るようになるのでその分だけ得なのか…。
やや高速化した気がする。
・Eval::eval()という関数名、気に入らないのでevaluate()と名前を変更する。
・連続対戦のときの戦績が偏るの、同じseedの乱数を使って定跡選択をしているからという話はないか…？
→ uint64_t(this)を乱数seedにしているので実行ファイルの読み込みのランダム化が行われているなら問題なさげ…。
■ 2016/02/21 V1.65
・まだ落ちる局面があるようだ。もしかして255手目でMAX_PLYに到達して落ちた感じ？
4<Error : engine timeout , engine name = YaneuraOu nano plus KPP 1.62 64 AVX2
4< □ 金 □ □ 玉 金 と □ と
4< □ □ 圭 □ □ 圭 □ 杏 □
4< □ □ と □ □ □ □ と と
4< □ □ □ □ □ 馬 □ □ □
4< □ □ □ □ □ □ □^歩^と
4< □ □ □ □ □ □ □^と □
4< □ □ □ □^全 □^と □ □
4< □ □ □ □^龍^と^玉^と^と
4< □^金^と □ □ □^と^と^と
4<先手 手駒 : 歩2 香 角 , 後手 手駒 : 香2 桂2 銀3 飛 金
4<手番 = 先手
4<sfen 1G2KG+P1+P/2+N2+N1+L1/2+P4+P+P/5+B3/7p+p/7+p1/4+s1+p2/4+r+pk+p+p/1g+p3+p+p+p b 2PLB2l2n3srg 255
→ nano plusのsearch stackがkillerの初期化でアクセス違反になるっぽい。
search<Root>は、やめたほうがいいのでは..うーん。id_loop()、あとで考え直す。
とりあえずss+1にしてるのはおかしいのでそこだけ修正する。
あとsearchにMAX_PLYの判定追加する。
連続王手の千日手、判定していないのでそれ絡みで無限に延長されてPVでMAX_PLYに到達して落ちるのか。そうか…。
とりあえずMAX_PLYの判定だけ追加した。
1<Error : engine timeout , engine name = YaneuraOu nano plus KPP 1.64 64 AVX2
1<^香 □^玉 □ □ □ □ □ と
1< □ □^龍^金 □ □ □ 馬 □
1< □ □^桂 □ □ と □ □ □
1< □ □ □^歩 □ □ □ □ □
1< □ □ □ □ 歩 □ □ □ □
1< □ □ 馬 □ □ □ □^歩 □
1<^と □ □ □ 玉 □ □ □^と
1< □ □ □ □ □ □ □^と^と
1< □ □ 龍 □ □ □ □^と □
1<先手 手駒 : 歩4 桂3 銀 金 , 後手 手駒 : 歩4 香3 銀3 金2
1<手番 = 先手
1<sfen l1k5+P/2+rg3+B1/2n2+P3/3p5/4P4/2+B4p1/+p3K3+p/7+p+p/2+R4+p1 b 4P3NSG4p3l3s2g 157
・前のバージョンに対してだいぶ負けるようになった。もしかして前のバージョン、連続王手の千日手で不利になったときに逃れているパターンがあるのか？
// 最大手数を超えている
if (ss->ply >= MAX_PLY)
return VALUE_ZERO; // Draw Score
→ こう変更して引き分けを回避させよう。
→ これでもV1.64に-R100ほど負け越している感じ。なんなん…。
→ 打ち歩詰め絡みで何かやらかしたのか？
→ recap深さは、やはり-3のほうが良いということなのか..戻した。
・メモリ8GBのときnormal perft、うまく動かないという報告が。
→ 固定で確保してるんだった…。
■ 2016/02/21 V1.64
・nano plusで静止探索、深さ-5までCAPTURESを生成しているの、よくない可能性が微レ存。
// 静止探索でこれより深い(残り探索深さが少ない)ところではRECAPTURESしか生成しない。
DEPTH_QS_RECAPTURES = -3*(int)ONE_PLY,
→ 1.57aと対戦させておく。こっちのほうが明らかに強いな..
・V1.64a
// 静止探索でこれより深い(残り探索深さが少ない)ところではRECAPTURESしか生成しない。
DEPTH_QS_RECAPTURES = -2*(int)ONE_PLY,
→ こう変更するとどうなのだ？
→ こっちのほうがわずかに強いっぽい。うわぁぁぁ。
今後、これを基準ソフトにしよう..
50.7%
#16
やねうら王nano plus V164a
静止探索のRECAPの深さ-3→-2に変更,1スレッド、0.1秒設定
#0
やねうら王nano plus V164
静止探索のRECAPの深さ-5→-3に変更,1スレッド、0.1秒設定
1687-16-1638(19.8% R5.1)
→ floodgateに放流しておく。
■ 2016/02/21 V1.63
・local server、timeout時にMOVE_RESIGNを返すように変更。
・local server、非合法手もMOVE_RESIGN扱いするように変更。
・そのときにエラーを出力するように変更。
・local server、エンジンを配置するpath変更できるように。
→ engine-config.txtのほうでエンジン名にpathが指定されていればいいか…。
■ 2016/02/21 V1.62
・打ち歩詰めの処理、LongEffect有り時の高速化
→ 綺麗には書けた気がする。あまり呼び出し頻度の高くない部分のコードなので高速化には寄与していない気が…。
===========================
Total time (ms) : 16981
Nodes searched : 20291525
Nodes/second : 1194954
1%ぐらいnpsが上がったのか？ちょっと嬉しい。
・nano-plusのデバッグ用のコード消してなかったの修正。
■ 2016/02/21 V1.61
・long effectがあるときにeffected_toは高速化できるのでそのコード追加。
改良前とbenchのnode数が変わらないことを検証する。
===========================
Total time (ms) : 17606
Nodes searched : 20291524
Nodes/second : 1152534
→ 変更後。nps 0.2%ぐらい上がった？
===========================
Total time (ms) : 17578
Nodes searched : 20291524
Nodes/second : 1154370
ASSERT無効にしてベンチ
===========================
Total time (ms) : 17142
Nodes searched : 20291525
Nodes/second : 1183731
何故かノード数が1だけ変わる…。do_move()するようなASSERTどこかに入っているのか..？あとで調べる。
とりあえずこれでcommitして、floodgateに放流しておく。
・nanoとnano plusと対局させておく。
■ 2016/02/21 V1.60
・pos.legal()の判定おかしいのか。
position startpos moves 7i6h 5c5d 6i7h 3c3d 2g2f 8c8d 7g7f 2b8h+ 7h8h 7a6b 6h7g 3a3b 2f2e 3b3c 4i5h 4a3b 5h6h 4c4d 6h7h 5a4a 5i5h 6a5b 7g8f 7c7d 8f7g 5b4c 5h6i 4a3a B*5b 3a2b 5b6a+ B*9d 6a9d 9c9d B*5b 4c4b 5b6a+ B*4c 6a4c 4b4c 6i5h 6b5c 2e2d 3c2d 7g6f 9d9e 6f6e B*8c 8i7g 6c6d 6e5f 7d7e 7f7e P*7f 7g6e 6d6e 9g9f 9e9f P*2e 2d3c 7e7d 8c7d 9i9f 9a9f P*7e 7d8c B*6c N*8e 8g8f 8e9g+ 8h8g 9g8g 7h8g 9f9g+ 8g7f 8c9d 7f6e P*7f P*9e 9d7b N*9d 7b6c 9d8b+ L*2g 2h2g 5d5e 2g2h G*2g 6e7d
go btime 169000 wtime 29000 byoyomi 10000
^飛 王 ★
★の升に移動する指し手はevasionにはならない。
ゆえにpos.legal()の判定、これを考慮しないといけない。
effected_to()の仕様がおかしいんだな。修正した。
■ 2016/02/21 V1.59
・local server、応答がなくなる原因わかった。bestmove待ちでエンジンがbestmoveを返さないと
そのまま待ち状態になるのがいけないのか。1分でtimeoutとしよう。
// タイムアウトチェック(連続自己対戦で1手に1分以上考えさせない
if (now() >= start + 60 * 1000)
{
sync_cout << "Error : engine timeout" << endl << pos << sync_endl;
return MOVE_NONE;
}
・また、local server、一行ずつ出力するのをデフォルトとしよう。
こちらのほうが、外部から自動操作するときに出力をparseするのが簡単だから。
// 1行ずつ結果を出力するモード
#define ONE_LINE_OUTPUT_MODE
■ 2016/02/21 V1.58
・DEPTH_QS_RECAPTURESとりあえず-10にしておく。この値でそんなに悪くはなさそうなので。
→ また後日調整する。
■ 2016/02/20 V1.57b
・local server機能で、プロセスが終了しないとき用の修正。
→ これでも終了しないことがあるためprocessのkillも行なうようにした。
→ これでもプロセス残ることがある。おかしい。ソース、読みなおす。
→ local-serverのidle_loopにsleep(5)を追加。
→ 長手数による引き分け、条件がMAX_PLYになっていたのを256に修正。
→ こっちの問題ではなさげ..
→ ソースコード、再度整理する。
・nano-plusのrecaptureの指し手生成間違っていたのを修正。
・nano-plusで静止探索での3手以上延長しないほうがいいのか実験。
// 探索深さが-3以下ならこれ以上延長しない。
if (param1)
{
if (depth < -3 * ONE_PLY)
{
// せっかくevaluateを呼び出したので置換表にhitしていないなら今回のevaluateの値を保存しておく。
if (!ttHit)
tte->save(posKey, value_to_tt(bestValue, ss->ply), BOUND_LOWER,
DEPTH_NONE, MOVE_NONE, ss->staticEval, TT.generation());
return bestValue;
}
}
→ なぜかR220ほど下がる。
RECAPTURESの指し手生成なにかおかしいのでは..
RECAPのフェーズをparam1依存にして、これでパラメーターを変えた実験をしてみる。
延々、同じ升でRECAPするだけのはずなのにレーティング下がるのなんで…。
else if (depth > /*DEPTH_QS_RECAPTURES*/ (Depth)(-3-param1))
stage = QSEARCH_WITHOUT_CHECKS_START;
→ MovePickerでttDepth突っ込んでたから延々とCAPTURESが生成されてたくさい。
→ これ修正したらずいぶんマシになった気がする。ベストな値を探す。
51.8% 56.0% 59.6% 59.8% 64.6% 62.7% 63.9%
#
やねうら王nano plus V157b
やねうら王nano plus param1!=0なら静止探索で3手以上延長しない,1スレッド、0.1秒設定
#0
やねうら王nano plus V157a
やねうら王nano plus 静止探索のオーダリングいじった,1スレッド、0.1秒設定
489-0-455(12.7% R12.5) 529-0-415(0.0% R42.2) 561-0-381(0.0% R67.2) 536-0-360(0.0% R69.1) 579-0-317(0.0% R104.6) 562-0-334(0.0% R90.4) 470-0-266(0.0% R98.9)
↓条件をこう変えてみる
else if (depth > /*DEPTH_QS_RECAPTURES*/ (Depth)(-7-param1))
stage = QSEARCH_WITHOUT_CHECKS_START;
70.3% 65.9% 72.1% 64.0% 65.3% 64.1% 60.0%
#13
やねうら王nano plus V157b
やねうら王nano plus param1に応じて静止探索のrecapまでの手数変更,1スレッド、0.1秒設定
#0
やねうら王nano plus V157a
やねうら王nano plus 静止探索のオーダリングいじった,1スレッド、0.1秒設定
270-0-114(0.0% R149.8) 244-6-126(0.0% R114.8) 253-1-98(0.0% R164.8) 224-2-126(0.0% R100.0) 226-6-120(0.0% R110.0) 223-4-125(0.0% R100.6) 210-2-140(0.0% R70.4)
■ 2016/02/20 V1.57a
・nano-plusで静止探索の1つ目の深さでは、CAPTURESの指し手を生成するように。(+R180)
・指し手生成に以下の2つを追加
QUIET_CHECKS, // 王手となる指し手(歩の不成などは含まない)で、CAPTURESの指し手は含まない指し手
QUIET_CHECKS_ALL, // 王手となる指し手(歩の不成なども含む)でCAPTURESの指し手は含まない指し手
■ 2016/02/20 V1.57
・nano-plusで静止探索で置換表のlookupをするように。(棋力にほぼ影響なさげ..)
→ これnanoのものに戻してもいいぐらいだな..。静止探索絡みはminiに持ち越すか…。
・置換表でdepthが深いと1byteに収まらないのでONE_PLYで割った値を格納するように変更。
・Depthの定数に色々追加。
■ 2016/02/19 V1.56
・nano-plusにLMRを追加。+R150
・静止探索1手詰め + LMRで +R210ぐらいになるはずだが、実際はnanoからはR+145程度のようだ。
おそらく静止探索1手詰めで強くなっているように見えたのが0.5手延長で強くなるように見えるのと同じ現象で、まやかし。
・local-game-serverでmainスレッド以外がエンジン名を設定しているの危ないので修正。
■ 2016/02/19 V1.55
・nano-plusに静止探索でのみ1手詰めを呼び出すようにした。-R20(long effectの更新分)+R70(1手詰めの効果) = +R50(nanoから)
■ 2016/02/19 V1.54c
・nano-plusで静止探索での1手詰め
{
// 1手詰み
Move m;
if (PvNode && param1)
m = pos.mate1ply();
else
m = MOVE_NONE;
if (m != MOVE_NONE)
return mate_in(ss->ply);
}
・通常探索での一手詰め判定
Move bestMove = MOVE_NONE;
// RootNodeでは1手詰め判定、ややこしくなるのでやらない。
// 置換表にhitしたときも1手詰め判定は行われていると思われるのでこの場合もはしょる
if (!RootNode && !ttHit && (PvNode && param2))
{
bestMove = pos.mate1ply();
if (bestMove != MOVE_NONE)
{
// 1手詰めスコアなので確実にvalue > alphaなはず。
alpha = mate_in(ss->ply);
goto TT_SAVE;
}
}
50.6% 48.7%
56.5% 54.2%
#1
やねうら王nano V140
やねうら王nanoの最終版1スレッド、0.1秒設定
#7
やねうら王nano plus V154c
やねうら王nano plus、1手詰め呼び出し条件の実験,1スレッド、0.1秒設定
2948-0-2876(17.3% R4.3) 2834-0-2990(98.0% R-9.3)
3292-0-2532(0.0% R45.6) 3101-0-2616(0.0% R29.5)
静止探索では無条件で1手詰めを呼ぶのがよさげ。
自己対戦だと0.5手延長みたくなって、勝率が上がっているだけかも知れないが。
・1.54d
// RootNodeでは1手詰め判定、ややこしくなるのでやらない。
// 置換表にhitしたときも1手詰め判定は行われていると思われるのでこの場合もはしょる
if (!RootNode && !ttHit & param1)
{
bestMove = pos.mate1ply();
if (bestMove != MOVE_NONE)
{
// 1手詰めスコアなので確実にvalue > alphaなはず。
alpha = mate_in(ss->ply);
goto TT_SAVE;
}
}
42.0% 54.4%
#1
やねうら王nano V140
やねうら王nanoの最終版1スレッド、0.1秒設定
#8
やねうら王nano plus V154d
やねうら王nano plus、通常探索で1手詰め呼び出すか,1スレッド、0.1秒設定
1397-0-1931(100.0% R-56.2) 1710-0-1432(0.0% R30.8)
→ 呼び出さないほうが強いようだ。
■ 2016/02/18 V1.54
・local server、結果を1行ずつ出力するモード用意。
・local server、finish時に子プロセスのエンジン開放するためにquitコマンドを送信するように変更。
・nano-plusでの実験用にoptionとしてParam1,Param2追加。
■ 2016/02/18 V1.53
・mate1で漏れているケースがあったので修正。
sfen p2g3n1/2gn4g/+P1s1k3s/1ppr2+Lbp/1P1p1K2b/4P1Ppl/3+n1P1RP/LS3p1PL/3P+p2NS w Ppg 160
test rp
Random Player test , loop_max = 100000000
mate found = 10000 , mate miss = 746 , mate found rate = 93.0579%
mate found = 20000 , mate miss = 1460 , mate found rate = 93.1966%
mate found = 30000 , mate miss = 2181 , mate found rate = 93.2227%
mate found = 40000 , mate miss = 2939 , mate found rate = 93.1554%
mate found = 50000 , mate miss = 3759 , mate found rate = 93.0077%
mate found = 60000 , mate miss = 4617 , mate found rate = 92.8548%
mate found = 70000 , mate miss = 5387 , mate found rate = 92.8542%
mate found = 80000 , mate miss = 6204 , mate found rate = 92.8031%
mate found = 90000 , mate miss = 6882 , mate found rate = 92.8965%
mate found = 100000 , mate miss = 7561 , mate found rate = 92.9705%
mate found = 110000 , mate miss = 8327 , mate found rate = 92.9627%
→ 0.2%ほど詰み発見率が上がった。
■ 2016/02/18 V1.52
Position.cppで評価関数を使わないときに
#ifndef EVAL_NO_USE
で囲み忘れていたところがあったので修正。
■ 2016/02/11 V1.51
・コマンドライン引数の複数コマンドの実行機能を追加。fileからの実行機能も追加。
■ 2016/02/10 V1.50
・自己対局サーバー、1スレッド×同時対局(マルチスレッド)に対応させる。goコマンドがThreads数を反映するように。
→ マルチスレッド化した。
■ 2016/02/09 V1.49
・スレッドまわり改修して、協力詰めエンジンがコンパイル通らなくなっていたの修正。
MainThread::searchがvirtualなので単にsearchって書くとthink()が呼び出されてしまうので注意。
次のように書く必要がある。
void MainThread::think() {
for (auto th : Threads.slaves) th->start_searching();
Thread::search();
for (auto th : Threads.slaves) th->wait_for_search_finished();
}
void Thread::search() { HelpMate::id_loop(rootPos, (int)thread_id(), (int)Options["Threads"]); }
■ 2016/02/09 V1.48
・Threadまわり全面的に書き直す。
→ 大改修したら落ちなくなった。やはりそうだったのか…。
→ スレッドまわりがすっきりして気分がいい。
・nanoとminiとビルドしなおしてローカル自己対局。
→ 直ってる気がする。そうか。スレッドまわりだったのか…。
・自己対局のときにコマンドラインではなくファイルから開始コマンドを受け取りたいのでusi.cppを改良。
引数で指定されたものを連結して一つのコマンドとして実行する機能があればいいのか…そうか。
次のような.batファイルを作ってそれを実行すれば連続自己対局が簡単に開始できる。
> local-game-server.exe go btime 500
・解説.txtの説明が古かったので刷新。
・スレッドまわり大改修したのでexeフォルダのnanoのバイナリ差し替え。
・shogi.hからマクロ関係をextra/macros.hに移動。
■ 2016/02/09 V1.47
・あかん。__mm_mallocが失敗する状況において、newも失敗する。これランタイムおかしいのでは…。
revertする。
・Releaseビルド時のランタイムなら落ちない。Debugビルド時のnewでまわり、高負荷時にかち合うと失敗するのでは。
main threadのnewをするタイミングが早すぎてランタイムの初期化が終わっていないことがあるのでは…。
→ main threadのnewは、ThreadPool::init()のなかが最初。これは、main関数のなかのThreads.init()から
呼び出される。ということは、問題なさげ。
そもそも、sizeof(MainThread)==1312しかないのに。
// Tの基底クラスはstd::threadなのでスライシングされて正しく代入されるはず。
*th = std::thread([&] {((T*)th)->idle_loop(); });
// →どうもMSVCのデバッグ用ランタイム、これやるとatomic_boolとかの実装と相まってまずいようだ。
■ 2016/02/09 V1.46
・自動対局サーバー、ときどき3つ目ぐらいのインスタンス走らへん。原因調査。
・自己対局サーバーに子プロセスとの通信ログ出力機能追加。
・Position::material、EVAL_NO_USEのときに参照している箇所があったのでifdefで囲んだ。
・デバッガで再現しない。また、local game server自体が落ちることがある。原因調査。
→ どうも負荷状態において _mm_malloc()が失敗して未初期化のポインターが返ってきているような感じなのだが…。
→ ランタイムが何か共有してて、同時起動時において初期化がされないのではないかな。MSVC、ひどい実装だな。
マルチスレッドデバッグDLLに何かバグがある予感。
→ VSからCtrl+F5連打でこの現象が起きる。
→ _mm_malloc()自前で実装する。
// --------------------
// __mm_malloc(),__mm_free()
// --------------------
// MSVCの__mm_malloc(),__mm_free()が高負荷状態において失敗するので自前で用意。
// 速度的には遅いがそんなに急所でこの関数を呼び出すわけではないので構わない。
// size = 要求メモリ量(byte単位)、align_size = アライメントするサイズ
inline void* my_mm_malloc(size_t size, size_t align_size)
{
const auto ptr_alloc = sizeof(void*); // この分余分に確保して[-1]のところに元のポインターを保存しておく。
size_t request_size = size + align_size;
const auto needed = ptr_alloc + request_size;
auto alloc = ::operator new(needed);
void* alloc2 = (uint8_t*)alloc + ptr_alloc;
auto ptr = std::align(align_size, size, alloc2, request_size);
((void**)ptr)[-1] = alloc;
return ptr;
}
inline void my_mm_free(void* ptr)
{
if (ptr)
{
void* alloc = ((void**)ptr)[-1];
::operator delete(alloc);
}
}
■ 2016/02/09 V1.45
・1手詰め見つけたときにスコアおかしいな。
mate distance pruning入れないと駄目なのか
→ 入れたらなおった..よしよし。
・nano plusにnode stackを導入する。
・nanoとnano plusでbenchでの探索node数が合致するようにする。
nano
===========================
Total time (ms) : 13332
Nodes searched : 13282757
Nodes/second : 996306
nano plus、1手詰めなし、mate distance pruningなし。
===========================
Total time (ms) : 11896
Nodes searched : 10584735
Nodes/second : 889772
→ 合致しない。ソース比較する。
MovePickerが原因としか考えられない。うわー。
MovePicker nanoにものと差し替えたらnode数合致した。
===========================
Total time (ms) : 14328
Nodes searched : 13282757
Nodes/second : 927048
LONG_EFFECTの更新で7%ぐらい遅くなってるのか..これで利きを使わない評価関数だとだいぶ損だな。
ああ、MovePicker、ttMoveと先頭のをswapするのでオーダリング違うのか。そうか。
===========================
Total time (ms) : 11129
Nodes searched : 10584735
Nodes/second : 951094
LONG_EFFECT更新なしにして7%ぐらい上がった。
MovePickerで段階生成にしてるので4%ほど損してるのか。
いまの状況だとほぼall nodeになるので仕方ないか。
・nano plusにkiller move実装したら枝刈り性能あがった気がする。
===========================
Total time (ms) : 3863
Nodes searched : 4850357
Nodes/second : 1255593
bench d 時のdepth上げる。
===========================
Total time (ms) : 12855
Nodes searched : 13773887
Nodes/second : 1071480
・nanoと対局させる。
nano VS nano plus
62-0-38
46-1-53
48-0-52
166-3-131
161-4-135
---------
483/892=0.54
killerで枝刈り効率が上がっているはずだが、LONG_EFFECTの更新の7%と
MovePickerの逐次化による5%ほどとが回収できてないのか…。大変だな。
■ 2016/02/09 V1.44
・benchコマンド追加。
・MAX_DEPTH、設計良くないな。削除。
・これに伴い、nano,nano plusのid_loop、修正。
・benchコマンド完成。
→ nano plusのベンチマーク、異常に悪い件。
===========================
Total time (ms) : 14419
Nodes searched : 11172282
Nodes/second : 774830
・比較用にnanoもベンチが通るように修正する。
nano plusへの修正をbackport
nanoのほう
===========================
Total time (ms) : 13476
Nodes searched : 13282757
Nodes/second : 985660
・nano/nano plusのconfigure、testコマンド、デフォルト有効にしておく。
・nano plus ASSERTなしでbench
===========================
Total time (ms) : 12411
Nodes searched : 11172282
Nodes/second : 900191
めっちゃ変わった。どのASSERTがそんなに重いというのか..わからん。
MATE1外してみる。
===========================
Total time (ms) : 12257
Nodes searched : 10584735
Nodes/second : 863566
探索木変わったのでむしろ増えた。
mate1外してnanoと探索ノード数が同じでないの、おかしい。あとで原因調べる。
mate1、non PVでも有効にして、ASSERTなしにして、nanoと対戦させておく。
non PVでもmate1入れるとnps増えた。mate1で枝刈りされて無駄な指し手生成が端折られたからか？
===========================
Total time (ms) : 5016
Nodes searched : 5955513
Nodes/second : 1187303
nano-nano plus
112-4-84
103-3-94
107-0-93
少しの負け越しで済んだが、やはり何かおかしいな。
benchの探索node数が同じにならないのはバグだろうから、調査する。
■ 2016/02/08 V1.43
・nano plusのMovePickerで段階的な指し手生成を実装。
→ やってみたがnpsほぼほぼ上がってない。(気がする。)
mate1入れたせいもあるのか。
・1手詰め、うまく詰ませられない。
position startpos moves 1g1f 8c8d 7g7f 8d8e 8h7g 7a6b 6g6f 5a4b 2h8h 5c5d 7i7h 4b3b 3i3h 6b5c 5i4h 3c3d 3g3f 5c4d 7h6g 5d5e 4g4f 6a5b 6i5h 7c7d 5h4g 9c9d 1f1e 2b3c 2i3g 8a7c 4h3i 9d9e 3i2h 3c4b 2g2f 8b8d 6f6e 7c6e 7g6f 8d8a 5g5f 5e5f 6g5f 6c6d 4f4e 4d3c P*5d 5b6c 5f5e 3b2b 3g2e 4a3b 3f3e 3d3e 8h5h 8e8f 5e4f 8f8g+ 2e3c 4b3c 6f3c+ 3b3c 5h5i P*5g B*7b 8a8f 7b6c+ 8g7g 6c6d 8f8h+ 6d6e 7g6h 5i5g 8h8i N*2e 3c3b 6e5e N*3c P*3d N*4b 4f3e 8i7i 5d5c+ B*7h 3d3c+ 2a3c 2e3c+ 3b3c N*2e P*3b 5c4c N*3d 4c3c 3b3c 2e3c+ 2b2a G*2b 3a2b
go btime 0 wtime 0 byoyomi 30000000
→ 修正した。
・nano-nono plus
59-1-40
60-1-39
47-2-51
55-5-40
0.56
枝刈りが甘い状況ではmate1にそんなに価値がないのかも。
PV nodeでだけ呼び出すか。
→ 1手詰め判定は通常探索、静止探索ともにPV nodeのみに変更。
もう寝るのでこの条件で2000回対戦させておく。
318-4-178
315-11-174
332-5-163
330-8-162
---------
1295-28-677
0.656
めっちゃ負けてる。おかしい。差分取る。
→ mate1は軽いのでnon PVでも入れたほうがいいということか。
→ MovePickerで遅くなった分、回収できていないのか。
→ bench書く。
・自動対戦サーバー、ときどき3つ目ぐらいのインスタンス走らへん。あとで原因調べる。
■ 2016/02/08 V1.42
・nano plus、1手詰め判定追加。
87-4-109 R35ほどup？大したことないな。枝刈りが甘いからmate見つけてもリターンが小さいんだな。
・config.h、デフォルトではdefineしないことに。
・add_hand(),sub_hand()、inlineにしていると内部コンパイルエラーになるときがあるのでshogi.cppのほうで定義するように変更。
・Depth自体は32bitでいいのでは..
■ 2016/02/08 V1.41
・materialの計算もifndef EVAL_NO_USE内に分離
・clangでコンパイルが通るように。
http://llvm.org/releases/download.html
> Download LLVM 3.7.1
> Clang for Windows (64-bit) (.sig)
LLVM-3.7.1でコンパイルが通るように頑張る。
→ ClangだとAVX関係が色々難しいみたい。gccならいけそうだが…。
gccでコンパイル通すのはまた今度にする。
・これコメントアウト
/*
// 静止探索時の最大探索深さ
const int MAX_QUIET_PLY = 6;
// 通常探索時の最大手数である128に、静止探索時の最大深さを加えた定数。
// 局面バッファ(StateInfo)などは、すべてこのサイズで確保する。
const int MAX_SEARCH_PLY = MAX_PLY + MAX_QUIET_PLY;
*/
・DEPTH_MAXが必要なので修正。
■ 2016/02/08 V1.40
・実行ファイルを配布するにあたって、定跡ファイルを移動させて、評価関数バイナリの置き場を変更する。
将来的に評価関数バイナリを切り替えられるようにする。また、将来的に定跡を複数から選択可能にする。
eval/kpp16ap.bin
eval/kkp32ap.bin
book/standard_book.db
→ exe/YaneuraOu-nano-readme.txtに詳しく書いた。
・やねうら王nano plusの開発開始。
engine/nano-plus-engine追加。
■ 2016/02/07 V1.39
・やねうら王nanoの探索部、少し改良
→ nonPV用の処理を少し書く。
→ そこそこうまく書けた気がする。floodgateに投入しておく。
これでR2000ぐらいになっているならnanoの開発はこれにて終了。
■ 2016/02/07 V1.38
・差分計算時のテスト
isready
position startpos moves 7g7f 8b3b 5i6h 5a6b 2g2f 6b7b 2f2e 3c3d 3i4h 3d3e 8h2b+ 3a2b 2e2d 2c2d 7i7h 5c5d 7h7g 2b2c B*6f B*2b 6f2b+ 3b2b 6h7h 2c3d 4g4f 2d2e 4h4g 2e2f B*6f B*3c 6f3c+ 2a3c 4i3h B*4i B*5f 3d2e 4g5h 4i5h+ 6i5h S*5e B*1e 4a3b 5f4g 5e4f 4g5f 5d5e
go btime 10000000
info depth 8 score cp -1502 nodes 16874114 nps 1063204 hashfull 420 time 15871 pv 5f6e 1c1d 1e3c+ 3b3c 3g3f B*4i 5h6h 2e3f
// 差分計算なし。
info depth 8 score cp -1502 nodes 16874114 nps 896414 hashfull 420 time 18824 pv 5f6e 1c1d 1e3c+ 3b3c 3g3f B*4i 5h6h 2e3f
17%ぐらいnps up!!
計算合った。これで良し。
・EVAL_KPP、差分計算、実装完了。
・read_book()、デバッグ中だったの戻した。
・DirtyPiece型導入。
・StateInfoからkingSquare除く。
■ 2016/02/07 V1.37
・Eval::compute_eval()で全計算して初期化する。
・差分で遡るの1局面前までに限定する。
・差分計算デバッグ中。
・README.md、整形
■ 2016/02/07 V1.36
・KPP評価関数の差分計算まわり。
・StateInfoにdirtyPiece追加。
・Eval/evaluate_kpp分離
・Eval/evaluate_bona_piece分離
・shogi.hのほうに
int hand_count(Hand hand, Piece pr) { ASSERT_LV2(PIECE_HAND_ZERO <= pr && pr < PIECE_HAND_NB); return (hand >> PIECE_BITS[pr]) & PIECE_BIT_MASK[pr]; }
int hand_exists(Hand hand, Piece pr) { ASSERT_LV2(PIECE_HAND_ZERO <= pr && pr < PIECE_HAND_NB); return hand & PIECE_BIT_MASK2[pr]; }
を書くと内部コンパイルエラーになるのでshogi.cppのほうに移動。
・EVAL_KPPのevaluateに差分計算追加。
・kingSquare、StateInfoに移動させる。
■ 2016/02/06 V1.35
・nanoのid_loopまわり、ちょっと整理した。
■ 2016/02/06 V1.34
・定跡DBの読み書き、std::mapではなくstd::unorder_mapを使うように変更。
■ 2016/02/05 V1.33
・定跡ファイルに定跡フォーマットのバージョン識別文字列を追加。
■ 2016/02/05 V1.32
・定跡にその指し手が採択された回数の項目を追加。
・nanoで定跡の指し手に関して、採択確率を出力するようにした。(将棋所ではこれでうまく表示される)
■ 2016/02/05 V1.31
・extra/book.hとcpp追加。
・test_cmd.cppから移動。
・bookの読み込み、書き込み等の操作を細かくして追加。
・read_all_lines()でエラーのときに1を返すように。
・nanoの定跡にbook.dbを用いるように変更した。
■ 2016/02/05 V1.30
・定跡部、何かフレームワークからのサポートを考える。
→ 考えた。解説に書いた。nano以外ではこれを使うことにする。
・read_all_lines()、空行はskipするように。
・makebookコマンド、sfen→db変換実装した。
・doc/nano-book.db削除。
・doc/book.db追加。
■ 2016/02/05 V1.29
・nanoの秒読み時の使用時間、もう少し少なくしないとtime upになるので修正。
・USIオプションに"NetworkDelay"追加。
・YaneuraOuMini_ja.txt → YaneuraOu_ja.txtにリネーム
バイナリは全部YaneuraOu.exeでいいや。
■ 2016/02/04 V1.28
・nano、floodgateに放流している人を見るとR1700ぐらいらしい。もう少しチューンする。
・nanoの静止探索で王手がかかっているならalpha = -VALUE_INFINITEにして、
あと静止探索の延長は3手までにする。
→ 少し強くなった気が。
・nanoの静止探索の指し手生成、RECAPTURESからCAPTURES_PRO_PLUSに変更してみる。
→ 弱くなった。
・Position::is_ok()にcheckesの検証を追加。
・CAPTURES_PRO_PLUSで歩の成りに自駒のある場所を除外していなかったのを修正。
position startpos moves 2g2f 3c3d 7g7f 8c8d 2f2e 1c1d 2e2d 2c2d 2h2d
go btime 169000 wtime 17100000 byoyomi 0
・検証用のコード
for (auto p = currentMoves; p != endMoves; ++p)
if (!pos.pseudo_legal(*p))
{
cout << pos << *p;
for (auto m : MoveList<CAPTURES_PRO_PLUS>(pos))
cout << m.move << " ";
}
・nanoに定跡追加。
→ 序盤、少しだけマシになった。
・misc.h/cppにread_all_lines()追加。
・プロジェクトのdoc/nano-book.sfen追加。
・対局中おかしかった局面のテスト
position startpos moves 7g7f 8b3b 5i6h 5a6b 2g2f 6b7b 2f2e 3c3d 3i4h 3d3e 8h2b+ 3a2b 2e2d 2c2d 7i7h 5c5d 7h7g 2b2c B*6f B*2b 6f2b+ 3b2b 6h7h 2c3d 4g4f 2d2e 4h4g 2e2f B*6f B*3c 6f3c+ 2a3c 4i3h B*4i B*5f 3d2e 4g5h 4i5h+ 6i5h S*5e B*1e 4a3b 5f4g 5e4f 4g5f 5d5e
go btime 10000000
・nanoの通常探索の指し手生成、CAPTURESさきに生成すると枝刈り性能が上がるはず。→ 少し強くなった。
・あと探索の並列化と評価関数の差分更新をやるとR200ぐらい上がるかも。
・2016年1月の作業メモから完了分
【完了】・1手詰め判定ルーチン、影の利きを考慮した詰み
【完成】・1手詰め判定ルーチン、打ちと移動による簡単な詰み
【完成】・undo_move()で利きの差分更新処理(戻す処理)、実装完了。ランダムプレイヤーによる自動テストをpassした。
【完成】・do_move()での利きの差分更新処理が正しいかをランダムプレイヤーによる自動テストにより確認。
【完成】・Position::do_move()のときのcaptureとnon_captureのときの利きの差分更新処理
【完成】・Position::do_move()のdropのときの利きの差分更新処理
【完成】・Long Effect Library
【完成】・利きの初期化処理
【完成】・自動対局サーバーの開始局面のランダマイズ機能
【完成】・自動対局サーバー機能、書けた。
【完成】・32bit環境用のコード、ちゃんと動くようになった。(手元に32bit環境がないので実際の環境で試してはいない。)
■ 2016/02/01 V1.27
・mate1plyで漏れているケースをいくつか修正。
sfen 1nk3G2/l4+RGb1/s1p5l/n2p3pp/1p1PP4/4KPPP1/NPP1S3P/LR3ppGL/B2+p+n1S2 b 2PSG 123
→詰むようになった。0.1%ほど詰み発見率が上がった。
sfen +P1+Lg1S+P1b/+P2k4p/1N1l1+R2n/1LG1Gp2L/S5p2/1PPP1g1p1/B3R3n/pp2+n1KsP/1S4P2 b 2P2p 203
→詰むようにした。0.2%ほど詰み発見率が上がった。
・USI拡張コマンドとして"mate1"コマンド追加。
test rp
Random Player test , loop_max = 100000000
mate found = 10000 , mate miss = 793 , mate found rate = 92.6526%
mate found = 20000 , mate miss = 1524 , mate found rate = 92.9195%
mate found = 30000 , mate miss = 2257 , mate found rate = 93.0031%
mate found = 40000 , mate miss = 3035 , mate found rate = 92.9476%
mate found = 50000 , mate miss = 3877 , mate found rate = 92.804%
mate found = 60000 , mate miss = 4764 , mate found rate = 92.6441%
mate found = 70000 , mate miss = 5544 , mate found rate = 92.6612%
mate found = 80000 , mate miss = 6376 , mate found rate = 92.6183%
mate found = 90000 , mate miss = 7079 , mate found rate = 92.708%
mate found = 100000 , mate miss = 7795 , mate found rate = 92.7687%
mate found = 110000 , mate miss = 8561 , mate found rate = 92.7792%
mate found = 120000 , mate miss = 9318 , mate found rate = 92.7945%
■ 2016/02/01 V1.26
・static const排除。実行ファイルのサイズが20KBほど縮んだ。
悪い影響はなさそうなのでこれでいく。
・Recaptureの指し手生成器、作る。
・movegenの指し手生成、選択式のするのやめる。どうせ呼び出していなければリンカーで削除される。
・NON_EVASIONS_ALL追加。
→ 呼びださなければ実行ファイル、1バイトも増えない。よしよし。
・nanoの静止探索、RECAPTURESを使って書き換え。
■ 2016/01/31 V1.25
・nanoの静止探索、standPatと比較するの忘れてた。修正。
→ 修正したら少し強くなった感。
■ 2016/01/31 V1.24
・評価値、局面の差分更新をしたときにおかしくなるので、駒番号まわりのテストコード追加する。
→ 難しい。書きにくい。
・BonaPieceの文字列での出力関数実装
・evalstatにPieceListの内容を表示、追加。
・test rpコマンドのランダムプレイヤーに評価値の差分計算のチェック機構追加。
・undo_move()で駒番号おかしくなっていたの修正。
・mateのときの手数表示がおかしいの修正。
■ 2016/01/31 V1.23
・nanoのデバッグ進める。
・USI::score_to_usi()追加
・USI::pv()追加。
・評価関数の値がおかしい気がしなくもない。
・sfenコマンド追加。(以前のものを変更)
■ 2016/01/31 V1.22
・nanoにはsee使わない。
・nanoの静止探索書く。
・nanoにid_loop導入。
・TanspositionTableにvalue_to_tt()とか追加する。
・goコマンドのデフォルトを秒読み1秒にしておく。(テストしにくいので)
・USI::Optionのコンストラクタで、on_changeのイベントハンドラを呼び出すように変更。
→ この設計だと駄目なのか。仕方ないので置換表のコンストラクタでデフォルト16MB確保する。
・USI::pv()追加。読み筋表示用。
■ 2016/01/30 V1.21
・Position::sse()追加。
・extra/see.cpp追加。
・USE_SEE追加。
■ 2016/01/29 V1.20
・評価関数、旧バージョンと値の比較。
・EvalList::set_piece修正。
position sfen lnsgkgsnl/1r5b1/pppppppp1/9/9/2P5p/PP1PPPPP1/LB5R1/1NSGKGSNL w p 8
■ 2016/01/27 V1.19
・やねうら王nanoとminiの探索部書いていく。
・評価関数のimportしてくるところから。
→ だいたい出来た気がする
・put_pieceで落ちる。
→ 王手がかかっているのにEVASIONS呼び出さなかったからか。
> position startpos moves 3i4h 3c3d
> position startpos moves 7g7f 3c3d 8h2b
evalおかしい。何これ。
■ 2016/01/27 V1.18
・Bitobardのoperator == () がまさかの高速化。これ、そもそもほとんど使ってないのであまり変わらんが…。
■ 2016/01/25 V1.17
・ByteBoard、WordBoard、無理やり取ってくるなら端にpaddingしといたほうが無難か…。
■ 2016/01/24 V1.16
・1手詰めに影の利きを考慮した詰みも追加。
・1手詰めで漏れているケースもう少し追加する。
・uint8_t -> u8とかtypedefする
・24近傍の9近傍への長い利きを回収するコード追加。
・mate1plyの移動による詰みをlambdaに変更。
・1手詰め判定で影の利き考慮するようにした。
test rp
Random Player test , loop_max = 100000000
mate found = 10000 , mate miss = 827 , mate found rate = 92.3617%
mate found = 20000 , mate miss = 1590 , mate found rate = 92.6355%
mate found = 30000 , mate miss = 2354 , mate found rate = 92.7242%
mate found = 40000 , mate miss = 3190 , mate found rate = 92.614%
mate found = 50000 , mate miss = 4072 , mate found rate = 92.4693%
mate found = 60000 , mate miss = 5015 , mate found rate = 92.2864%
mate found = 70000 , mate miss = 5822 , mate found rate = 92.3215%
mate found = 80000 , mate miss = 6704 , mate found rate = 92.2679%
mate found = 90000 , mate miss = 7435 , mate found rate = 92.3693%
mate found = 100000 , mate miss = 8202 , mate found rate = 92.4197%
mate found = 110000 , mate miss = 8984 , mate found rate = 92.4494%
詰み率 92%ちょいぐらいになった。8%ぐらいが影の利きありでの1手詰めなのか。
ランダムプレイヤーで数時間まわしておく。
→ 1.6億局面をpassしたのでうまく動いてるやろ…。
■ 2016/01/23 V1.15
・dirs_bw_of()→long_effect_ofとリネーム
・mate1plyの判定率、ランダムプレイヤーで計測できるようにした。
Random Player test , loop_max = 100000000
mate found = 10000 , mate miss = 28848 , mate found rate = 25.7414%
mate found = 20000 , mate miss = 58089 , mate found rate = 25.6118%
mate found = 30000 , mate miss = 87252 , mate found rate = 25.5859%
mate found = 40000 , mate miss = 116252 , mate found rate = 25.5997%
mate found = 50000 , mate miss = 146594 , mate found rate = 25.4331%
mate found = 60000 , mate miss = 176384 , mate found rate = 25.3824%
mate found = 70000 , mate miss = 206668 , mate found rate = 25.3011%
mate found = 80000 , mate miss = 237090 , mate found rate = 25.2294%
→ おかしい。低すぎ。
・移動による詰み、駒打ち用のdirectionsテーブルではまずいのか…。修正した。
test rp
Random Player test , loop_max = 100000000
mate found = 10000 , mate miss = 1590 , mate found rate = 86.2813%
mate found = 20000 , mate miss = 3134 , mate found rate = 86.4528%
mate found = 30000 , mate miss = 4722 , mate found rate = 86.4006%
mate found = 40000 , mate miss = 6296 , mate found rate = 86.4006%
mate found = 50000 , mate miss = 7953 , mate found rate = 86.2768%
mate found = 60000 , mate miss = 9620 , mate found rate = 86.1821%
mate found = 70000 , mate miss = 11028 , mate found rate = 86.3899%
mate found = 80000 , mate miss = 12651 , mate found rate = 86.3455%
mate found = 90000 , mate miss = 14175 , mate found rate = 86.3931%
mate found = 100000 , mate miss = 15725 , mate found rate = 86.4118%
→ だいぶ上がった。もう少し上がって欲しい気が。
■ 2016/01/23 V1.14
・do_move()に関するベンチが要るな。
test rpbenchコマンド追加。書けた。4600 games/sec程度。
1局が大抵256手まで行くことを考えると256×4600回の指し手生成 + do_move()/undo_move()だから妥当なところ？
ASSERT、long_effectオフにしたら6327 gps
long_effectだけオフにしたら5909gps
ASSERTだけオフにしたら4959 gps。
・ASSERTで5%ほど低下。long_effectは探索部と評価関数がなしだとすると30%ぐらい低下ということなのかな。
・Effect8に各駒の利き追加する
・1手詰め作っていく。
・UnitTestにMate1Ply関連のテストコード追加。
・HAND_KIND_ZERO追加。
・PRO_GOLD→QUEENに変更してeffects_fromにQUEEN追加。
・effects_fromにNO_PIECEのときの処理追加。
・駒打ちによる1手詰め判定できるようになった。
・桂の移動による1手詰め判定できるようになった。
・銀の移動による1手詰め判定うまく動いた。
・ランダムプレイヤーで1手詰め判定の自動テストするコードを追加。
・pseudo_legal()で金の成る手のチェックが抜けていたのを修正。
・1手詰めでの大駒による長い利きの遮断修正。
・1手詰めで桂打ちで利きを遮断するケース考慮。
・ランダムプレイヤーでランニング。動いているようだ。
■ 2016/01/22 V1.13
・undo_move()で戻す処理に利きを戻す処理も書くことにする。たぶん、そんなに遅くないはずで…。
・undo_move()も先後分けた。
・LongEffectLibraryに利きの更新の逆変換関数追加。
・ランダムプレイヤーで利きのrevertのテスト。
このまましばらくランニングさせておく。
・関数の名前revertでなくrewindにしよう。
・Position::set_effect、LongEffect::に移動。
■ 2016/01/22 V1.12
・captureとnon_captureのときの利きの更新処理追加。
→ これで利きの更新処理は一通り書けた。あとは…
・ランダムプレイヤーによる利きの更新の自動テスト追加。
・UNREACHABLE、ASSERT_LV3に変更。
・undo_moveで利きを巻き戻す作業がいるのか..これは難しい..
・LSB32/64にASSERT_LV3追加。
・利きのdo_move()での更新はこれで問題なさげ。undo_move()をどうするか考え中。
■ 2016/01/22 V1.11
・長い利き、WordBoardでないとまずいのか…。書き直し。
・make_piece()引数の順番変更。Colorをつねに先に。
・ENABLE_BIT_OPERATORS_ONに operator &= などを追加。
・WordBoardの表示修正。
・利きの初期化部、マクロいくつか削除。
・LongEffect::dir_bw_of()追加。
・Directionsのenumに定数追加。
・Position::do_move()のdropのときの利きの更新処理書けた。
あとはcaptureとnon_captureのときの利きの更新処理！
■ 2016/01/21 V1.10
・has_long_effect()追加。
・↑をUnitTestに追加。
・UPDATE_EFFECT_BY_PUTTING_PIECE、マクロ化した。(利きの差分更新のところでも使うため。)
・LONG_EFFECTにINCもDECも要らんかった。一つにまとめた。
・Direction削除。Effect8のものを持ってきて、これを使うことにする。
・SQWW_RIGHT→SQWW_Rとかにリネーム。
・Position::do_move()を内部的に、先後分ける。
・pop_lsb(uint8_t)追加。
・pop_directionsの引数変更。
・ENABLE_BIT_OPERATORS_ON追加。
・Directionsにbegin(),end()追加。
→ あかん。よくなかった。削除。
・pop_lsb()をbitop.hに移動。templateで書くことにした。
■ 2016/01/20 V1.09
・Effect8::directions_of()追加。
・長い利きの初期化コード書けた。→ 正しそう。
・ByteBoardの出力関数書いた。
・MAX_PLY_ → MAX_PLY_NUMにリネーム。
・LONG_EFFECT→LONG_EFFECT_LIBRARYにリネーム。
・long_effect.h/cpp、ifdef LONG_EFFECT_LIBRARYで囲った。
■ 2016/01/19 V1.08
・user.cpp、わかりにくいのでuser-engine.cppにリネーム。
・Positionクラスに利きを持たせる。
・利きの初期化コードおよび差分更新コードを追加する。
・Position::set_effect()書いた。
・評価関数、shogi.hで選択可能にする。(まずは準備だけ)
・config.h、書式整えた。
■ 2016/01/19 V1.07
・SquareWithWall追加。これを使って利き関係の初期化処理を書き直す。
・dist、これがあれば不要？ → 不要ではなかった。
・LongEffectライブラリにSquareWithWallの差分値追加。
■ 2016/01/19 V1.06
・aligned_stack、内部的にvectorを使うように変更。
■ 2016/01/19 V1.05
・std::stack<StateInfo>を用いるときにpush()に対して内部的にstackがStateInfoをnewするのだが
これがalignmentされてなくてまずいのか…。そんな問題があるのか…。
→ StateInfoにcustom new/delete追加。
// custom allocator(このクラスはstd::stack<StateInfo>のpush()によって内部的にnewされるが、そのときに
// alignasが無視されるので、custom allocatorが必要になる…ようだ。)
static void* operator new (std::size_t count){ return _mm_malloc(count,alignof(StateInfo)); }
static void operator delete(void* p) { _mm_free(p); }
→ これでも駄目なのか。難しい…。
// C++11では、std::stack<StateInfo>がalignasを無視するために、代わりにstack相当のものを自作。
template <typename T> struct aligned_stack {
void push(const T& t) { auto ptr = (T*)_mm_malloc(sizeof(T), alignof(T)); *ptr = t; container.push(ptr); }
T& top() const { return *container.top(); }
~aligned_stack() { while (container.size()) { auto ptr = container.top(); _mm_free(ptr); container.pop(); } }
private:
std::stack<T*> container;
};
こうしてみた。
■ 2016/01/19 V1.04
・engine/mate-engine/ 追加。このあとコードを書いていく。
■ 2016/01/19 V1.03
・自動対局フレームワークの開始局面をランダマイズする機能追加。
→ 定跡を読み込めるようにした。
■ 2016/01/19 V1.02
・move_from_usi()に合法チェック追加。
・連続自動対局フレームワーク、一通り動くようになった。
→ 対局開始局面のrandomize出来たほうがいいので何か考える。
■ 2016/01/18 V1.01
・連続自己対戦サーバー用のProcessNegotiatorで入出力のリダイレクトは出来るようになった。
あとはこれを非同期入出力にして連続自己対局が出来るようにすればOk.
■ 2016/01/18 V1.00
・連続自己対戦サーバー機能追加作業開始。
engine/local-game-server
・"Version"がwindows.hの内部の文字列と衝突した。"ENGINE_VERSION"にリネーム。
・_mm_malloc()～_mm_free()を使うように変更。
■ 2016/01/18 V0.99
・bitop.hとkey128.hのコメント掃除。
■ 2016/01/18 V0.98
・128bit hash keyを用いるときにalignmentが合ってないエラーがでうるのを修正。
■ 2016/01/18 V0.97
・x86で正常動作するようになった。指し手生成とか半分ぐらいの速度しか出ないが…。
・aligned_allocをbitop.hに移動させた。
■ 2016/01/18 V0.96
・size_t、x86環境だと32bitなのか…。ランダムプレイヤー修正。
・ランダムプレイヤー、GitHubにpushするの忘れてたので追加。
■ 2016/01/18 V0.95
・x86用のコード、allocatorだけ追加しておく。
・USE_AVX2をコメントアウトしたときにコンパイルが通らなくなっていたの修正。
■ 2016/01/18 V0.94
・Stockfishの升の差分を表現するDELTA_Nとか読みにくくてカナワンので、SQ_UPとかに変更。
■ 2016/01/18 V0.93
・engine関係、ひとつのフォルダにまとめる
・ランダムプレイヤーをengineとして追加。
・とりあえず、ビルドのデフォルトをランダムプレイヤーにしておく。(やねうら王miniの探索部が書けたらそれをデフォルトに変更する)
・StateInfo,Positionクラスのアライメントの調整をしたせいか、指し手生成が少し速くなったようだ。指し手生成祭りの局面で5.4M回/s程度(Core i7 4771にて)
・PRNGクラス、少しメンバー追加した。
■ 2016/01/18 V0.92
・x86用にコード修正。コンパイルは通るようになったが、Bitboardの代入等で落ちる。(アライメント合ってないから？)
コンパイル時に、こんな警告。
> source\thread.cpp(15): warning C4316: 'MainThread': ヒープで割り当てられたオブジェクトが 16 にアラインメントされていない可能性があります
→ thread.cppのnewしているところでaligned_new<T>()みたいなものが必要っぽいのだが、これを修正しても
ランタイムで落ちるようだ。よくわからんので誰か助けて欲しい…。
・よく考えるとKey256を使う場合も_mm256_store_si256()が32byteでアライメントされていることを要求するから、
これと同じ問題があるのか…。誰も使ってないだろうからそっちはまあいいか…。
■ 2016/01/17 V0.91
・x86用のemulation code、各種追加。
■ 2016/01/17 V0.90
・GitHubにて公開。