-
-
Notifications
You must be signed in to change notification settings - Fork 140
やねうら王の更新履歴2023
Total time (ms) : 60011 Nodes searched : 1504398679 Nodes_searched/second : 25068715 Nodes searched (main thread) : 18878902 Nodes searched/second(main thread) : 314590
The bench command has completed.
Total time (ms) : 60019 Nodes searched : 4604496403 Nodes_searched/second : 76717312 Nodes searched (main thread) : 35978440 Nodes searched/second(main thread) : 599450
The bench command has completed.
⇨ ちょうど3倍ぐらいの性能。
-
HaoとLiとの比較検証
engine1 = YaneuraOuNNUE_V777_avx2.exe , eval = hao engine2 = YaneuraOuNNUE_V777j4_1024.exe , eval = Li T2,b1000,3200 - 126 - 2614(55.04% R35.14[27.61,42.67]) winrate black , white = 51.81% , 48.19% T2,b2000,1333 - 86 - 1181(53.02% R21.03[9.62,32.45]) winrate black , white = 54.26% , 45.74% T2,b4000,499 - 33 - 428(53.83% R26.66[7.85,45.48]) winrate black , white = 52.0% , 48.0% T2,b4000,508 - 34 - 408(55.46% R38.08[19.1,57.07]) winrate black , white = 51.97% , 48.03% T2,b4000,490 - 51 - 409(54.51% R31.39[12.26,50.52]) winrate black , white = 53.73% , 46.27% T2,b4000,524 - 39 - 407(56.28% R43.89[25.02,62.76]) winrate black , white = 50.16% , 49.84% 2021 - 157 - 1652 (55.05%) R35.02
やねうらお — 今日 13:31
2スレ4秒で3671局回しました。4台でやったので手で集計します。
T2,b4000,499 - 33 - 428(53.83% R26.66[7.85,45.48]) winrate black , white = 52.0% , 48.0%
T2,b4000,508 - 34 - 408(55.46% R38.08[19.1,57.07]) winrate black , white = 51.97% , 48.03%
T2,b4000,490 - 51 - 409(54.51% R31.39[12.26,50.52]) winrate black , white = 53.73% , 46.27%
T2,b4000,524 - 39 - 407(56.28% R43.89[25.02,62.76]) winrate black , white = 50.16% , 49.84%
⇓集計結果
2021 - 157 - 1652 (55.05%) R35.02
Haoの方が+R35.02高かったです。1秒と変わらない感じ。2秒の方は回数が少なかったのか、たまたまなのか、まあ、そんな感じ。
結論的には、やねうら王の互角局面からだとHaoの方が強いのではないかということになりました。初期局面まわりだとLiの方が優れてる気はするんですけどねぇ…。😟
engine1 = YaneuraOuNNUE_V777_avx2.exe , eval = Haojian_231225 engine2 = YaneuraOuNNUE_V777_avx2.exe , eval = hao T2,b1000,2705 - 248 - 2717(49.89% R-0.77[-8.53,6.99]) winrate black , white = 51.44% , 48.56%
engine1 = YaneuraOuNNUE_V777_avx2.exe , eval = HaojianQPD_231227 engine2 = YaneuraOuNNUE_V777_avx2.exe , eval = hao T2,b1000,1710 - 211 - 4119(29.34% R-152.72[-160.94,-144.5]) winrate black , white = 51.31% , 48.69%
V7.77j4
- V7.77j2より。evaluate_with_no_returnに書き換えてみる。
if (!evaluated) { Eval::evaluate_with_no_return(pos); evaluated=true;}
pos.do_move(move, st);
こういう感じのコード。
engine1 = YaneuraOuNNUE_V777j3_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V777j4_1024.exe , eval = Li T2,b2000,833 - 83 - 914(47.68% R-16.12[-29.8,-2.44]) winrate black , white = 51.69% , 48.31% ⇨ なしよりはあったほうが良さそう。
engine1 = YaneuraOuNNUE_V777a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V777j4_1024.exe , eval = Li T2,b1000,1710 - 158 - 1902(47.34% R-18.49[-28.01,-8.96]) winrate black , white = 51.61% , 48.39% T2,b2000,865 - 108 - 927(48.27% R-12.03[-25.53,1.48]) winrate black , white = 51.51% , 48.49% ⇨ 強いっぽいので、j4をV778とする。
engine1 = YaneuraOuNNUE_V777j2_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V777j4_1024.exe , eval = Li T2,b1000,1806 - 144 - 1910(48.6% R-9.73[-19.1,-0.35]) winrate black , white = 49.84% , 50.16% T2,b2000,1711 - 197 - 1772(49.12% R-6.09[-15.77,3.6]) winrate black , white = 52.08% , 47.92% T2,b4000,406 - 56 - 428(48.68% R-9.17[-28.95,10.62]) winrate black , white = 53.0% , 47.0%
engine1 = YaneuraOuNNUE_V777j3_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V777j4_1024.exe , eval = Li T2,b1000,2079 - 164 - 2207(48.51% R-10.38[-19.11,-1.65]) winrate black , white = 51.98% , 48.02%
V7.77j3
- V7.77j2より。evaluatedのコード削除。
engine1 = YaneuraOuNNUE_V777j2_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V777j3_1024.exe , eval = Li T2,b1000,1279 - 106 - 1145(52.76% R19.23[7.6,30.85]) winrate black , white = 51.2% , 48.8% T2,b2000,3008 - 324 - 2988(50.17% R1.16[-6.22,8.54]) winrate black , white = 52.64% , 47.36% T2,b4000,1179 - 171 - 1090(51.96% R13.63[1.63,25.64]) winrate black , white = 53.68% , 46.32% ⇨ やはり、効果自体はありそうなんだけどなー。 ⇨ j2にrollbackして、evaluate_with_no_returnに書き換えてみるか…。
V7.77j2
if (is_ok((ss - 1)->currentMove) && !(ss - 1)->inCheck && !priorCapture)
{
int bonus = std::clamp(-13 * int((ss - 1)->staticEval + ss->staticEval), -1652, 1546);
// int bonus = std::clamp(-14 * int((ss - 1)->staticEval + ss->staticEval), -1449, 1449);
// この右辺の↑係数、調整すべきだろうけども、4 Eloのところ調整しても…みたいな意味はある。
ここ⇑だけ、V7.77gにしてみる。
engine1 = YaneuraOuNNUE_V777j1_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V777j2_1024.exe , eval = Li T2,b1000,4723 - 395 - 4882(49.17% R-5.75[-11.58,0.08]) winrate black , white = 52.05% , 47.95% T2,b2000,3020 - 312 - 3018(50.02% R0.12[-7.24,7.47]) winrate black , white = 52.4% , 47.6% ⇨ 検知できない差。j2にしておく。
V7.77j1 V7.77gの内容を順番に反映させてレーティングに一番影響する部分を探す。
- ⇓ここ変更。ここ以外はパラメータっぽいし。
// Decrease/increase reduction for moves with a good/bad history (~25 Elo)
r -= ss->statScore / (10216 + 3855 * (depth > 5 && depth < 23));
⇓
// Decrease/increase reduction for moves with a good/bad history (~25 Elo)
r -= ss->statScore / 14767;
⇑この変更、やはり悪そう。rollbackする。
engine1 = YaneuraOuNNUE_V777i4_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V777j1_1024.exe , eval = Li T2,b1000,4884 - 366 - 4750(50.7% R4.83[-0.99,10.66]) winrate black , white = 51.17% , 48.83% T2,b2000,2346 - 248 - 2246(51.09% R7.57[-0.87,16.0]) winrate black , white = 52.64% , 47.36%
■ MaxMovesToDraw と 連続王手の反則の組み合わせ
やねうら王で最大手数引き分けを設定する MaxMovesToDraw を 256に設定しているとする。
仮に、この最大手数で引き分けがないとして考えた時に、257手目で連続王手の反則が成立する時は、257手目の局面は送られてこないことになる。257手目の局面が送られてこないならば、最大手数での引き分けは成立していないというのが、shogi-serverによる最大手数による引き分けの解釈なので、つまりは、やねうら王のこの部分の処理は間違っていることになる。
// 最大手数の判定
if (pos.game_ply() > Limits.max_game_ply)
{
/*
連続王手の千日手で MaxMovesToDraw + 1手目にこの局面に到達している場合は、この局面の手番側が指す前に
反則が成立しているので、(最大手数での引き分けがないとしても)shogi-serverからはこの局面自体が送られてこない。
shogi-serverは、このような条件で判定しているので、MaxMovesToDraw + 1手目において
a. 連続王手の反則負け/勝ちが成立している
b. 詰まされている
のいずれかの場合は、そういうスコアを返さなければならない。
*/
auto draw_type = pos.is_repetition(ss->ply);
if (draw_type == REPETITION_WIN || draw_type == REPETITION_LOSE)
return value_from_tt(draw_value(draw_type, pos.side_to_move()), ss->ply);
return pos.is_mated() ? mated_in(ss->ply) : draw_value(REPETITION_DRAW, pos.side_to_move());
}
- TTcluster 4と3の比較
1024MBで10Mn読ませているのでその1/50の20MBで1/50である200kn読ませるのとは同じバランス。 USI_Hash 20MBと10MBで比較する。 ⇨ 省メモリであるほど影響があるかと思ったら、hash衝突して、cl3のほうが成績悪いな…。
USI_Hash 21MB engine1 = YaneuraOuNNUE_V777i4_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V777i4_1024_cl3.exe , eval = Li T2,b1000,501 - 40 - 499(50.1% R0.69[-17.37,18.76]) winrate black , white = 51.9% , 48.1% ⇨ 変わらず..
USB_Hash 10MB engine1 = YaneuraOuNNUE_V777i4_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V777i4_1024_cl3.exe , eval = Li T2,b1000,1796 - 148 - 1786(50.14% R0.97[-8.58,10.52]) winrate black , white = 51.79% , 48.21%
USB_Hash 10MB vs 20MB engine1 = YaneuraOuNNUE_V777i4_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V777i4_1024.exe , eval = Li T2,b1000,1508 - 112 - 1660(47.6% R-16.68[-26.85,-6.52]) winrate black , white = 51.74% , 48.26% ⇨ 有意に差があるな…。
USI_Hash 20MB vs 40MB engine1 = YaneuraOuNNUE_V777i4_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V777i4_1024.exe , eval = Li T2,b1000,1305 - 112 - 1263(50.82% R5.68[-5.59,16.96]) winrate black , white = 50.55% , 49.45% ⇨ こっちは計測できない差
engine1 = YaneuraOuNNUE_V777a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V777i4_1024.exe , eval = Li T2,b4000,1436 - 220 - 1454(49.69% R-2.16[-12.79,8.47]) winrate black , white = 53.7% , 46.3%
- やねうら王のREADME.mdに情報追記。
Total time (ms) : 60021 Nodes searched : 2961837883 Nodes_searched/second : 49346693 Nodes searched (main thread) : 22894876 Nodes searched/second(main thread) : 381447
The bench command has completed. ⇨ 2698 dual, 3.1 台分ぐらいか..
Total time (ms) : 60054 Nodes searched : 953117472 Nodes_searched/second : 15871007 Nodes searched (main thread) : 11879596 Nodes searched/second(main thread) : 197815
The bench command has completed.
V7.77i4
eval = ss->staticEval = evaluate(pos);
evaluated = true;
こっちのほうがいい可能性あるか…。
engine1 = YaneuraOuNNUE_V777h_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V777i4_1024.exe , eval = Li T2,b1000,2112 - 194 - 2264(48.26% R-12.07[-20.72,-3.43]) winrate black , white = 53.38% , 46.62% ⇨ これ自体は効果ありそうなんやけどなー。
全体としてつよなってるのかどうかがわからん…。なぜなのか…。 計測やりなおしたほうがいいと思う…が、時間ないので今回はここまで。
この改良、短い時間では影響しない可能性もあるか…。
engine1 = YaneuraOuNNUE_V777a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V777i4_1024.exe , eval = Li T2,b1000,1787 - 127 - 1776(50.15% R1.07[-8.5,10.65]) winrate black , white = 51.39% , 48.61% T2,b2000,1037 - 107 - 1096(48.62% R-9.61[-21.99,2.76]) winrate black , white = 50.63% , 49.37% T2,b2000,772 - 97 - 811(48.77% R-8.56[-22.93,5.8]) winrate black , white = 53.32% , 46.68% T2,b2000,803 - 78 - 809(49.81% R-1.29[-15.52,12.94]) winrate black , white = 55.58% , 44.42% T2,b4000,171 - 31 - 178(49.0% R-6.97[-37.53,23.59]) winrate black , white = 54.15% , 45.85% // 2秒でつよなってそうではある。
engine1 = YaneuraOuNNUE_V777i3_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V777i4_1024.exe , eval = Li T2,b1000,4845 - 368 - 4787(50.3% R2.09[-3.73,7.91]) winrate black , white = 52.52% , 47.48% T2,b2000,2334 - 228 - 2388(49.43% R-3.97[-12.29,4.34]) winrate black , white = 51.57% , 48.43% ⇨ なぜかi4の方が良さそう…。計測できない差。
V7.77i3
- evaluate()、呼んでなかったところ呼ぶように変更。
eval = ss->staticEval;
evaluated = true;
⇓ここ、条件まちごてた。修正する。
eval = ss->staticEval;
engine1 = YaneuraOuNNUE_V777h_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V777i3_1024.exe , eval = Li T2,b1000,2302 - 193 - 2345(49.54% R-3.22[-11.6,5.17]) winrate black , white = 50.59% , 49.41%
⇑でevaluate()呼ばないわりにはそこまで弱くなってなかったな…。 なんなんやろか…。この経路じゃないんやろか…。
V7.77i2
-
do_null_move()の前にevaluate呼び出すの忘れてたっぽい。修正。
engine1 = YaneuraOuNNUE_V777h_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V777i2_1024.exe , eval = Li T2,b1000,311 - 29 - 300(50.9% R6.26[-16.85,29.36]) winrate black , white = 50.41% , 49.59%
V7.77i
- evaluated導入。evaluate_with_no_return()廃止。
do_move()する直前までevaluate()を遅延する。
if (!evaluated) { evaluate(pos); evaluated=true;}
みたいなやつ。
engine1 = YaneuraOuNNUE_V777h_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V777i_1024.exe , eval = Li T2,b1000,166 - 7 - 147(53.04% R21.12[-11.2,53.43]) winrate black , white = 51.76% , 48.24% ⇨ 修正 7.77i2
V7.77h
- V7.77g rollback
int bonus = (depth > 6) + (PvNode || cutNode) + (bestValue < alpha - PARAM_COUNTERMOVE_FAILLOW_MARGIN /*657*/)
⇓
int bonus = (depth > 6) + (PvNode || cutNode) + ((ss - 1)->statScore < -18782)
ここだけ反映。
engine1 = YaneuraOuNNUE_V777f_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V777h_1024.exe , eval = Li T2,b1000,1634 - 153 - 1663(49.56% R-3.06[-13.01,6.9]) winrate black , white = 52.47% , 47.53% ⇨ 計測できない差
engine1 = YaneuraOuNNUE_V777a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V777h_1024.exe , eval = Li T2,b1000,3290 - 235 - 3225(50.5% R3.47[-3.61,10.55]) winrate black , white = 51.68% , 48.32% T2,b2000,1515 - 180 - 1505(50.17% R1.15[-9.25,11.55]) winrate black , white = 52.22% , 47.78% T2,b4000,718 - 100 - 692(50.92% R6.41[-8.81,21.62]) winrate black , white = 55.32% , 44.68%
⇨ この修正、よくない可能性があるな…。他のhistoryとのバランスがあるのかも知れん。
・GitHubのCI、やねうら王、ふかうら王のビルドでこけてる件、修正する。 ⇨ 修正できたっぽい…!? https://github.com/yaneurao/YaneuraOu/commit/89cd2f5afeb7c32660b410cad0a86e2f2d4e4538
-
エンジンオプションのPV_Intervalの上限大きくする
- 定跡掘る時とか最後に1回だけPVが来ればいいことがあるから。その時はPV_Intervalを大きく設定すれば良い。
-
readme.mdのMacOS→macOSと改める
-
駄目元でUbuntu用のふかうら王のActions少し修正。
-
peta_shock_nextコマンドで親ノードへの伝播高速化。
-
GitHub Actionsから以下のworkflowを削除。
- YANEURAOU_ENGINE_NNUE_HALFKP_1024X2_8_32
- YANEURAOU_ENGINE_NNUE_HALFKP_VM_256X2_32_32
- YANEURAOU_ENGINE_NNUE_HALFKPE9
- YANEURAOU_ENGINE_NNUE_KP256
- YANEURAOU_ENGINE_MATERIAL9
V7.77g
-
VLTC Search parameters tune : https://github.com/official-stockfish/Stockfish/commit/36db936e769a2e7a95fc4032eec3b79251bbaef5
engine1 = YaneuraOuNNUE_V777f_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V777g_1024.exe , eval = Li T2,b1000,689 - 48 - 593(53.74% R26.07[10.07,42.07]) winrate black , white = 51.64% , 48.36% ⇨ 明らかに悪い。rollbackする。
engine1 = YaneuraOuNNUE_V777a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V777g_1024.exe , eval = Li T2,b1000,774 - 61 - 765(50.29% R2.03[-12.53,16.6]) winrate black , white = 50.75% , 49.25%
V7.77f
-
Improvement of Time Management Parameters : https://github.com/official-stockfish/Stockfish/commit/07a2619b62a25910a32ad8a4e9912f748338580f → これは比較しないと怖くて無理。
engine1 = YaneuraOuNNUE_V777e_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V777f_1024.exe , eval = Li T2,b1000,910 - 75 - 905(50.14% R0.96[-12.45,14.37]) winrate black , white = 50.03% , 49.97% ⇨ 影響なさそう。
engine1 = YaneuraOuNNUE_V777a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V777f_1024.exe , eval = Li T2,b1000,1519 - 134 - 1547(49.54% R-3.17[-13.49,7.15]) winrate black , white = 52.12% , 47.88% ⇨ あれ?ほぼつよなってない?
V7.77e
- Adjust stand pat in qsearch on pv nodes : https://github.com/official-stockfish/Stockfish/commit/d9ec82e7438716671168d78eee26fae327249e8c
engine1 = YaneuraOuNNUE_V777d_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V777e_1024.exe , eval = Li T2,b1000,2503 - 211 - 2526(49.77% R-1.59[-9.65,6.47]) winrate black , white = 51.46% , 48.54% → 計測できない差
V7.77d
- Tweak quiet move bonus : https://github.com/official-stockfish/Stockfish/commit/fbdf5d94a9a42acb92720a5896b16c92931ec3de
- Fix TB score output in UCI without using TB : https://github.com/official-stockfish/Stockfish/commit/282e15bf75bd1142de96306b22424f0cd2bb8dfa
engine1 = YaneuraOuNNUE_V777c_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V777d_1024.exe , eval = Li T2,b1000,2405 - 227 - 2548(48.56% R-10.03[-18.16,-1.91]) winrate black , white = 52.37% , 47.63% → これだいぶつよなってる。
V7.77c
- Adjust return value in qsearch after fail high : https://github.com/official-stockfish/Stockfish/commit/9be0360aa414556f231873ce2348f9c1f00d1713
- Use std::abs over abs : https://github.com/official-stockfish/Stockfish/commit/a069a1bbbfb60abddbe3fe5276b06f35f783f41c
engine1 = YaneuraOuNNUE_V777b_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V777c_1024.exe , eval = Li T2,b1000,2551 - 193 - 2496(50.54% R3.79[-4.26,11.83]) winrate black , white = 52.51% , 47.49% → 強くなってるか怪しいな…。
V7.77b
- Remove moveMalus : https://github.com/official-stockfish/Stockfish/commit/53ad6d23b0e7ec2814579d4acba7c02c2b12008f
- Track seldepth in qsearch too : https://github.com/official-stockfish/Stockfish/commit/7885fa5bd3c8aae1e992ec80cbaaab1177502426
engine1 = YaneuraOuNNUE_V777a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V777b_1024.exe , eval = Li T2,b1000,2482 - 196 - 2542(49.4% R-4.15[-12.21,3.91]) winrate black , white = 52.45% , 47.55%
- 基準 : YaneuraOuNNUE_V777a_1024.exe
- peta_shock_next、queueを使っているところvectorに変更。
// メモリ消費実験 unordered_map<u64,u32> m; em.emplace(i,i*2) 10M個 ⇨ 716.8MB 7倍かー。ちょっと大きすぎるなー。 10Mに対して12倍+α程度であって欲しいなー。 100M個で6,652MB
BookMode 72byte // 32byteがpacked sfenかー。 100M×72 = 7.2GBで済むはずなのだが…。 指し手等を入れても30GB程度かな。 ↑のhash入れると37GBぐらいか…。
・最大手数による引き分けの判定、よく考える。 ⇨ PvNodeで引き分け判定しないのは、別に問題なさげ。qsearch()でやってるし…。
- peta_shockコマンド、SmallVector導入でさらに省メモリ化。
- あんま変わらんかった。100万局面で1M×14byte = 14MBでしかないからか…。まあいいや…。
- 高速化して300万局面のペタショック化が4分になった。
- そのnodeの前回のbestをBookNodeに保持するのやめた。効果なかった。
- peta_shock_next、Step IVの進捗出力がおかしかったの修正。
- ペタショック化の使用メモリさらに減らす // 250万局面2GBぐらいでいけそうな…。あとで再度計測する。
// 以前はUSI_Hashデフォルト(1024)のままになっていた。0を指定するようにした。
USI_Hash 0
SkipLoadingEval true
DrawValueBlack 0
DrawValueWhite 0
makebook peta_shock book.db user_book1.db
quit
やねうらお — 今日 01:02
■ 時間がO(N ^ 2) かかってもいいから、1/Nのメモリでペタショック化できるかについて
消費メモリをどこまで減らせるのか考える。
まず、合流チェック。これは、定跡全体をN分割して、group-1 , group-2, .. , group-Nと名付ける。このgroup-x から group-yへ合流するかをチェックする感じにすれば、ある瞬間にメモリに読み込むのは2つのグループだけで済むので、合流チェック自体は2 / Nのメモリで、O(N ^ 2)でできそう。
次に、後退解析。
// ループになっていないところをグラフ(定跡ツリー)から取り除けば、1/3ぐらいのノードしか残らないので、そうするのが現実的か?
いくつかの部分木に分割できれば良いのだが、簡単ではなさそう。
ディスクに退避しまくっていいなら、group-X を後退解析して、そこから他のgroupに出ていくやつと他から入ってくるやつをディスクに書き出す/読み出す、みたいなのをそれぞれのgroupに対して行う感じかなー。これはしかしMAX PLY回、ディスクから読み出す必要があって、ちょっとしんどい気はする。
角換わりが相掛かりに合流することなんてほぼありえないので、もうちょっと綺麗な部分グラフに分割できるはずなんだけどなー。もうちょっと賢いアルゴリズムないんかな…。
やねうらお — 今日 01:20
もうちょっと綺麗な部分グラフに分割できる
最小カットアルゴリズム(min-cut)のバランス版だな…。最小カットのコードすら満足に書けないのに、んなもん書けないっちゅーの!😠
よく知らんのだけど、min-cutって、MST(最小全域木)求める必要がある気がする。MST求めるのって、O(E + V log V)とかO(E log E)とか、なんかそれくらいで求まると思うんだけど、このためのworking memoryがないっちゅーの…。(1億ノードとか10億ノードとかなので…)
分割が最適である必要は全然ないので、小さな部分木から開始して、それ結合して(いい感じに)成長させていくのが簡単かつ省メモリで済むかなー。
やねうらお — 今日 01:37
後退解析の時に局面情報要らないので、いまpacked sfenに保存してるやつ(1ノード 32byte)をディスクに逃がすのもアリか…。32×0.1GB = 3.2GB 得するな…。
いやー、そもそもで言うと、ペタショック化する時は大きなメモリ積んでるインスタンスをAWSで借りればいいので最悪、そこは512GBぐらいまでならどうにかなる。(つまりは4億局面ぐらいまでならどうにかなる)
問題は、定跡掘ってる最中に次に掘るべき局面を調べるためにpeta_shock_nextというコマンド使ってて、これはペタショック化と同じような処理をしたあと、rootから評価値の一番いいleaf nodeを探して、次に掘るべき局面を返すんだけど、それ返したらそのleaf nodeは無かったことにして再度rootから辿っていく。それを繰り返す。このpeta_shock_nextをするためのメモリがないんだよなー。😟
やねうらお — 今日 01:41
定跡掘るプログラム、Pythonで書いてて、そいつがsfenを文字列で持ってるから、メモリに全部の局面のsfen持ってるんだよなー。😵💫
C++で書いて、定跡掘りながら後退解析もすればいいような気もするが、いまさらそんなところ書き直すのは大変だな…。🥴
やねうらお — 今日 03:07
■ 定跡 10億局面は多すぎるのか?
何億局面も掘ろうとするからこんな色んな問題が発生するのであって、5000万局面ぐらいなら何の問題もない。
もっと評価値の精度のいいソフトで1000万局面ほど掘るほうが現実的な気はするし、将来的にも、10億局面も掘る人は現れないだろうから、問題にはならない気もする。(10年先なら、そのころには家庭用PCでもメモリ1TBは搭載可能になってるだろうし…)
定跡は、終盤の激しい変化になってるところ、DL系の将棋ソフトでも読み抜けするから、あんまり深くまで定跡作っても(その局面の大会での探索ノード数のほうが定跡生成時のノード数より多い場合)、定跡に従って指して頓死したら意味ないしなー。
たぶん、精度のいい将棋ソフト持ってきたら1000万~1億局面ほどあればそれ以上はやっても効果に乏しい気がするんだよなー。🥴
やねうらお — 今日 13:31
合流とか循環があろうと、将棋の定跡ってほぼdendrogram(樹形図)なんだよなー。
結晶を成長させてくみたいなアルゴリズム(階層クラスタリング?)で簡単に分割できる気がする。
しかし階層クラスタリングって普通にやると計算コスト高杉なのか…。🥴
-
ペタショック化のコードでsize_tに対して-1を使っていたところ修正。
-
ペタショック化コマンドで出次数0になったnodeをqueueに追加するコード間違っていたの修正。
-
ペタショック化コマンドの途中経過でてないところがあったの修正。
-
clangなどでBookHeaderがwarningでてたの修正。
-
tanuki mateエンジンなどでビルドエラーになっていたの修正。
-
ペタショック化コマンドのpeta_next、root_sfenを普通のsfenから始まる文字列に変換して書き出せてなかったの修正。
// Illegal Positionの警告でた。なんで? ⇨ root_sfen、"startpos moves .."になってた。
2+BS1k1nl/4gs3/2ppp2g1/Pr3p2p/4GNP2/2+n2P3/L2PPKS1P/1+r3G3/2P2S2L w B3Pnl3p 110
lr4knl/3g2g2/4pssp1/p1pp1pp1p/1p1nP2PP/P1PS1PP2/1P1S2N2/1KG2G3/LN5RL w BPb 54
l2gk2nl/1r1s2g2/p1npp1sp1/2p2pp1p/1p5P1/2PP1PP1P/PPS1P4/2G3SR1/LN2KG1NL b Bb 25
l5knl/1r4g2/3gpssp1/p1pp1ppPp/3nP4/P1PS1PP1P/1P1S2N2/1KG2G3/LN5RL w BPbp 62
2+B2k1nl/4gsg2/2pppp1p1/P1G1l2Pp/1P3NP2/5P3/L3+nKS1P/2r2G3/5S2L b RBS2Pn4p 111
ln2k3l/r3g1g2/3pbsnp1/p2sppp1p/9/PP1G1PP1P/3PPSN2/1BSK1G3/LN5RL b 3Pp 57
ln1g3nl/1r1s1kg2/p1ppppsp1/6p1p/1p5P1/2P3P2/PPSPPP2P/2G1G1SR1/LN1K3NL w Bb 22
l5knl/1r4g2/3gp2pb/p2psPs1p/2Pn3P1/PP1SS1P1P/1G1PPG3/2K6/LN5RL w B3Pnp 72
ln1g3nl/1r1s1kg2/p1ppppsp1/6p1p/1p5P1/2PP2P2/PPS1PP2P/2G1G1SR1/LN2K2NL w Bb 22
lr5nl/3gk1gP1/2n1p4/p1bs1sppp/2p6/PP2PPP1P/2SS2N2/3GKG3/LN5RL w B2P3p 72
lr5nl/3gk1g2/2n1p1sp1/p1ppspp1p/1p5P1/P1PPSPP1P/1PS1P1N2/2GKG4/LN1R4L w Bb 46
lr1g3nl/2s2kg2/p1npppsp1/2p3p1p/1p5P1/2P2PP1P/PPSPPS3/2GK3R1/LN3G1NL b Bb 27
lr5nl/3gk1g2/2n1pp1p1/p1ppssp1p/1p5P1/P1PPSPP1P/1PS1P1N2/2G2G3/LN2K2RL b Bb 41
l6nl/1r2gkg2/p1npppsp1/2ps2p1p/1p5P1/2P1SPP1P/PPSPP1N2/2G2G1R1/LN2K3L b Bb 31
2+B2k1nl/4gsg2/2ppp2+P1/Pr3p2p/4GNP2/2+n2P3/L2PPKS1P/2r2G3/5S2L w BS4Pnl2p 106
ln1g3nl/1r1s1kg2/p1ppppsp1/6p1p/1p5P1/2P2PP2/PPSPP3P/2G1G1SR1/LN2K2NL w Bb 22
ln1g3nl/1r1s1kg2/p1ppppsp1/6p1p/1p5P1/2P3P2/PPSPPPS1P/2G1G2R1/LN2K2NL w Bb 22
lr5nl/3gk1g2/2n1p1sp1/p1p1spp1p/1p5P1/P1PpSPP1P/1PS1P1N2/2G2G3/LNKR4L b Bbp 45
l6nl/1r1gk2g1/2nsppsp1/p1pp2p1p/1p5P1/P1PP1PP1P/1PS1PSN2/2GK1G3/LN5RL b Bb 37
1+B1l1k1nl/3S2g2/2ppppsp1/P6rp/4N1P2/2+nG1P1P1/L2PP1S1P/2r2GK2/5S2L w BG4Pnp 106
lnsgk2nl/1r5g1/p1ppppspp/1p4p2/9/2P2P1P1/PP1PP1P1P/2S2S1R1/LN1GKG1NL w Bb 14
2+B2k1nl/4gsg2/2pppp1p1/P1G4Pp/1P3NP2/5P3/L2+n+lKS1P/2r2G3/5S2L b RBS2Pn4p 111
lr5nl/3g1kg2/2nspps2/p1p3ppp/1p3SP2/P1PS1P2P/1P2P1N2/2GK1G3/LN5RL w BPb2p 46
+B6nl/2g1k1g2/2ppppsp1/Pr3n2p/2G3P2/1+nP2P1PN/L2PPKS1P/2r2G3/5S2L w BS3Plp 96
lr5nl/3g1kg2/2n1p1s2/p1p1spp1p/1p5N1/P1PSSPP1P/1P2P4/2G1KG3/LN5RL w BPb3p 48
lr5nl/3g1kg2/2n1p1s2/p1p1spp1p/1p3P1p1/P1PSS1P1P/1P2P1N2/2G1KG3/LN5RL w Bb3p 48
4rk1nl/+B3g1g2/2ppppsp1/P7p/3Gn1PP1/1+nP1NPKS1/L2PP1S1P/2r2G3/5S2L w B2Pl2p 114
lr4knl/3g2g2/p3p1sp1/2pp2p1p/P2n1S1P1/1pPS2P1P/1P1PPp3/2GK2G2/LN5RL b BSPbn 57
lr5nl/3gk1g2/2n1ppsp1/p1pps1p1p/1p5P1/P1PPSPP1P/1PS1P1N2/2G3G2/LN1K3RL b Bb 43
l5knl/3g2gb1/4p2p1/p1Ppssp2/3P1P2p/PrpnS1PB1/4Pp3/1S1G2G2/LNK4RL b 4Pn 73
l6nl/3g1r1k1/p1n1p2g1/2pp2ppp/Pp7/2P2SP1P/1PSPP2g1/2GK1SR2/LN6L w 2BSPn2p 70
l6nl/3g1kg2/2n1p1s2/p1p1spp1p/7p1/PrPSSPP1P/2N1P1N2/2G1KG3/L6RL b BPb4p 51
ln6l/4gkg2/3pbsnp1/p1rsp1p1p/5p3/PPG1S1P1P/1S1PP1N2/1B1K1G3/LN5RL b 2P3p 67
lr4knl/3g2g2/p3p1s2/3ps2pp/P1Sn1Np2/2P1S3P/1PNPP4/LKG2G3/7RL w B3Pb3p 66
1+B6l/2g1k1g2/2ppppspn/P7p/4r1P2/1PP2P3/L2PPKS1P/1+nr1SG3/8L w BS2N4Pgl 86
lr5nl/3gk1g2/2n1p1sp1/p1ppspp1p/1p3P1P1/P1PPS1P1P/1PSGP1N2/3K1G3/LN5RL w Bb 48
l5knl/1r3sg2/3gp2p1/p1pps1P1p/3n1PbP1/PPPSS3P/1GN1P4/5G3/L1K4RL w B4Pn 62
l4r1nl/3g2gk1/p1n3sp+P/2p6/Pp1Sp1pP1/2P1B4/1P1PPP3/2GK1G3/LN5RL w BP2sn3p 72
lr5nl/3g1kg2/2n1p1s2/p1p1spp1p/7p1/PPPSSPP1P/2N1P1N2/2GpKG3/L6RL b BPb2p 51
1+B5nl/3gk1g2/2ppppsp1/P4n1rp/4G1P2/2+n2P1P1/L2PP1S1P/2r2GK2/5S2L b BSN4Plp 103
lr5nl/3g1kg2/2n1p1s2/p1p1spp1p/9/PPPSSPPpP/2N1P1N2/2G1KG3/L6RL b BPb3p 51
l4r1nl/3g1kg2/p3p1s2/2ppspppp/Pp1n5/2PSSPP1P/1P1PP1N2/L1G2G3/1NK4RL b Bbp 51
lr5nl/3g1kg2/2n1pp1p1/p1p1ssp1p/1p5P1/P1PSSPP1P/1P2P1N2/2G1KG3/LN5RL b BPbp 43
l5knl/1r2g1g2/2n1p1sp1/p1ppspp1p/5PPP1/PpP1S3P/1PSPP1N2/2GK2G2/LN5RL b Bb 41
+Bn1g3nl/1+Ls1k1g2/2ppppsp1/P3r3p/5N3/1PPG1Pp2/L2PPK2P/1+nr2GS2/8L w BS2P2p 76
l4r1nl/3g2gk1/p1n1p2p1/2pp2p1p/Pp2s4/2P2SP1P/1PSPPP3/2GK1G3/LN5RL w BSbn2p 60
lr5nl/2g2kg2/2nPp2p1/2p2pp1p/p2pSP1P1/PpP3P1P/1P2P1N2/1KG2G3/LN1R4L b BSb2s 61
lr5nl/2g2kg2/2nPp2p1/p1p2pp1p/1p1pS2P1/P1P2PP1P/1P2PGN2/1KG1b4/LNR5L w B2Ss 62
+Bn5nl/2g1k1g2/2ppppsp1/P7p/4r1P2/1P+r2P3/L2PPKS1P/1+n1+sSG3/5G2L b BN4Plp 93
l4r1nl/2g1k1g2/2n1p1sp1/p1ppspp1p/1p3PPP1/P1PPS2RP/1PS1P1N2/2G2G3/LNK5L w Bb 50
lr5nl/3gkg3/2n1p1sp1/p1p1spp1p/3p1P1P1/PpPPS1P1P/1PS1P1N2/2G2G3/LNK4RL b Bb 47
lr5nl/3gk1g2/2n1p1sp1/p3sppPp/1ppp1P3/P2PS1P1P/1PS1P1N2/2KG1G3/LN5RL w Bbp 56
lr4knl/3g2g2/p3p1s2/3p3pp/P1Sn1Sp2/2P4nP/1PpPPp3/LK1G2G2/1N5RL b BS2Pb2p 71
l5rnl/3gk1g2/2n1p1sp1/p1ppspp1p/1p5P1/P1PPSPP1P/1PSGP1N2/2K2G2L/LN5R1 w Bb 48
l6nl/2g1k1g2/2n1p1sp1/p1ppsrp1p/1p5P1/P1PPS1P1P/1PS1P1N2/2GK1G3/LN5RL b BPbp 47
l5rnl/3gk1g2/2n1ppsp1/p1pps1p1p/1p5P1/P1PPSPP1P/1PS1P1N2/2G3G2/LN1K3RL b Bb 43
l4r1nl/2gk2g2/2n1p2p1/p1ppssp1p/1p5P1/P1PPS1P1P/1PS1PPN2/2GK1G3/LN5RL b Bbp 49
lr5nl/2g2kg2/2nPp2p1/p1p2pp1p/1p1pS2P1/P1P2PP1P/1P2PGN2/1KGRb4/LN6L w B2Ss 62
lr2k2nl/3g1sg2/2n1pp1p1/p1pps1pPp/1p3N3/P1PPSPP1P/1PS1P4/2G2G3/LN1K3RL w Bb 44
lr5nl/3gk1g2/2n1p1sp1/p1ppspp1p/1p5P1/P1PPSPP1P/1PS1P1N2/2GK2G2/LN1R4L w Bb 46
l5knl/3g2gb1/1r2p2p1/p1Ppssp2/3P1P2p/P1pnS1PB1/1P2Pp3/1S1G2G2/LNK4RL b 3Pn 75
lr5nl/3gk1g2/2n1ppsp1/p1pps1p1p/1p3P1P1/P1PPS1P1P/1PS1P1N2/2G2G3/LN1K2R1L w Bb 44
lr5nl/3gk1g2/2n1p1sp1/2p1spp1p/pp1p3P1/P1PPSPP1P/1PS1P1N2/2G2G3/LNKR4L b Bb 49
l5knl/3g2g2/pr2p1sp1/2pBspp1p/P2n3P1/2PSSPP1P/3PP1Nb1/2GK1G2L/LN5R1 b 2Pp 57
lr2k2nl/3g1g3/2n1ppsp1/p1pps1p1p/1p5P1/P1PPSPP1P/1PS1P1N2/2G1KG3/LN5RL b Bb 43
l4r1nl/3g2gk1/p1n1p2p1/2ppn1pPp/Pp7/2P2SP1P/1PSPPS3/2GK1G3/LN5RL w Bbs2p 56
lr5nl/3gk1g2/2n1ppsp1/p1pps1p1p/1p3P1P1/P1PP2P1P/1PS1PSN2/2G2G3/LN1K3RL w Bb 44
lr6l/3gk1g2/2n1p1np1/p1p2sp1p/3Ps1PP1/PPP1S3P/2SpPPN2/3GKG3/LN5RL b B2Pb 59
l4r1nl/2g1k1g2/2n1p2p1/p2pss1Pp/1pp3p2/P2PS1P1P/1PS1PPN2/2GK1G3/LN5RL w Bb2p 52
+B6nl/2g1k1g2/B1ppppsp1/Pr3n2p/3G2P2/1+nP2P1PN/L2PP1SKP/2r2G3/5S2L w S3Plp 100
+B2g3nl/1+Ls1k1g2/2ppppsp1/P3rn2p/2G2PP2/1+nP4PN/L2PP1SKP/2r2G3/5S2L w B3Pp 96
ln2k3l/2r1g1g2/3pbsnp1/p3ppp1p/9/PP1s1PP1P/3PPSN2/1BSK1G3/LN5RL b 4Pg 57
lr5nl/3gk1g2/2n1p1sp1/p1ppspp1p/1p5P1/P1PPSPP1P/1PS1P1N2/2GK1G3/LN4R1L w Bb 46
lr5nl/3gk1g2/2n1p1sp1/p1ppspp1p/1p5P1/P1PP1PP1P/1PS1PSN2/2GK1G3/LN1R4L w Bb 46
l5knl/4g1gb1/4ps1p1/p1+Pps1p2/1rNP1P2p/P1p1S1PB1/1P2P4/1SG2G3/LNK4RL w 3Pnp 74
+Bn1g4l/1+Ls1k1g2/2ppppspn/P7p/4r1P2/1PP2P1P1/L2PPKS1P/1+nr1SG3/8L w BN3Pg 84
1n1g3nl/1+Bs1k1g2/2pp1p1p1/P3p3p/1p4p2/1PPG1PK2/L2PP1N1P/1+nr2G3/5S2L b RBS2Pslp 87
1n1g3nl/1+Bs1k1g2/2pp1p1p1/P3p2sp/6P2/1pPG1P3/L2PPKN1P/1+nr2G3/5S2L b RB3Pslp 83
+Bn6l/2g1k1g2/2ppppspn/P7p/4r1P2/1PP2P1P1/L2PPKS1P/1+nr1SG3/8L w BSN3Pgl 86
lr4knl/3g2g2/p3p1sp1/2pp2p1p/P2n1S1P1/1pPS1nP1P/1P1PPpb2/2GK5/LN3SGRL b BP 61
2+B3knl/4gsg2/2pppp1p1/P1rP4p/2P1GNPP1/B4Pp2/L2+nPKS1P/2r2G3/5S2L b SPnl2p 113
2+BS1k1nl/4gsg2/2ppp2p1/Pr3p1Pp/4GNP2/2+n2P3/L2PPKS1P/2r2G3/5S2L w B3Pnl2p 110
l3k3l/4gbg2/1rpp1snp1/p3ppp1p/3N1P3/Ps1G2P1P/1p1PPSN2/2SK1G3/L1B4RL w NP2p 74
lr4knl/3g2g2/p3p1sp1/2pp2p1p/P2n1S1P1/1pPS2P1P/1P1PP4/2GK1G3/LN5RL b BSPbnp 55
+Bn6l/2g1k1g2/2ppppspn/P7p/4r1P2/1PP1PP3/L2P1KS1P/1+nr1SG3/8L w BSN4Pgl 86
2+B2k1nl/4gs3/2ppp4/Pr3p1gp/4GNPP1/2+n2P3/L2PPKS1P/1+r3G3/2P2S2L w BSPnl4p 112
+Bn1g4l/1+Ls1k1g2/2ppppspn/P7p/4r1P2/1PP1PP3/L2P1KS1P/1+nr1SG3/8L w BN4Pg 84
+Bn1g3nl/1+Ls1k1g2/2ppppsp1/P6rp/6P2/1PPG1PpP1/L2PPK2P/1+nr2G1S1/5S2L w B2Pn 86
+B6nl/2g1k1g2/2ppppsp1/Pr3n2p/3G2P2/1+nPB1P1PN/L2PP1SKP/2r2G3/5S2L w S3Plp 100
6knl/lr4g2/3gp2p1/p2ps1psp/2SP1p3/P1P1P1P1P/1PKS2N2/2G2G3/L6RL w BN2Pbn2p 66
+Bn6l/2g1k1g2/2ppppspn/P2N4p/4r1P2/1PP2P3/L2PPKS1P/1+nr1SG3/8L w BS4Pgl 86
lr5nl/3gk1g2/2n1p4/p1bs1sppp/2p6/PP1PPPP1P/2SS2N2/3GKG3/LN5RL w B2P3p 74
+Bn1g3nl/2s1k1g2/2pppp1p1/Pp2r2sp/1L3SP2/1PPG1P3/L2PPKN1P/1+nr2GS2/8L b B3P 77
ln1gk2nl/1r1s1s1g1/2pppp1p1/pp4p1p/9/2P4PP/PPSPPPP2/5G1R1/LN1GK1SNL b Bb 17
+Bn1g4l/1+Ls1k1g2/2ppppnp1/P3rs2p/6P2/1PPG1P3/L2PPKS1P/1+nr1SG3/8L b B4Pn 81
ln2k3l/2r1g1g2/3pbsnp1/p2sppp1p/2p6/PP1G1PP1P/3PPSN2/1BSK1G3/LN5RL b 3P 57
lr6l/3gk1g2/2n1p1np1/p1pPs1p1p/1p4sP1/P1P1PP2P/1PS3NB1/3GKG3/LN5RL w S2Pbp 64
lr5nl/3gk1g2/2nsp4/p4pppp/2p6/PP1P1PP1P/2S1K1N2/9/LN5RL b 2B2S2P2g3p 79
+Bn1g3+Pl/2s1k1g2/2pppp1p1/Pp2r1s1p/1L3N3/1PPG1Pp2/L2PPK2P/1+nr1NGS2/8L w BSPp 80
ln2k3l/4g1g2/2rpbsnp1/p2sppp1p/9/PP1G1PP1P/3PPSN2/1BSK1G3/LN5RL b 3Pp 57
l4r1nl/3g3k1/p1n1p2g1/2pp2p1p/Pp5R1/2P2SP1P/1PSPP4/2GK1Sb2/LN6L w BS2Pgn2p 64
+Bn1g3nl/2s1k2g1/+P1pppp1p1/4r3p/1p3Ps2/1PPG2K2/L2PP1N1P/1+nr1SGS2/8L b B3Plp 85
+Bn1g3+Pl/2s1k1g2/2ppppspn/P3r1p1p/1p7/1PPG1PP2/L2PPKN1P/1+nr2GS2/8L b BSPl 77
+Bn1g4+P/2s1k1g2/2ppppspn/Pp6p/1L4P2/1PPG1PB2/L2PPKN1P/1+nr2GSS+r/7P1 w LPl 86
lr5nl/3gk1g2/2nsp2p1/p1b2sp1p/2p6/PP2PPPRP/2S3N2/1p1GKG3/LN6L b BS4Pp 73
+Bn1g4l/2s1k1gP1/2ppppspn/P5p1p/1p2G4/1PP2PP2/L2PPKN1P/1+nr2GS2/8L b RBPsl 79
+Bng4nl/2sPk1gP1/2p2psp1/P2pp3p/1pG3P2/1PP2P3/L2+lPKN1P/1+nr2G3/5S2L w RBs2p 88
ln1g3nl/1r1s1k1g1/p1ppppsp1/1p4p1p/9/P1P2P1PP/1P1PP1P2/2S1GS1R1/LN1GK2NL w Bb 20
+Bng4nl/2sPk1g2/2p2psp1/P2Gp3p/1p4P2/1PP2P3/L2+lPKN1P/1+nr2G3/5S2L w RB2Ps2p 88
+Bn1g3nl/2s1k1g2/2p2psp1/P2pp3p/1pG2NP2/1PP2P3/L2+lPK2P/1+nr2G3/5S2L w RB2Ps2p 86
l4r1nl/3g2gk1/p1n1p1sp1/2ppb1p1p/Pp3S1PP/2P2SP2/1PSPP4/2GK1G3/LN5RL b Bn2p 57
+Bn1g3nl/2s1k1g2/2ppppsp1/P2lr3p/1p3SP2/1PP1GP3/L2PPKN1P/1+nr2G3/5S2L w B3P 80
+Bn1g3nl/2s1k1g2/2ppppsp1/P3r3p/1p4P2/1PPG1P3/L2PPKN1P/1+nr2GS2/5S2L b B3Pl 77
lr4knl/3g2g2/4p1s2/2pps1ppp/pP1n1pP2/P1PSP3P/3S2N2/1KG2G3/LN5RL b B3Pbp 61
+B2g3nl/2s1k1g2/+L1pppp1p1/4r2sp/1p4P2/1PPG1P3/3PPKN1P/1+nr2GS2/5S2L b BN3Plp 81
+B2g3nl/2s2k3/+L2ppg1p1/2p1r3p/1p3N2n/1PPG1Pp1B/3PP3P/1+nr2sPPK/5S2L b SL3Pg 107
+B2g3nl/2s2k3/+L2ppg1p1/2p4rp/1p3N2n/1PPG1Pp1B/3PP3P/1+nr2GPPK/5Ss1L b SL3P 107
6knl/lr4g2/3gp2p1/p2psppsp/2Sn1P3/P1P1P1P1P/1PpS2N2/1K1G1G3/LN5RL w B2Pbp 62
lnsgk2nl/1r5g1/p1ppppsp1/1p4p1p/9/2P4PP/PPSPPPP2/4G2R1/LN1GK1SNL w Bb 16
lnsgk2nl/1r5g1/p1ppppsp1/1p4p1p/9/2P4PP/PP1PPPP2/2S1G1SR1/LN1GK2NL w Bb 16
lnsgk2nl/1r5g1/p1ppppsp1/1p4p1p/7P1/2P5P/PP1PPPP2/2S1G2R1/LN1GK1SNL w Bb 16
lnsgk2nl/1r5g1/p1ppppsp1/1p4p1p/9/2P2P1PP/PP1PP1P2/2S1G2R1/LN1GK1SNL w Bb 16
ln1gk2nl/1rs4g1/p1ppppspp/6p2/1p7/2P3PP1/PPSPPP2P/5S1R1/LN1GKG1NL b Bb 17
lnsgk2nl/1r4g2/p1ppppspp/6p2/1p7/2P3PP1/PPSPPP2P/5S1R1/LN1GKG1NL b Bb 17
l5knl/1r3sg2/3gp2p1/p2ps1P1p/2pn1PbP1/PPPSS3P/1G2P4/2K2G3/LN5RL b B4Pn 63
l4r1nl/3g2gk1/p1n3sp1/2ppp1pPP/Pp7/2PS2P2/1P1PPP3/2GK1G3/LN5RL w 2B2sn2p 66
ln1gk2nl/1rs3g2/p2pppspp/1pp3p2/7P1/2P2PP2/PP1PP1N1P/2S2S1R1/LN1GKG2L w Bb 20
lnsgk2nl/1r3s1g1/p1pppp1pp/6p2/1p7/2P4PP/PP1PPPP2/2S3SR1/LN1GKG1NL w Bb 14
lnsgk2nl/1r3sg2/2pppp1p1/pp4p1p/9/P1P2P1P1/1P1PP1P1P/2S2S1R1/LN1GKG1NL b Bb 17
lnsgk2nl/1r3sg2/p1pppp1p1/6p1p/1p7/P1P2P1P1/1P1PP1P1P/2S2S1R1/LN1GKG1NL b Bb 17
ln6l/1rp1gkg2/3pbsnp1/p1P1ppp1p/9/P1SB1PP1P/1P1PPSN2/2SK1G3/LN5RL b 2Pg 61
lnsgk2nl/1r3sg2/p1p1pp1p1/1p1p2p1p/9/P1P2P1P1/1P1PP1P1P/2S2S1R1/LN1GKG1NL b Bb 17
ln1gk2nl/1rs2sg2/p1pppp1p1/1p4p1p/9/P1P2P1P1/1P1PP1P1P/2S2S1R1/LN1GKG1NL b Bb 17
lnsgk2nl/1r4g2/p1ppppspp/1p4p2/9/P1P4P1/1P1PPPP1P/2S2S1R1/LN1GKG1NL b Bb 15
lnsgk2nl/1r5g1/p1p1ppspp/3p2p2/1p7/2P3PP1/PPSPPP2P/5S1R1/LN1GKG1NL b Bb 17
lr5nl/3g1kg2/p3p1sp1/3psp2p/P1Pn3P1/3PSPp1P/1PN1P1N2/2GSBG3/L1K4RL b 2Pbp 57
lr5nl/3gk1g2/2nsp2p1/p1b2sp1p/1pp4P1/PP1PPPP1P/2S3N2/3GKG3/LN5RL b BS2Pp 69
ln1gk2nl/1r1s1sg2/p1pppp1p1/1p4p1p/9/P1P2P1P1/1P1PP1P1P/2S2S1R1/LN1GKG1NL b Bb 17
lnsgk2nl/1r5g1/p1ppppsp1/6p1p/1p7/2P3PP1/PPSPPP2P/5S1R1/LN1GKG1NL b Bb 17
lr5nl/3gk1g2/2nsp4/p5ppp/2p6/PP1P1PP1P/2S1s1N2/4K4/LN5RL b 2BS2P2g4p 77
lnsg3nl/1r3k1g1/p1ppppspp/6p2/1p7/2P3PP1/PPSPPP2P/5S1R1/LN1GKG1NL b Bb 17
lnsgk2nl/1r5g1/2ppppspp/p5p2/1p7/2P3PP1/PPSPPP2P/5S1R1/LN1GKG1NL b Bb 17
l5knl/1r4g2/3gp1sp1/2ppsp2P/P2n2pPp/2PSPPP2/1P1S2N2/1KG2G3/LN5RL b BPb2p 65
lnsgk2nl/1r5g1/p1ppppspp/1p4p2/7P1/2P6/PP1PPPP1P/2S2S1R1/LN1GKG1NL w Bb 14
lnsgk2nl/1r5g1/p1ppppspp/1p4p2/9/P1P4P1/1P1PPPP1P/2S2S1R1/LN1GKG1NL w Bb 14
lnsgk2nl/1r5g1/p1ppppspp/1p4p2/9/2P4P1/PP1PPPP1P/2SK1S1R1/LN1G1G1NL w Bb 14
lnsgk2nl/1r3sg2/2pppp1p1/pp4p1p/9/2P2P1PP/PPSPP1P2/5G1R1/LN1GK1SNL w Bb 18
lnsgk2nl/1r3s1g1/2p1ppbpp/p2p2p2/1p7/P1P2P1P1/1PBPP1P1P/2SK2SR1/LN1G1G1NL w - 20
l4r1nl/3g2gk1/p1ns2sp1/2ppp3P/Pp4pP1/2PSB4/1P1PPP3/2GK1G3/LN5RL b Bsn3p 69
lnsgk2nl/1r5g1/2ppppsp1/pp4p1p/9/2P4PP/PPSPPPP2/5G1R1/LN1GK1SNL b Bb 17
7kl/lr4g2/3gp1bP1/p1p2s1Rp/3p1s3/P1P1P1p1P/1P1S5/1KG2G3/LN6L b B2NPsn5p 73
lnsgk2nl/1r3s1g1/2pppp1p1/1p4p1p/p8/2P4PP/PPSPPPP2/5G1R1/LN1GK1SNL b Bb 17
lnr5l/4gkg2/3pbsnp1/p2sppp1p/9/PPGBSPP1P/1S1PP1N2/3K1G3/LN5RL w 3Pp 64
lr4knl/3g2g2/p3p1s2/3p3pp/P1Sn1sp2/2P1S3P/1P1PP4/LKG2G3/1N5RL b B2Pbn4p 65
lnsgk2nl/1r3sg2/2pppp1p1/pp4p1p/9/2P4PP/PPSPPPP2/5GSR1/LN1GK2NL w Bb 18
l6nl/3gk1g2/2nsp4/pr4ppp/2p6/PP1P1PP1P/2S1K1N2/9/LN5RL b 2B2S2P2g4p 79
lnsgk2nl/1r3sg2/2pppp1p1/pp4p1p/9/2P3PPP/PPSPPP3/5G1R1/LN1GK1SNL w Bb 18
lr6l/3gk1g2/2n1p1n2/p1s3ppp/2p3P2/PP1P1P2P/2S1K1N2/9/LN5RL w 2B2SP2g5p 82
lnsgk2nl/1r3s1g1/p1pppp1p1/1p4p1p/9/2PP3PP/PP2PPP2/2S4R1/LN1GKGSNL w Bb 14
lnsgk2nl/1r4g2/2ppppspp/pp4p2/7P1/2P3P1P/PPSPPP3/7R1/LN1GKGSNL w Bb 18
ln1gk2nl/1r1s3g1/p2pppsp1/1pp3p1p/9/P1P2P1PP/1P1PP1P2/2S2S1R1/LN1GKG1NL b Bb 19
l5knl/3g2gb1/4ps1p1/p1Pp1Np2/3s1P2p/PrpnS1PB1/4Pp3/1S1G2G2/LNK4RL b 4Pp 73
ln1g3nl/1r1s1k1g1/p1ppppsp1/1p4p1p/9/P1P2P1PP/1PSPP1P2/5S1R1/LN1GKG1NL w Bb 20
ln1g3nl/1r1s1k1g1/p1ppppsp1/1p4p1p/9/P1P2PPPP/1P1PP4/2S2S1R1/LN1GKG1NL w Bb 20
lnr6/4gkg1l/3pbsnp1/3sppp2/p5P1p/PP1GPP2P/1S1P1SN2/1B1KG4/LN5RL b 3Pp 65
lr4knl/3g2g2/p3p1sp1/3ps2Pp/P1Sn1pp2/2P1S3P/1PpPP1N2/LKG2G3/1N5RL b BPb2p 63
lnsgk2nl/1r4g2/2ppppspp/pp4p2/7PP/2P6/PPSPPPP2/7R1/LN1GKGSNL w Bb 18
lr5nl/3gk1g2/2nsp4/p5ppp/2p6/PP1P1PP1P/2S2sN2/3GK4/LN5RL b 2B2Pgs4p 77
lnsgk2nl/1r3s1g1/2p1ppbpp/p2p2p2/1p7/P1P2P1PP/1PBPP1P2/2S3SR1/LN1GKG1NL w - 20
l4r1nl/3g1P1k1/p1n1p2g1/2pp2p1p/Pp7/2P2SP1P/1PSPP4/2GK1Sb2/LN5RL w BSgn3p 62
ln1g3nl/1rs2kg2/p1ppppsp1/6p1p/1p7/2PP2PPP/PPS1PP3/3K1S1R1/LN1G1G1NL b Bb 23
ln1gk2nl/1r1s3g1/p1ppppsp1/6p1p/1p7/2P4PP/PPSPPPP2/3K1S1R1/LN1G1G1NL b Bb 19
l4r1nl/3g2gk1/p1n1p1sp+P/2pp2p2/Pp3b1P1/2P2SP2/1PSPP4/2GK1G3/LN5RL w BPsn2p 60
ln1gk2nl/1r1s3g1/p2pppsp1/1pp3p1p/7P1/2P2P2P/PP1PP1P2/2S2S1R1/LN1GKG1NL b Bb 19
lr5nl/3gk1g2/3ppb1p1/p1Ps1sp1p/3n3P1/PpSSP1P1P/1P3PN2/3GKG3/LN5RL b B2Pp 65
lr6l/3gk1g2/2S1p1np1/p1PPbsp1p/2pn3P1/PP2PPP1P/2S3N2/B2GKG3/LN5RL w s3p 72
lr6l/3gk1g2/2n1p1np1/p1pPs1p1p/1p4sP1/P1PSPP2P/1P4N2/3GKG3/LN5RL w BS2Pbp 64
lr6l/3g2g2/3kp1np1/p1P1bsp1p/2pn3P1/PP1SPPP1P/6N2/B2GKG3/LN5RL w SPs3p 70
lr6l/3g2g2/3kp1np1/p1P1bspPp/2pn5/PP2PPP1P/2S3N2/B2GKG3/LN5RL w SPs3p 70
lr6l/3gk1g2/2n1p1np1/p1pPbsp1p/2P1s2P1/PP2SPP1P/2S1P1N2/3GKG3/LN5RL w B3P 62
6knl/lr4g2/3gp1sp1/p2pspp1p/2Sn1P1P1/P1P1P1P1P/1P1S2N2/1KG2G3/LN5RL w B2Pbp 58
lr6l/3g1kg2/2n1p2p1/p1pPs1p1p/1p3PsP1/P1P1P3P/1PS6/3GKG2B/LN5RL b SN3Pbn 69
lr5nl/3gk1g2/3pp2p1/p1Psbsp1p/3n3P1/PpSSP1P1P/1P3PN2/3GKG3/LN5RL b B2Pp 67
lr5nl/3gk1g2/2nsp2p1/5sp1p/p1p4P1/PP2PPP1P/2S3N2/3GKG3/LN5RL b BS3Pb2p 69
lr5nl/3gk1g2/2nspp1p1/p2p1sp1p/1pp2P1P1/P2PP1P1P/1PS3N2/3GKG3/LN5RL w BSPb 70
l6nl/3g2gk1/p1n1p2p1/2pp2p1p/Pp3r1P1/2P3P1P/1PSPPsS2/2GK5/LN3G1RL w BSbn2p 54
lr5nl/3gk1g2/2nsp4/p2p1sppp/2p6/Pp1PPPP1P/1PS3N2/3GKG3/LN5RL b BSPb2p 71
lr5nl/3gk1g2/2nsp2p1/p1b2sp1p/2p6/PP3PPRP/2SS2N2/3GKG3/LN6L b B4P3p 75
lr6l/3gk1g2/2nsp1n2/p5pRp/2p6/PP1P1PP1P/2S1K1N2/9/LN6L w 2B2S3P2g4p 82
lr6l/3gk1g2/2nsp1nP1/p5ppp/2p6/PP1P1PP1P/2S1K1N2/9/LN5RL w 2B2SP2g4p 80
lr6l/3gk1g2/2nsp1n2/p5ppp/2p6/PP1PSPP1P/2S1K1N2/9/LN5RL w 2BS2P2g4p 80
lr5nl/3gk1g2/2nsp2p1/p1b3pRp/2p1P4/PP1p1PP1P/2SS2N2/3GKG3/LN6L b BS4Pp 75
lr4knl/P2gnsgP1/4p1bp1/2PpsNpl1/3P1P2p/1PSBS1P2/N1G1P4/5G3/2KR4L w 4Pp 80
lr5nl/3gk1g2/2nsp4/p1bP2pRp/2p1P4/PP3PP1P/2Ss2N2/4KG3/LN6L b BS4Pg2p 81
lr4knl/3g2g2/3Pp1s2/p1ppspppp/1p1n5/P1PSPPP1P/1P1S2N2/1KG2G3/LN5RL w Bbp 54
l6nl/3gk1gP1/2n1ps1p1/prsP4p/2p1PN3/PP3PP1P/2SG5/4KG3/LN5rL w 2BS4Pp 86
l6nl/3gk1gP1/2n1ps1p1/prsP4p/2p1P4/PP3PP1P/2SG2N2/4KG3/LN6L w 2BS4Prp 86
l5knl/3g2gb1/1r2ps3/p1PpsNpp1/3P1P2p/P1pnS1PB1/1P2Pp3/1S1G2G2/LNK4RL b 3P 75
l1B4nl/3gk1g2/2n1ps1p1/prsP4p/2p1PN3/PP3PP1P/2SG5/4KG3/LN5rL w BS5Pp 88
l6nl/3g1r1k1/p1n1p2g1/2pp2ppp/Pp2B4/2P2SP1P/1PSPP2g1/2GK1SbR1/LN6L w SPn2p 70
lr5nl/3gk1g2/2nsp2p1/p5p1p/2p1s2P1/PP1PGPP1P/2S3N2/3GK4/LN5RL w 2BS2P3p 72
lr5nl/3gk1g2/2nsp4/p1P3ppp/2p6/PP1PSPP1P/2S3N2/1p1K5/LN5RL w 2BS2P2g2p 82
l6nl/3gk1g2/2n1ps1p1/prsP3Pp/2p1P4/PP3PP1P/2SG2N2/4KG3/LN6L w 2BS4Prp 84
l6nl/3gk1g2/2n1ps1p1/prsP4p/2p1PB3/PP3PP1P/2SG2N2/4KG3/LN6L w BS5Prp 84
ln2k3l/2p1g1g2/1r1pbsnp1/p1P1ppp1p/9/P1SB1PP1P/1P1PPSN2/2SK1G3/LN5RL b 2Pg 61
lr6l/3gk1g2/2nsp1n2/p3P1ppp/2p6/PP1P1PP1P/2S1K1N2/9/LN5RL w 2B2SP2g4p 80
ln2k3l/2rbg1g2/3p1snp1/p2sppp1p/9/PP1G1PP1P/3PPSN2/1BSK1G3/LN5RL b 3Pp 57
l4r1nl/3g2gk1/p1n3sp1/2ppp2PP/Pp4p2/2PS5/1P1PPP3/2GK1G3/LN5RL w 2B2sn3p 68
lr6l/3gk1g2/2nsp1n2/p5ppp/2p1S4/PP1P1PP1P/2S1K1N2/9/LN5RL w 2BS2P2g4p 80
lr5nl/3gk2g1/2npp4/p1sP1sppp/1pp2S3/P3P1P1P/1PS2PN2/3GKG3/LN5RL w Bb3p 66
lr5nl/b2gk1g2/2nsp2p1/p4sp1p/2p6/PP3PPRP/2SS2N2/3GKG3/LN6L b B4P3p 75
lr5nl/3gk1g2/2nsp2p1/p4sp1p/2p6/PP3PPRP/2S+b2N2/3GKG3/LN6L b B4Ps3p 75
l4rknl/3g2g2/p1n1p2p1/2ppssp1p/Pp3N1PP/2P1SPP2/1PSPP4/2GK2G2/LN5RL w Bbp 46
lr4knl/3g2g2/p2pp1sp1/2pBspp1p/P2n3P1/2PSSPP1P/3PP1N2/2GK1G3/LN5RL b 2Pb 49
l5knl/4g1gb1/3+Pps1p1/p2ps1p2/1rNP1P2p/P1p1S1PB1/1P2P4/1SG2G3/LNK4RL w 3Pnp 74
l4r1nl/3g2gk1/p1n1p2p1/2ppn1p1p/Pp2B4/2P2SP1P/1PSPP2R1/2GK1G3/LN6L w SPbs2p 60
l4r1nl/3g3k1/p1n1p2g1/2pp2p1p/Pp2B4/2P2SP1P/1PSPP4/2GK1Sb2/LN5RL w SPgn3p 62
l4r1nl/2bg2gk1/p1n1p1sp1/2pp2p1p/Pp3S1PP/2P2SP2/1PSPP4/2GK1G3/LN5RL b Bn2p 57
lb3r1nl/3g2gk1/p1n1p1sp1/2pp2p1p/Pp3S1PP/2P2SP2/1PSPP4/2GK1G3/LN5RL b Bn2p 57
l4r1nl/3g2gk1/p1n1p1sp1/2pps1p1P/Pp5P1/2PS2P2/1P1PPP3/2GK1G3/LN5RL b 2Bsn2p 65
l4r1nl/3g2gk1/p1n1p1sp1/1npp2p1P/Pp5P1/2PS2P2/1P1PPP3/2GK1G3/LN5RL b 2B2s2p 65
l4r1nl/3g2gk1/p1n1p1sp1/2ppn1p1p/Pp3S1PP/2P2SP2/1PSPP4/2GK1G3/LN5RL b Bb2p 57
l4r1nl/3g2gkp/p1n1p1sp1/2pp2p1P/Pp5P1/2PS2P2/1P1PPP3/2GK1G3/LN5RL b 2B2snp 65
l4r1nl/3g2gk1/p1nsp1sp1/2pp2p1P/Pp5P1/2PS2P2/1P1PPP3/2GK1G3/LN5RL b 2Bsn2p 65
l4r1nl/3g2gk1/p1n1p1sp1/2pp1pp1p/Pp3S1PP/2P2SP2/1PSPP4/2GK1G3/LN5RL b Bbnp 57
l4r1nl/3g2gk1/p1n1p1sp1/2pp2p1p/Pp1b1S1PP/2P2SP2/1PSPP4/2GK1G3/LN5RL b Bn2p 57
l4r1nl/3g2gk1/p1n3sp1/2ppp1p1P/Pp5P1/2PS2PB1/1P1PPP3/2GK1G3/LN5RL w B2sn2p 66
l4r1nl/3g2gk1/p1n3sp1/2ppp1p1P/Pp5P1/2PS2P2/1P1PPP3/2G2G3/LNK4RL w 2B2sn2p 66
lr5nl/3g2gk1/p3p1sp1/2ppspp1p/Pp1n3P1/2PSPPP1P/1P1P1SN2/1KG2G3/LN5RL w Bb 48
l6nl/3g2gk1/p1n1p2p1/2pp2p1p/Pp3r1P1/2P3P1P/1PSPP4/2GK1G3/LN3S1RL w BSbsn2p 52
lr4knl/3g2gb1/4p2p1/p1PpsPp2/3P4p/Ppp1S1PB1/1P2P4/1SG2G3/LNK4RL b S3P2n 73
l6nl/3+Sr2k1/p1n1p2g1/2pp2ppp/Pp7/2P2SP1P/1PSPP2g1/2GK1SbR1/LN6L w BGPn2p 72
l4r1nl/3g2gk1/p1n4s+P/2p2sPR1/Pp1Sp1p2/2P1B4/1P1PPP3/2GK1G3/LN6L w BPsn4p 78
l4r1nl/3g2gk1/p1n5+P/2p2sPp1/Pp1Sp1p2/2P1B4/1P1PPP3/2GK1G3/LN5RL w B2sn4p 76
lr4knl/3g2g2/p3p2p1/2pp2psp/P2n1s2P/1PPS2P2/3PP1G2/2G5L/LNK4R1 w 2B3Psnp 64
l4r1nl/3g2gk1/p1n1p2p1/2ppn1p1p/Pp7/2P3P1P/1PSPP1SR1/2GK1G3/LN6L w BSPbs2p 60
l4r1nl/3g2gk1/p1n1p1sp1/2pp2p1p/Pp5P1/2P2SP1P/1PSPPS3/2G2G3/LNK4RL w Bbn2p 56
l5knl/4g1gb1/3+Pps1p1/p2p2p2/1r1P1P2p/P1p1S1PB1/1P2P4/1SG2G3/LNK4RL w S3P2np 76
l6nl/3g2gk1/p1n1p2p1/2pp2p1p/Pp3r1P1/2P3P1P/1PSPPS3/2GK1G3/LN5RL w BSbsn2p 52
l3S2nl/3gr2k1/p1n1p2g1/2pp2ppp/Pp2B4/2P2SP1P/1PSPP2g1/2GK1SbR1/LN6L w Pn2p 72
l6nl/3Sr2k1/p1n1p2g1/2pp2ppp/Pp7/2P2SP1P/1PSPP4/2GK1Sg2/LN6L w 2BGPrn2p 74
lr4knl/3g2g2/p2bp1s2/3p3pp/P1Sn1Sp2/2P5P/1PpPPp3/LK1G2G2/1N5RL b BS2Pn2p 71
l6nl/3g1r1k1/p1n1p2g1/2pp2ppp/Pp2B2R1/2P2SP1P/1PSPP4/2GK1Sb2/LN6L w SPgn2p 68
l4r1nl/3g1g1k1/p1np2sp1/2pBp1p1p/Pp5P1/2P2SP1P/1PSPP4/2G2G3/LNK4RL b Sbn2p 61
lr4knl/3g2g2/p3p1sp1/2pp2p1p/Pp1n1S1P1/2PS1+bP1P/1P1PPp3/2G1K4/LN3SGRL b BNP 63
l1r4nl/3g1kg2/p3p1sp1/3pspp1p/PpSn3P1/2P1SPP1P/1P1PP1N2/2GK1G3/LN5RL w Bbp 54
l4r1nl/3g1kg2/p3p1sp1/2ppspp1p/Pp1n3P1/2PSSPP1P/1PNPP1N2/2GK1G3/L6RL w Bb 50
lr4knl/3g2g2/p3p1sp1/2ppspp1p/Pp1n1P1P1/2PSS1P1P/1PNPP1N2/L1GK1G3/7RL w Bb 54
l3r2nl/3g2gk1/p3p1sp1/2ppspp1p/Pp1n3P1/2PS1PP1P/1P1PPSN2/1KG2G3/LN5RL b Bb 47
l4rknl/3g2g2/p3p1sp1/2ppspp1p/Pp1n3P1/2PS1PP1P/1P1PPSN2/1KG2G3/LN5RL b Bb 47
l5rnl/3g2gk1/p3p1sp1/2ppspp1p/Pp1n3P1/2PS1PP1P/1P1PPSN2/1KG2G3/LN5RL b Bb 47
lr4knl/3g2g2/p3p1sp1/2pps1pPp/Pp1n1p3/2PSS1P1P/1P1PP1N2/2G2G2L/LNK4R1 w Bbp 52
lr4knl/3g2g2/p3p1sp1/2pps1p1p/Pp1n1N1P1/2PSS1P1P/1P1PP4/2G2G2L/LNK4R1 w BPbp 52
lr4knl/3g2g2/p3p2p1/2pp2psp/P2nBs3/1PPS2P1P/3PP1G2/2G5L/LNK4R1 w B3Psnp 64
lnr6/4gkg1l/3pbsnp1/p2sppp1p/9/PP1GPPP1P/1S1P1SN2/1B2KG3/LN5RL w 3Pp 62
l5knl/5ggb1/1r2p2p1/p1PPsPp2/8p/P1p1S1PB1/1P2P4/1SG2G3/LNK4RL b S4P2np 75
lr4knl/3g2g2/p3p1sp1/2pps1pPp/P2n1p3/2PSS1P1P/1P1PP1N2/LKG2G3/1N5RL w Bb2p 58
lr5nl/3g2gk1/p3pssp1/2pp1pp1p/Pp1n3P1/2PSPPP1P/1P1P1SN2/LKG1G4/1N3R2L w Bb 54
lr5nl/3g2gk1/p3pssp1/2pp1pp1p/Pp1n3P1/2PS1PP1P/1P1PPSN2/LKGG5/1N3R2L w Bb 54
l5knl/3g2g2/p3p1sp1/1rppspp1p/P2n3P1/2PSSPP1P/B2PP1N2/2GK1G2L/LN5R1 b Pbp 55
l5knl/3g2gb1/4p2p1/p1rpsPp2/2PP4p/PPp1S1PB1/4P4/1SG2G3/LNK4RL w S2P2n2p 74
lr4knl/3g2g2/p3p1sp1/2ppspp1p/P2n3P1/2PSSPP1P/B2PP1N2/2GK1G2L/LN5R1 b Pbp 55
l5knl/3g2g2/2+P1psbp1/p2psNp2/3P1P2p/PrpnS1PB1/4P4/1S1G1G3/LNK4RL w 4Pp 72
lr4knl/3g2g2/p3p2p1/2pBsppsp/P2n5/1PPSSPP1P/1p1PP1N2/2GK1G2L/LN5R1 b Pbp 61
l5knl/1r1g2g2/p3p1sp1/2ppspp1p/Pp1n3P1/2PSSPP1P/1P1PP1N2/2GK1G2L/LN5R1 b Bb 51
l5knl/3g2g2/pr2p1sp1/2ppspp1p/Pp1n3P1/2PSSPP1P/1P1PP1N2/2GK1G2L/LN5R1 b Bb 51
lr5nl/3g1kg2/p3pp1p1/2ppssp1p/Pp3N1P1/2PSSPP1P/1P1PP4/2GK2G1L/L6R1 w BNbn 64
l5knl/1r3sg2/3gp2p1/p1ppspP1p/3n3P1/P1PSPP2P/1P1S2N2/2G2G3/LNK4RL b B2Pbp 57
lr4knl/3g2g2/p3p1sp1/2ppsppPp/P2n5/1PPSSPP1P/3PP1N2/L1G2G3/KN5RL w BPb 52
lr4knl/3g2g2/p3p1sp1/3ps1p1p/P1S2pPP1/2P1S3P/1PnPP1N2/LKG2G3/7RL b B2Pbnp 63
lr4knl/3g2g2/p3p1sp1/2pps1p1p/P2n1p1PP/2PSS1P2/1P1PP1N2/LKG2G3/1N5RL w Bb2p 58
lr4knl/3g2g2/p3p1sp1/3p4p/P1Sn1spP1/2P1S3P/1P1PP4/LKG2G3/1N5RL b B2Pbn3p 63
lr4knl/3g2g2/p3p1s2/3p3pp/P1Sn1Sp2/1pP5P/1PpPPp3/LK1G2G2/1N5RL b BS2Pbnp 71
lr4knl/3g2g2/p3p1s2/3p3pp/P1Sn1Sp2/2P2G2P/1PpPP4/LK1G2+p2/1N5RL b BSN2Pb2p 75
lr4knl/3g2g2/p3p1sp1/3p3Pp/P1Sn1Sp2/2P5P/1PpPP4/LK1G1+p3/1N5RL b BS2Pbgnp 69
lr4knl/3g2g2/p3p2p1/3p3sp/P1Sn1Sp2/2P5P/1PpPPp3/LK1G1G3/1N5RL b BS2Pbn2p 69
lr4knl/3g2g2/p3p1sp1/3psbp1p/P1Sn1pPP1/2P1S3P/1PNPP1N2/LKG2G3/7RL b B2Pp 63
lr4knl/3+P2gb1/4+Bs1p1/p2p2p2/1pn2P2p/P1p1P1P2/1P1s5/1SG2G3/LNK4RL w GSN4Pp 72
lr4knl/2S3gb1/3gps1p1/p5p2/1p1p1P2p/P1p2nPB1/1P2Pp3/1SG3G2/LNK4RL b N3Psp 75
l5knl/3g2gb1/1r2ps1p1/p1PpsNp2/3P1P3/P1pnS1PBp/1P2Pp3/1S1G2G2/LNK4RL b 3P 75
lr4knl/2S3g2/3gps1pb/p5p2/1p1p1P2p/P1p3PB1/1P2Pp3/1SG3G2/LNK4RL b N3Psnp 75
lr4knl/2S3g2/3gps1p1/p5p2/1p1p1P2p/P1pb2PB1/1P2Pp3/1SG3G2/LNK4RL b N3Psnp 75
lr4knl/4g1gb1/3+Pps1p1/p5p2/1p1p1P2p/P1pn2PB1/1P2Pp3/1SG3G2/LNK4RL b SN3Ps 73
l5knl/4g1gb1/2+P1ps1p1/p2psPp2/1rNP4p/P1p1S1PB1/1P2P4/1SG2G3/LNK4RL w 3Pnp 74
l5knl/4g1gb1/1r2p2p1/p1PPsPp2/8p/P1p1S1PB1/1P2Pp3/1SG2G3/LNK4RL b S4P2n 75
l5knl/4g1g2/1r2p1bp1/p1PPsPp2/8p/P1p1S1PB1/1P2P4/1SG2G3/LNK4RL b S4P2np 75
l5knl/3g2g2/4psbp1/p1PpsNp2/3P1P2p/PrpnS1PB1/1P2P4/1S1G1G3/LNK4RL w 3Pp 72
l5knl/1r5g1/3gps1p1/p1pps1P1p/3n1PbP1/PPPSS3P/1G2P4/5G3/LNK4RL b B4Pn 61
l5knl/3g2+N2/4psbp1/p1Pps1p2/3P1P2p/PrpnS1PB1/4P4/1S1G1G3/LNK4RL w G4Pp 72
l5knl/3g2g1P/4psbp1/p1PpsNp2/3P1P2p/PrpnS1PB1/4P4/1S1G1G3/LNK4RL w 3Pp 72
lr4knl/3g2g2/4p1s2/2ppspppp/pp1n1P3/P1PSP1P1P/1P1S2N2/1KG2G3/LN5RL b BPbp 55
lr4knl/4g1gb1/4p2p1/p1PPsPp2/2N1n3p/P1p1S1PB1/1P1SPG3/1SK6/LN5RL b 5Pg 83
l5knl/3g2gb1/1r2p2p1/2PpsPp2/p2P4p/P1p1S1PB1/1P2P4/1SG2G3/LNK4RL b S3P2np 73
l5knl/3g2gb1/4p2p1/p1rpsPpP1/3P4p/PPp1S1PB1/4P4/1SG2G3/LNK4RL w S2P2n2p 74
lnr6/4gkg1l/3pbsnp1/p2spp3/1P4p1P/Pp1GPP3/1S1P1SN2/1B1KG4/LN5RL b 5P 69
l5knl/3g2gb1/4p2p1/prPpsPp2/3P4p/P1pnS1PB1/1P2P4/1SG2G3/LNK4RL b S3Pnp 73
l5knl/3g1pgb1/4p2p1/prPpsPp2/3P4p/P1p1S1PB1/1P2P4/1SG2G3/LNK4RL b S3P2n 73
l5knl/3g2g2/1r2psbp1/p1PpsNp2/3P1P2p/P2nS1PB1/1PS1PG3/3G5/LNK4RL w 5P 78
l5knl/3g2gb1/1r2p2p1/p1PpsPp2/3P4p/P1p1S1PB1/1P2P4/1SG2G3/LNK4RL b S3P2np 73
ln2k3l/2rg2g2/3pbsnp1/p2sppp1p/9/PP1G1PP1P/3PPSN2/1BSK1G3/LN5RL b 3Pp 57
l5knl/3g2gb1/4ps1p1/p1Pp1Np2/1r3P2p/P1pns1PB1/1P1PP4/1S1G1G3/LNK4RL b 2Ps2p 75
l5knl/3g2g2/4p2p1/p1Pp1sp2/3P1s2p/PPpnS1P2/1S2PG3/3Gb4/LNK4RL w RB4Pnp 80
l5knl/3g2gb1/1r2ps1p1/2PpsNp2/p2P1P2p/P1pnS1PB1/1P2Pp3/1S1G2G2/LNK4RL b 3P 75
l5knl/4g1gb1/1r2ps1p1/p1PpsNp2/3P1P2p/P1pnS1PB1/1P2Pp3/1S1G2G2/LNK4RL b 3P 75
l5knl/3g2gb1/1r2ps1p1/p1Pp1Np2/3s1P2p/P1pnS1PB1/1P2Pp3/1S1G2G2/LNK4RL b 3Pp 75
l5knl/3g2g2/1r2psbp1/p1PPsNp2/5P2p/P1pnS1PB1/1P2Pp3/1S1G2G2/LNK4RL w 4P 76
l5knl/4g1gb1/2+Psps1p1/p2p1Pp2/1r1P4p/P1p1S1PB1/1P2P4/1SG2G3/LNK4RL w 3P2np 76
l5knl/3g2g2/1r2psbp1/p1PpsNp2/3P1P2p/P2nS1PB1/1PG1PG3/1S7/LNK4RL w 5P 78
l5knl/4g1gb1/2+Psps1p1/p2p2pP1/1r1P1P2p/P1p1S1PB1/1P2P4/1SG2G3/LNK4RL w 2P2np 76
ln2k3l/1rp1g1g2/4bsnp1/p1Ppppp1p/9/P1SB1PP1P/1P1PPSN2/2SK1G3/LN5RL b 2Pg 61
l3k3l/4g1g2/1rppbsnp1/p3ppp1p/9/Ps1G1PP1P/1pNPPSN2/2S1KG3/L1B4RL w NP2p 72
lnr5l/4gkg2/3pbsnp1/p2sppp1p/2p6/PPPG1PP1P/1S1PPSN2/1B1K1G3/LN5RL b 2P 61
l5knl/1r4g2/3gpp1p1/p1ppssp1p/1p1n1N1P1/P1PSSPP1P/1P2P4/2GK1G3/LN5RL w BPb 48
lnr5l/3bgkg2/3p1snp1/p2sppp1p/9/PPPG1PP1P/1S1PPSN2/1B1K1G3/LN5RL b 2Pp 61
lnr5l/4gkg2/3pbsnp1/p2spppPp/9/PPG1SPP1P/1S1PP1N2/1B1K1G3/LN5RL w 2Pp 64
lnr2k2l/4g1g2/3pbsnp1/p2sppp1p/9/PPPG1PP1P/1SNPPSN2/1B1K1G3/L6RL w 2Pp 62
lnr6/4gkg1l/3pbsnp1/p2sppp1p/6P2/PPSG1P2P/3PPSN2/1B1K1G3/LN5RL w 3Pp 62
lnr6/4gkg1l/3pbsnp1/p2sppp1p/9/PP1G1PP1P/1SNPPSN2/1B2KG3/L6RL w 3Pp 62
lnr6/4gkg1l/3pbsnp1/p2sppp1p/1p7/PP1GPPP1P/1S1P1SN2/1B1KG4/LN5RL b 3P 63
lnr6/4gkg1l/3pbsnp1/3sppp1p/p8/PP1GPPP1P/1S1P1SN2/1B1KG4/LN5RL b 3Pp 63
lnr6/4gkg1l/3pbsnp1/p2spp3/6p1p/PP1GPP2P/1S1P1SN2/1B1KG4/LN5RL b 3P2p 65
lnr6/3bgkg1l/3p1snp1/p2sppp1p/9/PP1GPPP1P/1S1P1SN2/1B1KG4/LN5RL b 3Pp 63
ln6r/4gkg1l/3pbsnp1/p2spp3/1P4p1P/P2GPP3/1S1P1SN2/1B1KG4/LN5RL b 5Pp 69
ln2k3l/3rg1g2/3pbsnp1/p2sppp1p/9/PP1G1PP1P/3PPSN2/1BSK1G3/LN5RL b 3Pp 57
ln4k1l/2r1g1g2/3pbsnpP/p2sppp2/8p/PP1G1PP2/1S1PPSN2/1B1K1G3/LN5RL w 2P2p 62
lnr5l/4gkg2/3pbsnp1/p2sppp1p/9/PPG1SPP1P/1SBPP1N2/3K1G3/LN5RL w 3Pp 64
l5knl/1r4g2/3gpssp1/p1pp1pp1p/3nPP1P1/P1PS2P1P/1P1S2N2/1KG2G3/LN5RL w BPbp 62
ln6l/4gkg2/3pbsnp1/p1rsppp1p/6P2/PPG1SP2P/1S1PP1N2/1B1K1G3/LN5RL w 2P2p 66
lnr5l/4gkg2/3pb1np1/p2spp2p/5Ps2/PPG1S3P/1SpPP1N2/1B1K1G3/LN5RL b 2P3p 73
lnr5l/4gkg2/3pbsnp1/p2spp2p/2p2PP2/PP1GS1p1P/1SBPP1N2/3K1G3/LN5RL b 3P 77
ln2gk2l/2r3g2/3pbsnp1/p2sppp1p/9/PPPG1PP1P/1S1PPSN2/1B1K1G3/LN5RL w 2Pp 60
l3k3l/4g1g2/2ppbsnp1/p3ppp1p/1r1N5/Ps1G1PP1P/1p1PPSN2/2SK1G3/LNB4RL w P2p 70
l3k3l/4g1g2/1rppbsnp1/p3ppp1p/1P7/Ps1G1PP1P/1pNPPSN2/2SK1G3/L1B4RL w N2p 72
6knl/lr4g2/3gpssp1/3p1p2p/P1SnPPpP1/2PP2P1P/1P1S2N2/1KG2G3/LN5RL w B2Pbp 64
l3k3l/4gbg2/1rpp1snp1/p3ppp1p/3N5/Ps1G1PP1P/1p1PPSN2/2S1KG3/L1B4RL w NP2p 74
l3k3l/1r2g1g2/2ppbsnp1/p3ppp1p/9/PsG2PP1P/1p1PPSN2/2SK1G3/LNB4RL b NP2p 71
lr2k3l/4g1g2/2pp1snp1/p2bppp1p/1P7/P4PP1P/1S1PPSN2/3K1G3/LNB4RL b SNPg2p 77
l1r6/4gkg1l/n2pbsnp1/p2spp3/1P4p1P/P2GPP3/1S1P1SN2/1B1KG4/LN5RL b 5Pp 69
lr4knl/3g2g2/4p1s2/p1ppspppp/1p1nP4/P1PS1PP1P/1P1S2N2/1KG2G3/LN5RL w BPbp 54
lr4knl/3g2g2/4p1s2/p1ppspppp/1p1n3P1/P1PSPPP1P/1P1S2N2/1KG2G3/LN5RL w Bbp 54
lr4knl/3g2g2/4p1s2/p1ppspppp/1p1n5/P1PSPPPPP/1P1S2N2/1KG2G3/LN5RL w Bbp 54
lr4knl/3g2g2/4p1s2/p1ppspppp/1p1n4P/P1PSPPP2/1P1S2N2/1KG2G3/LN5RL w BPbp 54
lr4knl/3g2g2/4p1s2/p1ppsp1pp/1p1n1Pp2/P1PSP1P1P/1P1S2N2/1KG2G3/LN5RL b BPbp 55
lr4knl/3g2g2/4p1s2/p1ppspppp/3n1P3/PpPSP1P1P/1P1S2N2/1KG2G3/LN5RL b BPbp 55
lr4knl/3g2g2/4p1s2/p1pps1ppp/1p1nPp3/P1PS2P1P/1P1S2N2/1KG2G3/LN5RL w BPb2p 56
lr4knl/3g2g2/4p1s2/p1pps1ppp/1p1n1p3/P1PSP1P1P/1P1S2N2/1KGB1G3/LN5RL w Pb2p 56
lr4knl/3g2g2/4p1s2/p1pps1ppp/1p1n1p1P1/P1PSP1P1P/1P1S2N2/1KG2G3/LN5RL w Bb2p 56
lr4knl/3g2g2/4p1s2/p1pps2pp/1P1n1pp2/P1PSP3P/3S2N2/1KG2G3/LN5RL b B3Pb2p 61
lr4knl/3g2g2/4p1s2/p2psbppp/1ppn1pPP1/P1PSP3P/1P1S2N2/1KG2G3/LN5RL b B2p 59
6knl/lr4g2/3gp4/p1ppss1pp/3n1N3/P1PSP1p1P/1P1S5/1KG2G3/LN5RL b B2Pb4p 63
l5knl/1r4g2/3gp1sp1/p1ppspp1p/3n3PP/PpPSPPP2/1P1S2N2/1KG2G3/LN5RL b BPb 61
l5knl/6g2/3gps1p1/prpp1ppsp/3nP4/P1PS1PP1P/1P1S2N2/1KG2G3/LN5RL w BPb2p 58
l6nl/1r5k1/3gp2g1/p2pspspp/2Pn5/P2SPPP1P/1P1S2N2/2G2G3/LNK4RL b B3Pb2p 67
6knl/lr4g2/3gpssp1/3p1pp1p/p1SnPP1P1/P1PP2P1P/1P1S2N2/1KG2G3/LN5RL w BPbp 62
6knl/lr4gP1/3gp2p1/p2ps1psp/2S2p3/P1P1P1P1P/1PKS2N2/2G2G3/L6RL w BN2Pbn2p 66
l5knl/1r4g2/3gpp1p1/p1ppssp1p/3n1N1PP/P1PSSPP2/1P1PP4/2G2G3/LNK4RL w Bbp 54
l3B1k1l/5ng2/1r1gppn2/pPpps1R1p/3n1S3/P1PS1PP1P/3PP4/2+b6/LNK2G2L b Sg4p 73
l3B1k1l/1r4g2/3gppn2/p1ppssR1p/3n1N3/PPPSSPP1P/3PP4/2G2+b3/LNK5L b 3Pgp 63
l5knl/1r3s1g1/3gp2p1/p2ps1P1p/2pn1PbP1/PPPSS3P/1G2P4/5G3/LNK4RL b B4Pn 61
l5knl/1r3sg2/3gp2p1/p1pps1P1p/3n1PbP1/PPPSS3P/1G1PP4/5G3/LNK4RL w B3Pn 62
6knl/l5g2/3gppsp1/prpps1p1p/3n1P1P1/P1PSSBP1P/1P2P1N2/2G2G3/LNK4RL b Pbp 53
- makebook peta_shock , peta_shock_nextコマンド、定跡読み込み部を自前で書き直して大幅高速化、省メモリ化した。
- FlippedBookを無視することにした。
- 先手番の局面だけを定跡DBとして書き出すことにした。(FlippedBookをオンにして用いて欲しい)
- register_flipped_position削除。必ずflip局面も登録する。
// makebook peta_shock 3440.2MB(rebuild) / 4322MB ⇓ 1689MB(read) / 1767MB (Unpack sfen) 消費メモリ、元の半分以下になった。 245MBの定跡ファイルの処理に消費するのが、その7倍程度か。 10GBの定跡作っても70GB。わりと小さいな。
200MBが100万局面 1.4GB。2GBが1000万局面が14GB。 3000万局面ぐらいまではギリいけるか…。 そのあとどうするか考えよう。
20GBのbuildに140GBのworkが必要だからなー。
// 反転された局面を書き出すのか。(FlippedBookがtrueなら書き出さない)
// すなわち、後手番の局面はすべて書き出さない。(反転された先手番の局面を書き出しているはずだから)
bool flipped_book = Options["FlippedBook"];
cout << "FlippedBook : " << flipped_book << endl;
private:
// 盤面を反転させた局面も定跡に登録するかのフラグ。
// makebookコマンドのオプションでON/OFF切り替えられるようにすべきか?
const bool register_flipped_position = true;
// 盤面を反転させた局面が元の定跡DBにどれだけ含まれていたかを示すカウンター。
u64 flipped_counter = 0;
// 反転局面の登録
if (register_flipped_position)
{
cout << "Register flipped pos:" << endl;
progress.reset(book.size());
Book::MemoryBook book2;
book.foreach([&](const string& sfen,const Book::BookMovesPtr book_moves){
StateInfo si;
pos.set(sfen,&si,Threads.main());
string flip_sfen = pos.flipped_sfen(-1); // 手数なしのsfen文字列
progress.check(++counter);
if (book.find(flip_sfen) != nullptr)
{
// すでに登録されていた
++flipped_counter;
return;
}
Book::BookMovesPtr flip_book_moves(new Book::BookMoves());
for(const auto& bm : *book_moves)
{
// 盤面を反転させた指し手として設定する。
// ponderがMOVE_NONEでもflip_move()がうまく動作することは保証されている。
Book::BookMove flip_book_move(flip_move(bm.move), flip_move(bm.ponder), bm.value , bm.depth , bm.move_count);
flip_book_moves->push_back(flip_book_move);
}
book2.append(flip_sfen, flip_book_moves);
});
// 生成されたflipped bookをmergeする。
book.merge(book2);
}
// ここで登録される局面数の上限はわかっているので、途中でresizeが発生しないように上限分だけ確保しておく。
book_nodes.reserve(book.size() * (register_flipped_position ? 2 : 1));
// まず、出現する局面すべてのsfenに対して、それをsfen_to_hashkeyに登録する。
// sfen文字列の末尾に手数が付与されているなら、それを除外する。→ IgnoreBookPly = trueなので除外されている。
book.foreach([&](string sfen, const Book::BookMovesPtr book_moves){
// 同じ値のキーがすでに登録されていないかをチェックしておく。
StateInfo si, si2;
pos.set(sfen, &si, Threads.main());
auto hash_key = pos.hash_key();
if (this->hashkey_to_index.count(hash_key) > 0)
{
cout << "Error! : Hash Conflict! Rebuild with a set HASH_KEY_BITS == 128 or 256." << endl;
Tools::exit();
}
// 局面ひとつ登録する。
BookNodeIndex index = (BookNodeIndex)this->book_nodes.size();
this->book_nodes.emplace_back(BookNode());
this->hashkey_to_index[hash_key] = index;
// 局面をpacked sfenにして保存しておく。
pos.sfen_pack(this->book_nodes.back().packed_sfen);
progress.check(++counter);
});
// 手数無視のオプションを有効にすると、MemoryBook::read_book()は、
// sfen文字列末尾の手数を無視してくれる。
Options["IgnoreBookPly"] = true;
// 定跡生成書き出したあとに普通に探索させることはありえないだろうから
// 元のオプションへの復元は行わない。(行いたいならば、benchmark.cppを参考にコードを修正すべし。)
Book::MemoryBook book;
if (book.read_book(readbook_path).is_not_ok())
{
cout << "read book error" << endl;
return ;
}
// memo : 指し手の存在しない局面はそんな定跡ファイル読み込ませていないか、
// あるいはMemoryBookが排除してくれていると仮定している。
/*
残念なことにhash key to indexは、後手の局面分しか持っていないので、
ここで後手の局面のhash keyを得る必要がある。
*/
HASH_KEY white_hash_key;
if (pos.side_to_move() == BLACK)
{
} else {
white_hash_key = pos.state()->hash_key();
}
if (hashkey_to_index.count(white_hash_key) == 0)
{
// 局面が定跡DBの範囲から外れた。この局面は定跡未探索。このsfenを書き出しておく。
write_sfens.emplace(pos.sfen());
progress.check(write_sfens.size());
write_counter2++;
break;
// このnodeへのleaf node move(一つ前のnodeがleaf nodeであるはずだから、そのleaf nodeからこの局面へ至る指し手)を削除する。
// そのあと、そこから後退解析のようなことをしてrootに評価値を伝播する。
} else {
// bestmoveを辿っていく。
BookNodeIndex index = hashkey_to_index[hash_key];
// 手順もデバッグ用に書き出す。
//write_sfens.emplace_back(sfen_path);
// PV leaf nodeまで到達したので、ここからrootまで遡ってbest move,best valueの更新を行う。
// rootまで遡る時にparentsが複数あったりloopがあったりするので単純に遡ると組み合わせ爆発を起こす。
// そこで、次のアルゴリズムを用いる。
/*
queue = [処理すべき局面]
while queue:
p = queue.pop_left()
b = pの指し手がすべてMOVE_NONE(無効)になったのか
v = 局面pのbestvalue
for parent in 局面p.parents():
if b:
parentの局面pに行く指し手 = MOVE_NONE
else:
parentの局面pにいく指し手の評価値 = v
if ↑この代入によりこのparent nodeのbestvalueが変化したなら
queue.push_right(p)
*/
// 上記のアルゴリズムで停止すると思うのだが、この停止性の証明ができていない。
// 永久ループになることがある。同じ局面は2回更新しないようにする。
peta shock化でMOVE NONEが含まれていた。なぜ? ⇨ 合流がらみでnoneが入ってるっぽい..
>1:position startpos moves 2g2f 8c8d 2f2e 4a3b 7g7f 8d8e 8h7g 3c3d 7i8h 2b7g+ 8h7g 3a2b 1g1f 9c9d 9g9f 1c1d 6i7h 2b3c 3i4h 6c6d 4g4f 7a7b 4h4g 7b6c 3g3f 7c7d 2i3g 5a4b 5i6h 6c5d 4i4h 6a6b 2h2i 6b6c 4g5f 4b3a 6g6f 8a7c 6h7i 6d6e 3f3e 6e6f 3e3d 3c3d 2e2d
>1:go infinite
<1:info string Error! : Illegal Move In Book DB : move = none , sfen = l5knl/1r4g2/2ngpp1p1/p1p1s1sPp/1p7/P1PpSP2P/1PS1P1N2/2G2G3/LNK4RL w BPb2p 46
<1:info string Error! : Illegal Move In Book DB : move = none , sfen = l5knl/1r4g2/2ngpp1p1/p1p1s1sPp/1p7/P1PpSP2P/1PS1P1N2/2G2G3/LNK4RL w BPb2p 46
<1:info string Error! : Illegal Move In Book DB : move = none , sfen = l5knl/1r4g2/2ngpp1p1/p1p1s1sPp/1p7/P1PpSP2P/1PS1P1N2/2G2G3/LNK4RL w BPb2p 46
<1:info string Error! : Illegal Move In Book DB : move = none , sfen = l5knl/1r4g2/2ngpp1p1/p1p1s1sPp/1p7/P1PpSP2P/1PS1P1N2/2G2G3/LNK4RL w BPb2p 46
<1:info multipv 1 score cp -40 depth 2 pv 2c2d 2i2d 8e8f (25.00%)
<1:info multipv 2 score cp -62 depth 0 pv 8e8f (25.00%)
<1:info multipv 3 score cp -263 depth 0 pv 6f6g+ (25.00%)
<1:info multipv 4 score cp -275 depth 0 pv P*3f (25.00%)
<1:info string BookEvalDiff = 0 , BookEvalWhiteLimit = -99999 , 4 moves to 1 moves.
⇨ 重複局面の指し手を登録してしまっていた。
// 後退解析IVで用いる構造体。
struct ParentMoveEx
{
ParentMoveEx(ParentMove parent_move , bool is_deleted , ValueDepth best)
: parent_move(parent_move), is_deleted(is_deleted) , best(best){}
// ある子局面にいたる指し手
ParentMove parent_move;
// その子の指し手がすべてMOVE_NONEで、parent_moveは削除されるべきであるか。
bool is_deleted;
// is_deleted == falseの時、子のbest_value。これを反転させたものが、parent_moveの評価値となる。
ValueDepth best;
};
/*
// plyを求めるためにBFSする時に必要な構造体
struct BookNodeIndexPly
{
BookNodeIndexPly(BookNodeIndex index, int ply):
index(index), ply(ply){}
BookNodeIndex index;
int ply;
};
// 異なる値へのupdateの時だけ親に伝播させる。
if ( parent_vd != book_node.lastParentVd )
{
// 次回用にlastParentVdを更新しておく。
book_node.lastParentVd = parent_vd;
// 親に伝播させる。
for(auto& parent_move : book_node.parents)
{
// すでに一度updateしてあるならスキップする
BookNodeIndex parent = parent_move.parent;
if (already_searched_node.count(parent) > 0)
continue;
// これは一度updateしたのでこれ以上追加しないようにしておく。
already_searched_node.emplace(parent);
queue.emplace_back(parent_move, is_deleted, parent_vd);
}
}
}
SystemIO::TextWriter writer;
writer.Open(writebook_path);
for(auto& write_sfen : write_sfens)
{
StateInfo si;
pos.set(write_sfen, &si, Threads.main());
auto key = pos.hash_key();
// 既出ならskip
if (hashkey_to_index.count(key) > 0)
continue;
// 登録しておく。
hashkey_to_index[key] = -1;
// flipした局面に対してもhitするか調べる。
auto flipped_sfen = pos.flipped_sfen();
pos.set(flipped_sfen, &si, Threads.main());
key = pos.hash_key();
if (hashkey_to_index.count(key) > 0)
continue;
//hashkey_to_index[key] = -1;
// ⇨ flipした局面は登録しなくとも、元の局面に対してhitするから問題ない。
writer.WriteLine(write_sfen);
write_counter++;
}
// write_sfenが先手の局面なら、flipして、hashkey_to_indexに存在するかチェック
StateInfo si;
pos.set(write_sfen, &si, Threads.main());
auto key = pos.hash_key();
// 既出ならskip
if (hashkey_to_index.count(key) > 0)
continue;
// 登録しておく。
hashkey_to_index[key] = -1;
// flipした局面に対してもhitするか調べる。
auto flipped_sfen = pos.flipped_sfen();
pos.set(flipped_sfen, &si, Threads.main());
key = pos.hash_key();
if (hashkey_to_index.count(key) > 0)
continue;
//hashkey_to_index[key] = -1;
// ⇨ flipした局面は登録しなくとも、元の局面に対してhitするから問題ない。
*/
// すべてのnodeがMOVE_NONEになっているか?
bool delete_flag = std::all_of(book_node.moves.begin(), book_node.moves.end(),
[](auto& move){ return move.move == MOVE_NONE; });
- PV出力のコード、整理する。出力タイミング、出力条件を調整する。
- 宣言勝ちの時にPVがmate 2になってた気がするのでmate 1に修正。
- ConsiderationModeのオン/オフで出力タイミングが違ってたの統一した。
- このオプションによる違いは、置換表からPVを集めるかどうかだけにした。
- mate1と宣言勝ちの時に、最後にPVが二重に出力されていたの修正。
// /* rootDepth < 3 ||*/
// ⇨ また、rootDepthが3以下の時はPvIntervalを無視して出力していたが、
// なくてもいいような気がするのでこの処理はやめることにした。
bestThreadがmainThreadではなくなる場合、探索した最大depthが減ることがありうる。
なので、最後の出力でdepthが減っていることは普通にある。これ、「あれ?」と思う挙動ではあるが…。
- ⇓このPV、出力少なすぎる。調査する。
:position startpos moves 2g2f 8c8d 7g7f 3c3d 2f2e 4a3b 6i7h 8d8e 2e2d 2c2d 2h2d 8e8f 8g8f 8b8f 2d3d 2b3c 5i5h 8f8b 3g3f P*8f P*8c 8b8c P*8d 8c8b 2i3g 5a4b 3g4e 3c8h+ 7i8h P*3c 3d2d P*2c 2d2e 7a6b 8i7g 4c4d P*2d B*3d 2e3e 3d4e 3e4e 4d4e 2d2c+ 3b2c B*6e 8b8d 6e2a+ 3a3b 2a1a 8f8g+ 8h8g R*8i N*3e 2c3d L*4c 4b5b 1a2b N*5e 3i3h 6b5a 2b3b 4e4f 4g4f P*8f 8g9f 5b6b P*8e 8d4d B*8c 4d4f P*4g 4f3f 4c4b+ P*4f 7g6e 4f4g+ 5h6h 6a7b 6e5c+ 6b7a 3b5d 5e6g+ 6h6g 7b8c 5d3f 8i6i+ P*6h B*5h 4i5h 6i5h 6g7g 5h5g 6h6g G*8g
>1:go ponder btime 297000 wtime 703000 binc 10000 winc 10000
<T:-0087KI,T1
>1:ponderhit
<1:info depth 31 seldepth 28 score mate 27 nodes 140658895 nps 7155300 hashfull 197 time 19658 pv 9f8g 5g5c 4b5a 8f8g+ 7h8g S*7b R*5b 5c5b 5a5b R*7i 7g8f 7i7g+ 8g7g P*8d B*6b 7a8b S*7a 8b9b R*8b 8c8b 7a8b+ 9b8b S*7a 8b8c R*8b 8c7d G*7e
<1:info depth 31 seldepth 28 score mate 27 nodes 144650757 nps 7133383 hashfull 200 time 20278 pv 9f8g 5g5c 4b5a 8f8g+ 7h8g S*7b R*5b 5c5b 5a5b R*7i 7g8f 7i7g+ 8g7g P*8d B*6b 7a8b S*7a 8b9b R*8b 8c8b 7a8b+ 9b8b S*7a 8b8c R*8b 8c7d G*7e
<1:bestmove 9f8g ponder 5g5c
⇨ pvinterval 1000にしてるからでは?
やねうらお — 今日 06:34
■ aspiration searchのwindow幅の初期値について
前回探索(goコマンドによる)時のrootMoves[0].scoreから幅を決定してたと思うのだけど、これ、ponderすると相手番になるから、 - rootMoves[0].score をベースに決めないといけない気がする。ここの処理、Stockfishのままだった気がするのだけど、もしそうなってるとしたら、これバグだよね…。
// 自分の備忘用のメモ。あとで確認する。
- 定跡にhitした時の最後のPV出力で、評価値が0になっていたのを定跡の評価値を出力するように修正した。
- 定跡DBの評価値はcpで、そこからValue型に逆変換したあと、再度cpに変換して出力するので変換誤差が出て1違うことがあるが、まあ気にしないで…。
- 定跡にhitしたときのmultipvでの出力、"pv ..."のところ、スペースが2つになっていたのを修正。
定跡にhitした時のPV出力、depth 0の出力してるのおかしいな…。修正する。
considerationmode false
bookfile user_book1__.db
isready
go
やねうらお — 今日 05:43
■ やねうら王の定跡の評価値のscaleについて
やねうら王の定跡の評価値、search()した返し値をそのまま書き出すタイプの定跡だと、これは内部で使っているscaleであり、型で言うとValue型である。
ところが、思考エンジンを外部から駆動させてそのinfo stringなどの値を取得してそこから定跡を作る場合、これはcp(centi-pawn)であり、Value型とはscaleが異なる。
どちらで書き出しているか人それぞれあって、やねうら王では、何も考えずに定跡の評価値をそのままinfo stringで出力しているが、前者とみなしてcpに変換する方がいいような気は少ししている。
しかしいまこの変換をしてしまうと評価値が変わった!みたいな感じで大騒ぎする(?)人が絶対でてくる。
かと言って、いま定跡だと最終的な読み筋に評価値0を出力してて、これがおかしい気はする。これを修正しようと思うと、そのまま出力していいのかValueとみなしてcpに変換した方がいいのか迷う。
まあ、定跡の指し手は、評価値0が出力されてると定跡の指し手だとわかって逆に嬉しい意味もあるので、何も修正しないでおこうかと思うが…。
やねうらお — 今日 06:11
いままで定跡の評価値そのままcpとして出力してたから、cpのような気がする。そこで、内部Valueに逆変換してから、USI::pv()で出力することにする。そうすると、逆変換するときに誤差が生じるのだが…。まあいいか…。(評価値が1違います!とか言って誰かが騒ぎそう…)
- peta shockコマンドのlow_depth あんまよくなかったので削除。
// 1番目の指し手のdepthが0なら、その指し手で進めた局面を列挙するモード。
bool low_depth = false;
cout << "low_depth : " << low_depth << endl;
else if (token == "low_depth")
low_depth = true;
if (low_depth)
{
// bestmoveでdepth == 0の指し手(で進めた局面)だけ書き出す。
// 次に探索すべき定跡局面についてsfenを書き出していく。
// これはmin-max探索した時のPVのleaf node。
cout << "Low Depth : step IV -> pick up next sfens to search." << endl;
progress.reset(book_nodes.size());
for(size_t i = 0; i < book_nodes.size() ; ++i)
{
auto& book_node = book_nodes[i];
auto& moves = book_node.moves;
if (moves.size() == 0)
continue;
// 一つでもdepthが0ではない
bool depth_not_zero = false;
// best valueのmoveを探す。
// ※ valueでsortされてないことに注意。
size_t best_index = 0;
int best_value = int_min;
for(size_t j = 0 ; j < moves.size() ; j++)
{
auto move = moves[j];
if (best_value < move.vd.value)
{
best_value = move.vd.value;
best_index = j;
}
auto depth = move.vd.depth;
depth_not_zero |= depth > 0;
}
// best moveのdepth == 0
auto best_move = moves[best_index];
if (depth_not_zero && best_move.vd.depth == 0)
{
// bestmoveのnextはないことはわかっている。(depth == 0なので)
Move move = best_move.move;
if (is_ok(move))
{
StateInfo si, si2;
pos.set_from_packed_sfen(book_node.packed_sfen, &si ,Threads.main());
pos.do_move(move, si2);
auto write_sfen = pos.sfen();
write_sfens.emplace(write_sfen);
}
}
progress.check(i++);
}
} else {
あと、末端の局面で1番目の指し手を掘り進めた結果、1番目の指し手の評価値が2番目の指し手の評価値より下回り、順番が入れ替わることがある。この時、元の2番目の指し手が全く掘っていない(depth == 0)指し手である場合、ある程度掘り進めておかないと危険である。そこで、このような指し手を列挙する機能を追加した。
makebook peta_shock_next book.db sfens.txt 1000 low_depth
⇨ leaf nodeで2番目の指し手はdepth > 0なのに1番目の指し手のdepth == 0だと、
これは掘らないとおかしいので、こういう局面を探して列挙する。
(これ以外の局面は列挙しない。列挙する局面数は制限なし。)
// makebook peta_shock_next book.db sfens.txt 1000 low_depth
// ⇨ leaf nodeで2番目の指し手はdepth > 0なのに1番目の指し手のdepth == 0だと、
// これは掘らないとおかしいので、こういう局面を探して列挙するモード。
// (これ以外の局面は列挙しない。列挙する局面数は制限なし。)
// ⇨ やってみたら対象局面がめっちゃあった。こりゃあかんわ。
やねうらお — 昨日 23:28
■ ペタショックコマンドの省メモリ化について(1)
ペタショックコマンド、現在、100万局面に対してメモリ4GBほど消費している。単純計算だと、1000万局面だと40GB、1億局面だと400GBだ。
これを減らしていかなければ、ペタショック化コマンドを使えない。400GBは、AWSで512GBのインスタンスを借りれば良いのだが、そうは言ってもそのクラスともなると定跡ファイルを圧縮しても30GBぐらいあるので、それ転送するのも嫌だ。
また定跡を掘っていくときにどこを掘るか決めるコマンド(peta_shock_next)のためにもこれだけ必要なので、ここでたくさんメモリが必要になるのは嫌である。
そこで、これを段階的に減らしていくことにする。まずはpacked_sfenを用いて、unordered_mapのテーブルを一つ削除した。これにより、メモリ使用量が20%程度削減された。
https://github.com/yaneurao/YaneuraOu/commit/5db908c26a04b5575069bd49876199cea42367ba
やねうらお — 今日 02:44
■ ペタショックコマンドの省メモリ化について(2)
いま、ペタショック化の時にflipした盤面もいったん生成して、後退解析をしている。また、局面の合流のチェックのために、局面のhash keyから indexへのunordered_mapも持っていて(これをkey2indexと仮に呼ぶ)、これで求めた indexを用いて、book_nodes[index]のようにして、そのnodeへアクセスできるようになっている。
よく考えたらこれが無駄で、2倍食ってるように思う。
つまり、book_nodesに登録する局面はすべて先手番にすれば良い。後手番なら、flipしたものを登録しておく。これでbook_nodesはすべて先手番になる。後手番の局面は登録しない。
次に、key2indexにも先後の両方の局面を登録するのは無駄だから、後手の局面だけを登録する。なぜ後手だけで良いかと言うと、つまりは、先手から1手動かしたら後手なので、book_nodesのnodeを一つ持ってきて、そこからdo_move()した局面は後手なんだけど、これをflipした局面がbook_nodesのなかにあるかを調べたいわけだから、つまりは、後手の局面(book_nodesをflipした局面)だけ登録されていれば良いのだ。
この天才的なアイデア(誰でも思いつく?)により、消費メモリを半分に抑えることができるのだ。
ちょっといまのコード修正するの面倒なので、時間できた時にやる。
- flipしたsfen文字列の生成について
やねうらお — 今日 01:41
■ flipしたsfenについて
定跡を掘る時に元のflip(盤面を180゜回転させること)した局面を重複して掘ってしまっている。全体の1%程度しかないが、角換わりを掘っていくと1%で済まないかも知れない。
ここを掘るのを回避するためにはsfen文字列に対してflipしたsfen文字列を返す関数が必要だ。
やねうら王には備わっているが、定跡を掘るプログラムはPythonで書いているため、反転させたsfen文字列を得ることが困難となっている。
cshogiに備わっていると嬉しいのだが、Aperyに備わってないので、結局のところ、Aperyにプルリク送って追加してもらって、cshogiにそのメソッドを生やすのがいいのかも知れないが、これはわりと面倒な話になりそうである。
そこで文字列操作だけで反転したsfen文字列を作れないかという話になる。
これ自体はわりと簡単で、駒を先後入れ替え、すなわち、アルファベットの大文字小文字を入れ替えて盤面文字列の後ろから前に向かって置き換えていくと良い。
つまり、盤面文字列をreverse()して、文字のcaseを大文字小文字入れ替えればいいだけ…であってるのか?
やねうらお — 今日 01:53
まず、sfen文字列があったとして、これを盤面と手駒に分割する。
# sfen文字列に手数は含まれていないものとする。
sfen_board , turn , hands = sfen.split()
次に盤面だが逆順にしてswapcase()するだけである。
# 逆順にして大文字小文字を入れ替えるだけ。
sfen_board = sfen_board[::-1].swapcase()
手駒はちょっとむずかしい。
やねうらお — 今日 02:23
ChatGPT、アルゴリズムまで書いてあげたら、一発でかきよった..😲
画像
def transform_and_swap_advanced(s):
# Finding the index 'm' from the end where the first uppercase letter appears
m = next((i for i in range(len(s) - 1, -1, -1) if s[i].isupper()), None)
# Splitting the string into two parts: B and W
B = s[:m+1]
W = s[m+1:]
# Swapping the case and concatenating W and B
return (W + B).swapcase()
# Testing the function with the provided string
transform_and_swap_advanced("S2P2b3p")
next()を使うんかー。そうかー。
やねうらお — 今日 02:33
そんなわけで書けた。⇓ 自由に使ってもらって構わない。
def flipped_sfen(sfen:str)->Sfen:
"""
与えられたsfen文字列をflipしたsfen文字列にする。
例) "lnsgkgsnl/1r5b1/3pppppp/9/9/7P1/PPPPPPP1P/1B5R1/LNSGKGSNL w P2p"
→ "lnsgkgsnl/1r5b1/p1ppppppp/1p7/9/9/PPPPPP3/1B5R1/LNSGKGSNL b 2Pp"
"""
# 余分なものを除去
sfen = trim_sfen(sfen)
# 手数は含まれていない。手駒はなしなら"-"だから、常にあるはず。
sfen_board, turn, hands= sfen.split()
# 逆順にして大文字小文字を入れ替えるだけ。
sfen_board = sfen_board[::-1].swapcase()
# 手駒は後ろから見ていき、最初に大文字になるところをmとして、そこで区切って入れ替えてswapcase
# Finding the index 'm' from the end where the first uppercase letter appears
m = next((i for i in range(len(hands) - 1, -1, -1) if hands[i].isupper()), -1)
hands = (hands[m+1:] + hands[:m+1]).swapcase()
# 手番は反転
turn = 'w' if turn == 'b' else 'b'
return f"{sfen_board} {turn} {hands}"
- peta_shockコマンド、省メモリ化
// sfen文字列からBookMoveIndexへのmapper
// this->book_nodesの何番目の要素であるかが返る。
// sfen文字列は先頭の"sfen "と、末尾の手数は省略されているものとする。
unordered_map<string,BookNodeIndex> sfen_to_index;
⇨ なくす
makebook peta_shock user_book1_20231214215252-2.db 起動時(定跡読み込み後) 2520MB 4059.2MB(rebuild) / 5027.5MB(write book) 3459.9MB(rebuild) / 4385.3MB 定跡書き出し準備前にswap trickでunordered_mapを解放する 3440.2MB(rebuild) / 4322MB ⇨ 変わってない。なんでやろか…。
- ペタショック化コマンド、省メモリ化のために定跡ファイル書き出し部を自前で書くことにした。
書き出し部を自前で書くことにした。 ⇨ 3593MB(write) わりと減ったか…? これならBookNodeに持たせているのとなんも変わらんのだが…。 packed sfenで持ってるのがよくないか…。
書き出しのsort時にsfen文字列を構築しない。 ⇨ 3272.8 MB(write) sort中にメモリが解放された 1981.8MB ⇨
- ペタショック化コマンド、一つ前のcommitでflipped_book有効で後手の局面を書き出していたの修正。
- ⇑のcommitでペタショック化コマンド、書き出した局面数の出力が0になっていたの修正。
- MemoryBookを用いて書き出すルーチン、削除
やねうらお — 今日 04:56
■ ペタショックコマンドの省メモリ化について(3)
後手番の局面をflipさせて先手番の局面としてメモリ上に持つことでメモリ使用量が半分になることを前回書いたのだが、よく考えたらDrawValue(千日手スコア)を変更する時におかしなことになる。
例えば、先手は千日手にされてはたまらないので、先手のDrawValue = 負け , 後手のDrawValue = 勝ち と設定しているとする。
ところが定跡生成時に全部先手の局面として登録すると、どれがその対局の先手の局面なのかがわからなくなってしまう。平手の初期局面から偶数手で到達できるところが先手の局面か?違う。先手が手損すると後手の定跡に突っ込むので、偶数手で後手の定跡局面になっていることがあるのだ。
結局、このような状況で、flipした局面も定跡DBの同じ局面にhitするようにしてるので、その対局の先手と後手とで(同じ局面にhitした時の)扱いを変えるということはできないのだ。
わりといろんな問題を引き起こしそうなのだ。
- BookNodeで手番保持をやめる。
⇨ 変わってない。構造体サイズ変わってないからか…。
次のnodeのindex要らんと言えば要らんのだが、親のlistに対して、undo_move()で戻れないから やっぱり欲しい気もするんだよなー。
指し手最大で10bitで数えられるほどしかないのにvectorにしてsize_t(8バイト)消費するのたまらんなー。
■ やねうら王GitHubのCIビルドの復旧について
先日プルリク、もらった⇓YANEURAOU_ENGINE_NNUE_HALFKP_1024X2_8_32の追加なんだけど、macOS用がいまコケてて(ビルドに失敗していて)、これそもそも要るのか?というところで悩んでいる。
CIの意義は、誰かからプルリクもらった時に、そのプルリクによってビルドできない状態になってしまっていないかを簡単にチェックできればいいだけなのだが、だとして、NNUEのhalfKP 256がビルド通って、halfKP 1024の方がビルド通らないことなんてほとんどありえないだろうし、こんなテストあるだけ無駄じゃないかと思う。
NNUEのhalfKP VMなんとか言うのも、いま使ってる人がいるのかわからんし、この際、このへん大掃除したほうがスッキリするような気がしている。
https://github.com/yaneurao/YaneuraOu/commit/376b10d607714d830b6351ef7ef4567f7fc7438d
GitHub
Update make-msys2.yml (#270) · yaneurao/YaneuraOu@376b10d
* Update make-msys2.yml
HalfKP512とHalfKP1024を追加
* Update make-mingw.yml
HalfKP512とHalfKP1024を追加
* Update make-macos.yml
HalfKP512とHalfKP1024を追加
* Update make.yml
HalfKP512とHalf...
Update make-msys2.yml (#270) · yaneurao/YaneuraOu@376b10d
やねうらお — 今日 15:41
次に、ふかうら王のCIビルドが通っていない件だが、まず最新のCUDAのSDKで手元でビルド通るところまで作業して、そのあと、Dockerでビルド通す作業して、それから、GitHubのReleasesのところに配布用のファイル生やすためのビルド(releases.yml)のテストして、そして、GitHubのCIでビルド通す作業をするのである。
わりとたくさん作業しないといけないので、順番にやってく。😵💫
- 評価関数の埋め込みをしてのビルド
やねうらお — 今日 03:36
評価関数の埋め込みをしてのビルド。
makeするときにEVAL_EMBEDDING=ONを指定する
source\eval\nnue\embedded_nnue.cpp として⇑で変換したファイルをコピー
# トーナメント
make clean YANEURAOU_EDITION=YANEURAOU_ENGINE_NNUE ENGINE_BRANCH=dev
cp "eval-bin\nnue_li_bin.cpp" "source\eval\nnue\embedded_nnue.cpp"
make -j8 tournament COMPILER=clang++ YANEURAOU_EDITION=YANEURAOU_ENGINE_NNUE_HALFKP_1024X2_8_32 ENGINE_BRANCH=dev ENGINE_NAME="YaneuraOu\(dev-tournament\)" TARGET_CPU=AVX2 EXTRA_CPPFLAGS="-DHASH_KEY_BITS=128 -DTT_CLUSTER_SIZE=4" EVAL_EMBEDDING=ON
cp YaneuraOu-by-gcc.exe "C:\msys64\home\yaneen\shogi\bin/YaneuraOuNNUE_V800_1024.exe"
やねうらお — 今日 03:53
評価関数のバイナリ埋め込みをしてみたが、これ、ファイルの変わりにC++のMemoryBufferでくるんでistreamに渡して、ここからNNUEの各layerごとに確保されたメモリに読み込んでるっぽい。
要するに、ファイルから読み込むのと同じだけメモリ消費する。🤯
いやー、まいったなー。丸一時間かけてやった作業、まるっきり無駄やった。😢
やねうらお — 今日 23:54
1000万局面掘るときに、peta_shock_next(次に掘る局面を探すコマンド)のworking memoryとして20GB必要である。1億局面だと200GB必要である。
20GBはなんとかならなくはないが、200GBもサーバー用のメモリ(Xeon対応のマザーなので…)買いたくないので(普通のメモリの3-5倍ぐらいのお値段する)、これをディスクに逃しながら求めるプログラムを書かなくてはならない。
うまく部分木に分割できると良いのだが、実際はループもあって(グラフ理論で言うところの)木ではないから、そんなに簡単じゃないんだよなー。
peta_shock_nextコマンドで内部的に用いている構造体、もっと節約すれば半分ぐらいにはなると思うけど、それでも半分なんだよなー。いまのままだと2000万局面が上限だなー。もうちょっとどうにかならんのかな…。🤔
やねうらお — 今日 00:46
80個エンジンを起動しているが、これ評価関数が256MBほどある。実行ファイルに埋め込むことで1つ分で済むなら79個分節約できて、これが20GB。
もともとの空きと合わせて40GBほど確保できる。
peta_shock_nextコマンドの内部構造体をきちきちに節約してworking memoryを半分にできれば、これでいまのマシンのまま4000万局面ほど掘れる計算になる。
-
make_book peta_shockコマンドの内部構造体でdepthを16bitに変更する。
- 千日手の時のスコアを1000,2000,3000,4000と999と1桁減らす。
-
makebook peta_shock_nextコマンドのパラメーター名つけるように変更。
- eval_noise [数値] : 末端の指し手に加えるノイズの大きさ
- low_depth : leaf nodeで2番目の指し手はdepth > 0なのに1番目の指し手のdepth == 0だと、これは掘らないとおかしいので、こういう局面を探して列挙する。
-
peta_shock_nextで、flipしてる局面や、flipした局面がDBにすでにあるなら、それらのsfenは書き出さないようにした。
SkipLoadingEval true DrawValueBlack 0 DrawValueWhite 0 makebook peta_shock_next book.db peta_next_sfens.txt 0 low_depth quit
position startpos moves 6i7h 8c8d 7g7f 8d8e 8h7g 4a3b ⇓ 上のpeta_shock_nextコマンドでこの局面が書き出されればOK sfen lnsgk1snl/1r4gb1/p1ppppppp/9/1p7/2P6/PPBPPPPPP/2G4R1/LNS1KGSNL b - 7 出せたが、局面数が多すぎる気がする…。
⇨ 末端の局面にノイズ加えるの、ちょっとおかしいな。 ガウスノイズ加算するときにrootからの手数を限定すべきような気がしてきた。 bestmoveでないところを延長しすぎている。 もうちょっと考えたほうが良さそう。 nodeの性質を考慮してノイズを加えたほうがよさげ。
あー、leaf nodeでbestmove以外が延長されるのがおかしいので、 そのnodeの指し手すべてに同じノイズを加算すべきか? ⇨ しかしこうやってしまうと、延長されなくなるのか…。いやー、depth > 0 なら、leaf nodeの値が 伝播してくるから、そうでもないか…。わりといいアイデアかも知れん。
for(size_t i = 0 ; i < book_nodes.size() ; i++)
{
BookNode& book_node = book_nodes[i];
// leaf nodeでbest move以外の指し手が展開されるのは嫌だ。
//
// そこで、このnodeの指し手すべてに同一のノイズを加算する。
// こうすることでbest valueを持つmoveが展開される。
// (その指し手がleaf nodeでないなら、それが伝播してきて置き換わるから問題なし)
int noise = int(d(gen));
for(auto& move : book_node.moves)
move.vd.value += noise;
progress.check(++counter);
}
こう変更するだけでいいのか。
- makebook peta_shock_nextでは、1つのnodeの各指し手には同じノイズを加えるように変更。 leaf nodeでbest move以外の指し手が展開されるのは嫌だ。 そこで、このnodeの指し手すべてに同一のノイズを加算する。 こうすることでbest valueを持つmoveが展開される。 (その指し手がleaf nodeでないなら、それが伝播してきて置き換わるから問題なし)
やねうらお — 今日 21:43
peta_shock_next(次に掘るべきノードを列挙するコマンド)で、leaf nodeの各指し手の評価値にガウスノイズを加えるようにしていたのだが、これだと、leaf nodeでbest move(一番良い評価値の指し手)以外の指し手が容易に展開されてしまう。ノイズを加えるのは良いが、leaf nodeでは少なくともbest moveが展開されて欲しい。
そこで、あるleaf nodeで各指し手の評価値に加えるノイズは同じ値にすることにした。ちょっとしたhackだが、これでうまく動いているようである。
https://github.com/yaneurao/YaneuraOu/commit/68210f3c2012fd83fe11e1412e483eef5375575a
- メモリ足りんエラーでた。なんぞこれ? → メモリほんまに足りんだけやった。
>1:usi
>2:usi
<2:Error : option name not found : SkillLevel
<2:id name YaneuraOu(DR4) with peta-BOOK
<2:id author yaneurao
<2:option name Threads type spin default 1 min 1 max 512
<2:option name USI_Hash type spin default 512 min 1 max 33554432
<2:option name USI_Ponder type check default false
<2:option name Stochastic_Ponder type check default false
<2:option name MultiPV type spin default 1 min 1 max 800
<2:option name NetworkDelay type spin default 120 min 0 max 10000
<2:option name NetworkDelay2 type spin default 1120 min 0 max 10000
<2:option name MinimumThinkingTime type spin default 2000 min 1000 max 100000
<2:option name SlowMover type spin default 100 min 1 max 1000
<2:option name MaxMovesToDraw type spin default 0 min 0 max 100000
<2:option name DepthLimit type spin default 0 min 0 max 2147483647
<2:option name NodesLimit type spin default 0 min 0 max 9223372036854775807
<2:option name EvalDir type string default eval
<2:option name WriteDebugLog type string default
<2:option name GenerateAllLegalMoves type check default false
<2:option name EnteringKingRule type combo default CSARule27 var NoEnteringKing var CSARule24 var CSARule24H var CSARule27 var CSARule27H var TryRule
<2:option name ThreadIdOffset type spin default 0 min 0 max 15
<2:option name LargePageEnable type check default true
<2:option name USI_OwnBook type check default true
<2:option name NarrowBook type check default false
<2:option name BookMoves type spin default 999 min 0 max 10000
<2:option name BookIgnoreRate type spin default 0 min 0 max 100
<2:option name BookFile type combo default no_book var no_book var user_book1.db var user_book2.db var user_book3.db var book.bin
<2:option name BookDir type string default book
<2:option name BookEvalDiff type spin default 30 min 0 max 99999
<2:option name BookEvalBlackLimit type spin default -300 min -99999 max 99999
<2:option name BookEvalWhiteLimit type spin default -300 min -99999 max 99999
<2:option name BookDepthLimit type spin default 0 min 0 max 99999
<2:option name BookOnTheFly type check default false
<2:option name ConsiderBookMoveCount type check default false
<2:option name BookPvMoves type spin default 8 min 1 max 246
<2:option name IgnoreBookPly type check default true
<2:option name FlippedBook type check default true
<2:option name DrawValueBlack type spin default -2 min -30000 max 30000
<2:option name DrawValueWhite type spin default -2 min -30000 max 30000
<2:option name PvInterval type spin default 300 min 0 max 100000
<2:option name ResignValue type spin default 99999 min 0 max 99999
<2:option name ConsiderationMode type check default true
<2:option name OutputFailLHPV type check default true
<2:option name FV_SCALE type spin default 16 min 1 max 128
<2:usiok
>2:setoption name Threads value 8
>2:setoption name USI_Hash value 4096
>2:setoption name USI_Ponder value false
>2:setoption name Stochastic_Ponder value false
>2:setoption name MultiPV value 1
>2:setoption name NetworkDelay value 200
>2:setoption name NetworkDelay2 value 1200
>2:setoption name MinimumThinkingTime value 2000
>2:setoption name SlowMover value 100
>2:setoption name MaxMovesToDraw value 0
>2:setoption name DepthLimit value 0
>2:setoption name NodesLimit value 0
>2:setoption name EvalDir value eval
>2:setoption name WriteDebugLog value
>2:setoption name GenerateAllLegalMoves value false
>2:setoption name EnteringKingRule value CSARule27
>2:setoption name ThreadIdOffset value 0
>2:setoption name LargePageEnable value true
>2:setoption name USI_OwnBook value true
>2:setoption name NarrowBook value false
>2:setoption name BookMoves value 256
>2:setoption name BookIgnoreRate value 0
>2:setoption name BookFile value user_book1.db
>2:setoption name BookDir value book
>2:setoption name BookEvalDiff value 0
>2:setoption name BookEvalBlackLimit value -99999
>2:setoption name BookEvalWhiteLimit value -99999
>2:setoption name BookDepthLimit value 0
>2:setoption name BookOnTheFly value true
>2:setoption name ConsiderBookMoveCount value false
>2:setoption name BookPvMoves value 25
>2:setoption name IgnoreBookPly value true
>2:setoption name FlippedBook value true
>2:setoption name DrawValueBlack value -2
>2:setoption name DrawValueWhite value -2
>2:setoption name PvInterval value 300
>2:setoption name ResignValue value 99999
>2:setoption name ConsiderationMode value true
>2:setoption name OutputFailLHPV value true
>2:setoption name FV_SCALE value 24
>2:isready
<1:id name BLOSSOM with s-book_black
<1:id author yaneurao
<1:option name Threads type spin default 1 min 1 max 512
<1:option name USI_Hash type spin default 512 min 1 max 33554432
<1:option name USI_Ponder type check default false
<1:option name Stochastic_Ponder type check default false
<1:option name MultiPV type spin default 1 min 1 max 800
<1:option name NetworkDelay type spin default 120 min 0 max 10000
<1:option name NetworkDelay2 type spin default 1120 min 0 max 10000
<1:option name MinimumThinkingTime type spin default 2000 min 1000 max 100000
<1:option name SlowMover type spin default 100 min 1 max 1000
<1:option name MaxMovesToDraw type spin default 0 min 0 max 100000
<1:option name DepthLimit type spin default 0 min 0 max 2147483647
<1:option name NodesLimit type spin default 0 min 0 max 9223372036854775807
<1:option name EvalDir type string default eval
<1:option name WriteDebugLog type string default
<1:option name GenerateAllLegalMoves type check default false
<1:option name EnteringKingRule type combo default CSARule27 var NoEnteringKing var CSARule24 var CSARule24H var CSARule27 var CSARule27H var TryRule
<1:option name ThreadIdOffset type spin default 0 min 0 max 15
<1:option name LargePageEnable type check default true
<1:option name USI_OwnBook type check default true
<1:option name NarrowBook type check default false
<1:option name BookMoves type spin default 999 min 0 max 10000
<1:option name BookIgnoreRate type spin default 0 min 0 max 100
<1:option name BookFile type combo default no_book var no_book var user_book1.db var user_book2.db var user_book3.db var book.bin
<1:option name BookDir type string default book
<1:option name BookEvalDiff type spin default 30 min 0 max 99999
<1:option name BookEvalBlackLimit type spin default -300 min -99999 max 99999
<1:option name BookEvalWhiteLimit type spin default -300 min -99999 max 99999
<1:option name BookDepthLimit type spin default 0 min 0 max 99999
<1:option name BookOnTheFly type check default false
<1:option name ConsiderBookMoveCount type check default false
<1:option name BookPvMoves type spin default 8 min 1 max 246
<1:option name IgnoreBookPly type check default true
<1:option name FlippedBook type check default true
<1:option name SkillLevel type spin default 20 min 0 max 20
<1:option name DrawValueBlack type spin default -2 min -30000 max 30000
<1:option name DrawValueWhite type spin default -2 min -30000 max 30000
<1:option name PvInterval type spin default 300 min 0 max 100000
<1:option name ResignValue type spin default 99999 min 0 max 99999
<1:option name ConsiderationMode type check default true
<1:option name OutputFailLHPV type check default true
<1:option name FV_SCALE type spin default 16 min 1 max 128
<1:usiok
>1:setoption name Threads value 8
>1:setoption name USI_Hash value 4096
>1:setoption name USI_Ponder value false
>1:setoption name Stochastic_Ponder value false
>1:setoption name MultiPV value 1
>1:setoption name NetworkDelay value 120
>1:setoption name NetworkDelay2 value 1120
>1:setoption name MinimumThinkingTime value 2000
>1:setoption name SlowMover value 100
>1:setoption name MaxMovesToDraw value 0
>1:setoption name DepthLimit value 0
>1:setoption name NodesLimit value 0
>1:setoption name EvalDir value eval
>1:setoption name WriteDebugLog value
>1:setoption name GenerateAllLegalMoves value false
>1:setoption name EnteringKingRule value CSARule27
>1:setoption name ThreadIdOffset value 0
>1:setoption name LargePageEnable value true
>1:setoption name USI_OwnBook value true
>1:setoption name NarrowBook value false
>1:setoption name BookMoves value 999
>1:setoption name BookIgnoreRate value 0
>1:setoption name BookFile value user_book1.db
>1:setoption name BookDir value book
>1:setoption name BookEvalDiff value 0
>1:setoption name BookEvalBlackLimit value -300
>1:setoption name BookEvalWhiteLimit value -300
>1:setoption name BookDepthLimit value 0
>1:setoption name BookOnTheFly value false
>1:setoption name ConsiderBookMoveCount value false
>1:setoption name BookPvMoves value 8
>1:setoption name IgnoreBookPly value true
>1:setoption name FlippedBook value true
>1:setoption name SkillLevel value 20
>1:setoption name DrawValueBlack value -2
>1:setoption name DrawValueWhite value -2
>1:setoption name PvInterval value 300
>1:setoption name ResignValue value 99999
>1:setoption name ConsiderationMode value true
>1:setoption name OutputFailLHPV value true
>1:setoption name FV_SCALE value 24
>1:isready
<2:info string Hash table allocation: Windows Large Pages not used.
<1:info string Hash table allocation: Windows Large Pages not used.
<1:info string EvalDirectory = C:\Shogi\Shogidokoro\Engine\BLOSSOM-s-book_black/eval
<1:info string loading eval file : eval/nn.bin
<2:info string EvalDirectory = C:\Shogi\Shogidokoro\Engine\BLOSSOM-peta-book/eval
<2:info string loading eval file : eval/nn.bin
<1:info string read book file : book/user_book1.db
<2:info string Error! : can't alloc enough memory. in LargeMemory::alloc(4294967296,64)
<1:info string read book done. number of positions = 370525
<1:info string USI_Hash : Start clearing with 8 threads , Hash size = 4096[MB]
<1:info string USI_Hash : Finish clearing.
<1:readyok
>1:quit
- PvIntervalの上限、大きくした。
- MultiPVの時でもdepth 3以下のPVを強制出力していたのやめる。
- 宣言勝ちの局面テスト
position sfen 8K/PPPPPPPPP/LNSG1GSNL/9/9/9/9/9/4k4 b 9P2L2N2S2G b 1
- V7.75c = V7.75b9 = V7.75b + R20 = V7.70 + R120ぐらい?
・教師生成、置換表をクリアするオプション用意する。 ⇨ 置換表は、すでにクリアしてた。
・定跡生成手法、改良 ⇨ leaf nodeの指し手にガウスノイズ加えると良さげ。
// BFSして初期局面からの手数を計算する。
cout << "BFS for eval bonus for ply." << endl;
progress.check(book_nodes.size());
u64 counter = 0;
for(auto root_sfen : root_sfens)
{
// 作業対象nodeが入っているqueue
// このqueueは処理順は問題ではないので両端queueでなくて良いからvectorで実装しておく。
deque<BookNodeIndexPly> queue;
deque<StateInfo> si;
BookTools::feed_position_string(pos, root_sfen, si);
auto hash_key = pos.state()->hash_key();
if (this->hashkey_to_index.count(hash_key) > 0)
{
BookNodeIndex index = hashkey_to_index[hash_key];
int ply = pos.game_ply();
queue.push_back(BookNodeIndexPly(index , ply));
}
while (queue.size())
{
BookNodeIndexPly ip = queue[0];
queue.pop_front();
int ply = ip.ply;
auto& book_node = book_nodes[ip.index];
// このnodeは計算済みであるか?
if (book_node.ply !=0)
continue;
// 忘れないうちに代入しておく。
book_node.ply = ply;
for(auto& book_move : book_node.moves)
{
BookNodeIndex next = book_move.next;
if (next == BookNodeIndexNull)
{
// leaf moveなのでせっかくだからここでevalを補整しとくか…。
if (bonus != 0)
{
// 先手から見たvalueなので後手なら反転させて考える必要がある。
book_move.vd.value -= (int)((book_node.color == BLACK ? 1 : -1) * ply * bonus);
}
} else {
queue.push_back(BookNodeIndexPly(next,ply+1));
}
}
progress.check(++counter);
}
}
⇓
// leaf nodeの指し手の評価値に乱数を加える。
if (leaf_move_rand != 0)
{
cout << "add random bonus for every leaf move." << endl;
progress.check(book_nodes.size());
// 乱数生成器
std::random_device rd;
std::mt19937 gen(rd());
// 正規分布を定義(平均 = 0 , 標準偏差 = leaf_move_rand)
std::normal_distribution<> d(0, leaf_move_rand);
u64 counter = 0;
for(size_t i = 0 ; i < book_nodes.size() ; i++)
{
BookNode& book_node = book_nodes[i];
for(auto& move : book_node.moves)
move.vd.value += d(gen);
progress.check(++counter);
}
}
- peta next コマンド例
SkipLoadingEval true
DrawValueBlack 0
DrawValueWhite 0
makebook peta_shock_next book.db peta_next_sfens.txt 30 50
quit
- makebook peta_shock_next コマンドでガウスノイズを定跡DBのleaf nodeの指し手の評価値に加えてからminmaxできるようにした。
やねうらお — 今日 05:25
leaf nodeの指し手の評価値にガウスノイズを加える。コードとしては、以下のようになる。
std::random_device rd;
std::mt19937 gen(rd());
// 正規分布を定義(平均 = 0 , 標準偏差 = leaf_move_rand)
std::normal_distribution<> d(0, leaf_move_rand);
for(size_t i = 0 ; i < book_nodes.size() ; i++)
{
BookNode& book_node = book_nodes[i];
for(auto& move : book_node.moves)
move.vd.value += d(gen);
}
たったこれだけなのだが、これが驚くほどうまく機能する。
浅く探索した時の評価値というのは、もともと真の値(深く探索した時の評価値)からは、離れていて、それはガウスノイズが加わっているものと解釈できる。
なので、ここでガウスノイズを加えてから定跡木をminmaxして最善応手列を得ることで、(数学的に)堅牢な定跡を得ることができる。
- V7.75b = V7.75a11 = V7.70 + R100ぐらい?
・null moveの時にNNUEの計算端折れる件、調査する。 ⇨ わかったが、どうにもならんわ、これ。 Introduce a function to compute NNUE accumulator : https://github.com/official-stockfish/Stockfish/commit/08385527dd470ece814ac85013802995a0e7f6ca
-
V7.75b1
- excludedMoveまわりのコード、新しいコードに戻してみる。
- assert( v > -INF && v < INF ) みたいなの、assert ( -INF < v && v < INF)にしとく。
- mate1と宣言勝ち、!excludedMoveの条件追加。
- hash衝突で何か拾ってきたときに、このnodeにsaveするのまずい。
engine1 = YaneuraOuNNUE_V775a11_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V775b1_1024.exe , eval = Li T2,b1000,132 - 7 - 91(59.19% R64.61[25.76,103.46]) winrate black , white = 48.43% , 51.57% → これも違いそう。
-
V7.75b2
- Improve excluded move logic : https://github.com/official-stockfish/Stockfish/commit/8d3457a9966f8c744ab7f8536be408196ccd8af9
//eval = ss->staticEval;
// ⇓ evaluate()いるんちゃう?
eval = ss->staticEval = evaluate(pos);
→ これでなおるみたいやな…なんなんや、これ。 → あー、わかった。NNUEの差分計算できなくなるのか。
Introduce a function to compute NNUE accumulator : https://github.com/official-stockfish/Stockfish/commit/08385527dd470ece814ac85013802995a0e7f6ca
やねうらお — 今日 23:08
https://github.com/official-stockfish/Stockfish/commit/08385527dd470ece814ac85013802995a0e7f6ca
この長大なcommit、NNUEの差分計算だけを実行するためのもので(つまりは、do_move()のあとevaluate()を呼ばずにさらにdo_move()した時に差分計算ができないから、それを回避するためのもの)、やねうら王で言うとEval::evaluate_with_no_return()なのだが、那須さんは、Eval::evaluate_with_no_return()をやねうら王にNNUEのプルリクした時にはすでに実装してくれてて、たぬきさんが、StockfishにNNUEをプルリクした時に、それいらねーみたいな感じで端折ったため、いまごろになってこの機能が必須であることに気づいたvondeleさん(Stockfishの主力開発者)が自力実装したっぽい。(たぶん)
GitHub
Introduce a function to compute NNUE accumulator · official-stockfi...
This patch introduces `hint_common_parent_position()` to signal that potentially several child nodes will require an NNUE eval. By populating explicitly the accumulator, these subsequent evaluation...
Introduce a function to compute NNUE accumulator · official-stockfi...
やねうらお — 今日 23:09
ここにいたる流れを言うと⇓ここでexcludedMoveがある局面に対してhashkeyをこねこねしてprobe()するのやめようぜ、と言う提案(プルリク)が来て、ここに
Side note:
Very surprisingly it looks like we cannot use static eval's from
TT since they slightly differ over time due to changing optimism.
Attempts to use static eval's from TT did loose about 13 ELO.
This is something about to investigate.
みたいなことが書いてあるのだ。
https://github.com/official-stockfish/Stockfish/commit/8d3457a9966f8c744ab7f8536be408196ccd8af9
GitHub
Improve excluded move logic · official-stockfish/Stockfish@8d3457a
PR consists of 2 improvements on nodes with excludeMove:
1. Remove xoring the posKey with make_key(excludedMove)
Since we never call tte->save anymore with excludedMove,
the unique l...
Improve excluded move logic · official-stockfish/Stockfish@8d3457a
サイドノート:
非常に驚くべきことに、静的評価をTTから使うことはできないようです。
これは、時間とともに変わる楽観性のために、わずかに異なるためです。
TTからの静的評価を使用しようとした試みは、約13 ELOを失いました。
これは調査するべきことです。
要するに、「なんでか知らんけど、eval = ss->staticEval; とやって、staticEval使おうと思ったら、それだけでめっちゃ弱なった、ありえん。原因調査しる!」とのことである。
言うまでもなく、この原因は、evaluate()すっ飛ばしてdo_move()して次のnodeに行ってevaluate()したからNNUEの差分計算おかしなった(差分計算ができない?計算を間違う?)からである。
このように差分計算の必須な評価関数、探索部の改良と相性悪いんだよなー。
みんなハマるのである。
engine1 = YaneuraOuNNUE_V775a11_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V775b2_1024.exe , eval = Li T2,b1000,1930 - 155 - 1945(49.81% R-1.34[-10.52,7.83]) winrate black , white = 52.05% , 47.95% → ほぼ変わらへん…。
- V7.75b3
eval = ss->staticEval;
// ⇓ evaluate()いるんちゃう?
//eval = ss->staticEval = evaluate(pos);
// evaluate()呼び出さんと、NNUEの評価関数次の局面で差分計算しくるのでは…。
// cf. https://github.com/official-stockfish/Stockfish/commit/08385527dd470ece814ac85013802995a0e7f6ca
Eval::evaluate_with_no_return(pos);
engine1 = YaneuraOuNNUE_V775a11_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V775b3_1024.exe , eval = Li T2,b1000,2052 - 150 - 1518(57.48% R52.36[42.69,62.03]) winrate black , white = 50.76% , 49.24% → これじゃないのだ…。
-
V7.75b4
- hint_common_parent_position()を evaluate_with_no_return()に変更してみる。
engine1 = YaneuraOuNNUE_V775b_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V775b4_1024.exe , eval = Li T2,b1000,220 - 18 - 162(57.59% R53.16[23.62,82.71]) winrate black , white = 53.14% , 46.86% → これじゃないっぽい。
-
V7.75b5
- V7.75b2にrollback
- search()でmate1plyでなく3plyを呼び出す。
engine1 = YaneuraOuNNUE_V775b_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V775b5_1024.exe , eval = Li T2,b1000,1494 - 151 - 1685(47.0% R-20.9[-31.05,-10.75]) winrate black , white = 50.27% , 49.73% → そんなに悪くないんだよなー。 3手詰めになってなかったか。しまった。これ計測ミスか。
-
V7.75b6
- 1手詰めを宣言勝ちより先に判定するようにした。
- 1手詰め・宣言勝ちの条件を、pvnodeなら必ずという条件を緩和してrootnodeに変更した。
if (!rootNode && !excludedMove && !ttMove) {
engine1 = YaneuraOuNNUE_V775b_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V775b6_1024.exe , eval = Li T2,b1000,1400 - 131 - 1529(47.8% R-15.31[-25.88,-4.74]) winrate black , white = 52.75% , 47.25% T2,b2000,609 - 74 - 657(48.1% R-13.18[-29.25,2.89]) winrate black , white = 51.82% , 48.18% → なんでか知らんけど、つよなった。
- V7.75b7
- search(),qsearch()ともに1手詰めなくした。
// 静止探索での1手詰め
// 重要度 ★★☆☆☆
// 元の値 = 1
// → 1スレ2秒で対技巧だと有りのほうが強かったので固定しておく。
// NNUEだと、これ無しのほうが良い可能性がある。
// いったん無しでやって最後に有りに変更して有効か見る。
// 2スレ1,2秒程度だと無しと有意差がなかったが、4秒~8秒では、有りのほうが+R30ぐらい強い。
// [PARAM] min:0,max:1,step:1,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_QSEARCH_MATE1 = 0;
// 通常探索での1手詰め
// 重要度 ★★☆☆☆
// → よくわからないが1スレ2秒で対技巧だと無しのほうが強かった。
// 1スレ3秒にすると有りのほうが強かった。やはり有りのほうが良いのでは..
// 元の値 = 1
// [PARAM] min:0,max:1,step:1,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_SEARCH_MATE1 = 0;
engine1 = YaneuraOuNNUE_V775b_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V775b7_1024.exe , eval = Li T2,b1000,1393 - 124 - 1573(46.97% R-21.11[-31.62,-10.6]) winrate black , white = 52.23% , 47.77% → そこまで悪くないんだよなー。 → 静止探索での1手詰め、要らん可能性あるな…。 → 持ち時間増やすとそうでもないのか…。
PARAM_WEAK_MATE_PLY
これ反映してないんじゃ.. ⇨ テスト失敗してそう
-
V7.75b8
- テスト失敗した。破棄。
-
V7.75b8a
- 3手詰めになったなかったので再テスト
move = Mate::weak_mate_3ply(pos,3);
if (move != MOVE_NONE)
{
// N手詰めかも知れないのでPARAM_WEAK_MATE_PLY手詰めのスコアを返す。
bestValue = mate_in(ss->ply + 3);
ASSERT_LV3(pos.legal_promote(move));
tte->save(posKey, value_to_tt(bestValue, ss->ply), ss->ttPv, BOUND_EXACT,
std::min(MAX_PLY - 1, depth + 8), move, /* ss->staticEval */ bestValue);
return bestValue;
}
engine1 = YaneuraOuNNUE_V775b_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V775b8a_1024.exe , eval = Li T2,b1000,468 - 44 - 418(52.82% R19.63[0.41,38.85]) winrate black , white = 49.32% , 50.68%
⇨ これは弱いと見てよさそう。
- V7.75b9
- 3手詰めのコード、掃除。棋力変化ないはず。
} else {
move = Mate::weak_mate_3ply(pos,PARAM_WEAK_MATE_PLY);
if (move != MOVE_NONE)
{
// N手詰めかも知れないのでPARAM_WEAK_MATE_PLY手詰めのスコアを返す。
bestValue = mate_in(ss->ply + PARAM_WEAK_MATE_PLY);
ASSERT_LV3(pos.legal_promote(move));
tte->save(posKey, value_to_tt(bestValue, ss->ply), ss->ttPv, BOUND_EXACT,
std::min(MAX_PLY - 1, depth + 8), move, /* ss->staticEval */ bestValue);
return bestValue;
}
}
}
//
// mate..
//
// 静止探索での1手詰め
// 重要度 ★★☆☆☆
// 元の値 = 1
// → 1スレ2秒で対技巧だと有りのほうが強かったので固定しておく。
// NNUEだと、これ無しのほうが良い可能性がある。
// いったん無しでやって最後に有りに変更して有効か見る。
// 2スレ1,2秒程度だと無しと有意差がなかったが、4秒~8秒では、有りのほうが+R30ぐらい強い。
// [PARAM] min:0,max:1,step:1,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_QSEARCH_MATE1 = 1;
// 通常探索での1手詰め
// 重要度 ★★☆☆☆
// → よくわからないが1スレ2秒で対技巧だと無しのほうが強かった。
// 1スレ3秒にすると有りのほうが強かった。やはり有りのほうが良いのでは..
// 元の値 = 1
// [PARAM] min:0,max:1,step:1,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_SEARCH_MATE1 = 1;
// 1手詰めではなくN手詰めを用いる
// 重要度 ★★☆☆☆
// ※ 3手,5手はコストに見合わないようだ。
// 元の値 = 1
// [PARAM] min:1,max:5,step:2,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_WEAK_MATE_PLY = 1;
if (!ttMove)
{
// 1手詰めなのでこの次のnodeで(指し手がなくなって)詰むという解釈
if (PARAM_WEAK_MATE_PLY == 1)
{
if (Mate::mate_1ply(pos) != MOVE_NONE)
{
//bestValue = mate_in(ss->ply + 1);
//tte->save(posKey, value_to_tt(bestValue, ss->ply), ss->ttPv, BOUND_EXACT,
// std::min(MAX_PLY - 1, depth + 6), move, /* ss->staticEval */ bestValue);
// ⇨ 置換表に書き出しても得するかわからなかった。(V7.74taya-t9 vs V7.74taya-t12)
return mate_in(ss->ply + 1);
}
}
else
{
if (Mate::weak_mate_3ply(pos, PARAM_WEAK_MATE_PLY) != MOVE_NONE)
// 1手詰めかも知れないがN手詰めの可能性があるのでNを返す。
return mate_in(ss->ply + PARAM_WEAK_MATE_PLY);
}
// このnodeに再訪問することはまずないだろうから、置換表に保存する価値はない。
}
→ 掃除。
// -----------------------
// 一手詰め判定
// -----------------------
// 置換表にhitした場合は、すでに詰みを調べたはずなので
// 置換表にhitしなかったときにのみ調べる。
ASSERT_LV3(!ss->inCheck && !ss->ttHit);
// 1手詰めなのでこの次のnodeで(指し手がなくなって)詰むという解釈
if (Mate::mate_1ply(pos) != MOVE_NONE)
{
//bestValue = mate_in(ss->ply + 1);
//tte->save(posKey, value_to_tt(bestValue, ss->ply), ss->ttPv, BOUND_EXACT,
// std::min(MAX_PLY - 1, depth + 6), move, /* ss->staticEval */ bestValue);
// ⇨ 置換表に書き出しても得するかわからなかった。(V7.74taya-t9 vs V7.74taya-t12)
return mate_in(ss->ply + 1);
}
engine1 = YaneuraOuNNUE_V775b_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V775b9_1024.exe , eval = Li T2,b1000,1272 - 106 - 1402(47.57% R-16.9[-27.97,-5.84]) winrate black , white = 52.51% , 47.49% T2,b2000,828 - 90 - 952(46.52% R-24.24[-37.82,-10.67]) winrate black , white = 52.53% , 47.47%
-
V7.75b10
- V7.75b9から。
- 1手詰め判定、削除してみる。
engine1 = YaneuraOuNNUE_V775b_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V775b10_1024.exe , eval = Li T2,b1000,1196 - 106 - 1358(46.83% R-22.07[-33.4,-10.74]) winrate black , white = 51.84% , 48.16% T2,b2000,712 - 84 - 714(49.93% R-0.49[-15.62,14.64]) winrate black , white = 52.81% , 47.19% ⇨ 秒が長くなってくると得してないな…。
engine1 = YaneuraOuNNUE_V775b9_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V775b10_1024.exe , eval = Li T2,b4000,405 - 64 - 391(50.88% R6.11[-14.14,26.36]) winrate black , white = 50.63% , 49.37% T4,b4000,187 - 36 - 177(51.37% R9.55[-20.38,39.48]) winrate black , white = 46.7% , 53.3% ⇨ 対局回数が少なくてよくわからないが、無いほうがいいとは言いにくいな…。
-
V7.75 = 基準 : 第4回 電竜戦バージョン やねうら王GitHub
-
V7.75a1
-
Simplify history update. : https://github.com/official-stockfish/Stockfish/commit/13426a93c187c4953388a4484b8da69ee6f26fa3
-
history statsの更新式、Stockfish 14の頃の式に戻った。
// Stockfish 16のコード
-
// entry += (bonus * D - entry * abs(bonus)) / (D * 5 / 4);
// → この新しい計算式、良くなかった。R-20。
// ひとまず適用保留。
//
// 上式は、Stockfish 14のコードの全体に0.8を掛けている。
//
// (bonus - entry * abs(bouns) / D) * 0.8
// = (bonus - entry * abs(bouns) / D) * 4/5
// = (bonus - entry * abs(bouns) / (D * 5 / 4)
// ⇓こう変形したほうが演算の精度は高い気はするが。
// = (bonus - entry * abs(bouns) * 4 / (D * 5)
// いずれにせよ、0.8掛け算するの、良くない。
// TODO : この係数、パラメーターチューニングで調整すべき。
//
⇓ entry += bonus - entry * abs(bonus) / D;
- stat_bonus等に変更があった。
engine1 = YaneuraOuNNUE_V775_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V775a1_1024.exe , eval = Li T2,b1000,2930 - 215 - 2855(50.65% R4.5[-3.01,12.02]) winrate black , white = 51.7% , 48.3%
→ stat_bonusの式の変更、よくない可能性あるな…。
-
V7.75a2
-
Simplify doDeeperSearch : https://github.com/official-stockfish/Stockfish/commit/f17db4641e0ec3a3d633cff6abc83e980a04ac4c
const bool doDeeperSearch = value > (bestValue + 51 + 10 * (newDepth - d));
⇓
const bool doDeeperSearch = value > (bestValue + 50 + 2 * newDepth); // (~1 Elo)
- V7.75a3
- Simplify quietMoveMalus malus : https://github.com/official-stockfish/Stockfish/commit/7dc40ac6437ec96d312e387b76573e5c496bd0b6
int quietMoveMalus = stat_malus(depth + 1);
⇓
int quietMoveMalus = stat_malus(depth);
engine1 = YaneuraOuNNUE_V775_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V775a3_1024.exe , eval = Li T2,b1000,2852 - 204 - 2944(49.21% R-5.52[-13.02,1.99]) winrate black , white = 52.24% , 47.76%
-
V7.75a4
-
Skip LMR for 2nd move at the root only : https://github.com/official-stockfish/Stockfish/commit/85403a89bac9fe3538ae410fe651364abf78c504
if ( depth >= 2
&& moveCount > 1 + (PvNode && ss->ply <= 1)
&& ( !ss->ttPv
|| !capture
|| (cutNode && (ss - 1)->moveCount > 1)))
⇓
if ( depth >= 2
&& moveCount > 1 + rootNode
&& ( !ss->ttPv
|| !capture
|| (cutNode && (ss - 1)->moveCount > 1)))
- V7.75a5
- Tweak return value in futility pruning : https://github.com/official-stockfish/Stockfish/commit/08cdbca56fac98513481683a92eb1ecdc00d3f6e
&& eval >= beta && eval < 29462 // smaller than TB wins
&& (!ttMove || ttCapture))
return eval;
⇓
&& eval >= beta && eval < 29462 // smaller than TB wins
&& (!ttMove || ttCapture))
return (eval + beta) / 2;
engine1 = YaneuraOuNNUE_V775_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V775a5_1024.exe , eval = Li T2,b1000,2836 - 207 - 2957(48.96% R-7.26[-14.77,0.25]) winrate black , white = 51.44% , 48.56%
// --- コードの整理
// qsearchの時に、see<=0の指し手を枝刈りするか。
// 重要度 ★★★★☆
// 元の値 = 0 , step = 1
// [PARAM] min:0,max:1,step:1,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_QSEARCH_PRUNE_LE0_SEE_MOVE = 0;
→ 削除
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V775a5_1024.exe , eval = Li T2,b1000,977 - 68 - 1065(47.85% R-14.98[-27.64,-2.33]) winrate black , white = 52.11% , 47.89% → 最終、V770から+R15ぐらいなのか。
- V7.75a6
やねうらお — 今日 00:02
■ excludedMoveがある時にmake_key()しない件
あー、わかってしまった。たややんさんが以前⇓これを適用したら弱くなったと言っていた件、よく考えたら、excludedMoveがある時、tablebases(終盤定跡)のprobeできないわ。だってexcludedMoveを除外して残りの指し手についてそのノードを探索しているので、これで1手詰みみたいなものがあったとしても、それがこの除外した指し手であるとexcludedMoveを正確に反映した探索とは言えないのだ。だから、⇓このcommitを取り込む時に、やねうら王のmate_1ply(1手詰め判定)を呼び出す前に、!excludedMove と言う条件が必要になるんじゃないのかな。いやー、そうか…これは難しい。😟 これ、気づくのに2ヶ月かかったわ。(ずっと考えてたわけではないけども..)
https://github.com/official-stockfish/Stockfish/commit/8d3457a9966f8c744ab7f8536be408196ccd8af9
-
excludedMoveがあるなら、mate1,宣言勝ちを呼ばない。
- よく考えたらexcludedMoveがあるならttHitしてるから、もとより呼んでないか。
engine1 = YaneuraOuNNUE_V775a5_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V775a6_1024.exe , eval = Li T2,b1000,536 - 42 - 522(50.66% R4.6[-12.97,22.16]) winrate black , white = 53.59% , 46.41% → 関係なさげ。rollback
-
V7.75a7
-
V7.75a5から。 // recaptureに関しては、よく考えたほうがいい。
-
Remove recaptures stage in qsearch : https://github.com/official-stockfish/Stockfish/commit/15d47a2b3821b92c4d048f39f7f43c301299d365
-
stage = (pos.in_check() ? EVASION_TT : QSEARCH_TT) +
!(ttm
&& (pos.in_check() || pos.capture(ttm))
&& pos.pseudo_legal(ttm));
engine1 = YaneuraOuNNUE_V775a5_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V775a7_1024.exe , eval = Li T2,b1000,2862 - 204 - 2934(49.38% R-4.32[-11.82,3.19]) winrate black , white = 51.97% , 48.03% → 単にcapture()よさそう。
- V7.75a8
- V7.75a5から。
stage = (pos.in_check() ? EVASION_TT : QSEARCH_TT) +
!(ttm
&& (pos.in_check() || depth > DEPTH_QS_RECAPTURES || pos.capture(ttm))
&& pos.pseudo_legal(ttm));
engine1 = YaneuraOuNNUE_V775a5_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V775a8_1024.exe , eval = Li T2,b1000,2869 - 207 - 2924(49.53% R-3.3[-10.81,4.21]) winrate black , white = 50.8% , 49.2%
engine1 = YaneuraOuNNUE_V775a7_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V775a8_1024.exe , eval = Li T2,b1000,2861 - 212 - 2927(49.43% R-3.96[-11.47,3.55]) winrate black , white = 52.59% , 47.41%
→ 計測できない差。a8の方がいいか?
- V7.75a9
-
V7.75a8から。
-
Remove cutNode condition : https://github.com/official-stockfish/Stockfish/commit/7a8bcfc229ca6e4e44c0b284b7609a3aa26fa1ee
-
// Increase reduction for cut nodes without ttMove (~1 Elo)
if (!ttMove && cutNode)
r += 2;
⇓
// Increase reduction if ttMove is not present (~1 Elo)
if (!ttMove)
r += 2;
engine1 = YaneuraOuNNUE_V775a8_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V775a9_1024.exe , eval = Li T2,b1000,1428 - 101 - 1431(49.95% R-0.36[-11.05,10.32]) winrate black , white = 51.24% , 48.76% → 計測できない差。
- V7.75a10
-
V7.75a9から。
-
PARAM_FUTILITY_AT_PARENT_NODE_GAMMA1 : 31 → 26
-
taya版と探索部の差異を小さく。
-
MovePickerのrecaptureの引数なくす。
-
強さほぼ変わらんはずやけど計測はしとくか。 → なんか強さえらい変わってる。上のパラメーター変更、そんな大きいのか…? → 2乗に比例するからか…。
-
// Prune moves with negative SEE (~4 Elo)
// lmrDepthの2乗に比例するのでこのパラメーターの影響はすごく大きい。
if (!pos.see_ge(move, Value(- PARAM_FUTILITY_AT_PARENT_NODE_GAMMA1 * lmrDepth * lmrDepth)))
continue;
engine1 = YaneuraOuNNUE_V775a9_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V775a10_1024.exe , eval = Li T2,b1000,2208 - 153 - 2229(49.76% R-1.64[-10.22,6.93]) winrate black , white = 50.62% , 49.38% → 計測不能な差。
- V7.75a11
- V7.75a10から。⇑の変更だけrollback。
- PARAM_FUTILITY_AT_PARENT_NODE_GAMMA1 : 26 → 31
- PARAM_FUTILITY_EVAL1,PARAM_FUTILITY_EVAL2追加。
- V7.75a10から。⇑の変更だけrollback。
if (lmrDepth < PARAM_PRUNING_BY_HISTORY_DEPTH/*6*/ && history < -3645 * depth)
continue;
history += 2 * thisThread->mainHistory(us, from_to(move));
lmrDepth += history / 7836;
lmrDepth = std::max(lmrDepth, -1);
→ ここ、以前の値に戻してしまっていた。rollback。 → よく見たら壊してなかった。たややん版を壊して、それをコピーしてしまっていたのか…。
-
Extend by two if the side to move has only one legal move #4894 : https://github.com/official-stockfish/Stockfish/pull/4894/files
- あー、これやらないから、excludedMove除外して指し手がないときに、mate扱いになるか?
- 正式にmergeされてから考えよう。
-
make_key()のcommitをrollback
- Improve excluded move logic : https://github.com/official-stockfish/Stockfish/commit/8d3457a9966f8c744ab7f8536be408196ccd8af9
- これまだなんかおかしいのだ。
engine1 = YaneuraOuNNUE_V775a10_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V775a11_1024.exe , eval = Li T2,b1000,2164 - 218 - 2948(42.33% R-53.71[-61.8,-45.62]) winrate black , white = 51.53% , 48.47%
→ あれ、まだ新しいコードバグってたのか。つよなった。
→ 新しいコードで正しく動くようにしないと…。
-
V7.74z
- 残り時間でincreaseDepth変えているところを以前のコードに戻す。
- ここ、探索に影響する。
- 残り時間でincreaseDepth変えているところを以前のコードに戻す。
// 前回からdepthが増えたかのチェック。
// depthが増えて行っていないなら、同じ深さで再度探索する。
else if (!mainThread->ponder
&& Time.elapsed() > totalTime * 0.58)
Threads.increaseDepth = false;
else
Threads.increaseDepth = true;
⇑以前のコード
⇓いまのコード
else if (!mainThread->ponder && Time.elapsed() > totalTime * 0.50)
Threads.increaseDepth = false;
else
Threads.increaseDepth = true;
engine1 = YaneuraOuNNUE_V774y_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V774z_1024.exe , eval = Li T3,b1000,960 - 77 - 1063(47.45% R-17.7[-30.42,-4.99]) winrate black , white = 51.95% , 48.05% ⇨ これ、わりとでかそう。
- V7.74z2
// 残り時間的に、次のiterationに行って良いのか、あるいは、探索をいますぐここでやめるべきか?
if (Limits.use_time_management())
{
// まだ停止が確定していない
// (このへんの仕組み、やねうら王では、Stockfishとは異なる)
if (!Threads.stop && Time.search_end == 0)
{
// 1つしか合法手がない(one reply)であるだとか、利用できる時間を使いきっているだとか、
double fallingEval = (66 + 14 * (mainThread->bestPreviousAverageScore - bestValue)
+ 6 * (mainThread->iterValue[iterIdx] - bestValue)) / 583.0;
fallingEval = std::clamp(fallingEval, 0.5, 1.5);
// If the bestMove is stable over several iterations, reduce time accordingly
// もしbestMoveが何度かのiterationにおいて安定しているならば、思考時間もそれに応じて減らす
timeReduction = lastBestMoveDepth + 8 < completedDepth ? 1.56 : 0.69;
double reduction = (1.4 + mainThread->previousTimeReduction) / (2.03 * timeReduction);
// rootでのbestmoveの不安定性。
// bestmoveが不安定であるなら思考時間を増やしたほうが良い。
double bestMoveInstability = 1 + 1.79 * totBestMoveChanges / Threads.size();
double totalTime = Time.optimum() * fallingEval * reduction * bestMoveInstability;
// 合法手が1手しかないときはtotalTime = 0として、即指しする。(これはやねうら王独自改良)
if (rootMoves.size() == 1)
totalTime = 0;
// bestMoveが何度も変更になっているならunstablePvFactorが大きくなる。
// failLowが起きてなかったり、1つ前の反復深化から値がよくなってたりするとimprovingFactorが小さくなる。
// Stop the search if we have only one legal move, or if available time elapsed
if (Time.elapsed() > totalTime)
{
// 停止条件を満たした
// 将棋の場合、フィッシャールールではないのでこの時点でも最小思考時間分だけは
// 思考を継続したほうが得なので、思考自体は継続して、キリの良い時間になったらcheck_time()にて停止する。
// ponder中なら、終了時刻はponderhit後から計算して、Time.minimum()。
if (mainThread->ponder)
Time.search_end = Time.minimum();
else
{
// "ponderhit"しているときは、そこからの経過時間を丸める。
// "ponderhit"していないときは開始からの経過時間を丸める。
// そのいずれもTime.elapsed_from_ponderhit()で良い。
Time.search_end = std::max(Time.round_up(Time.elapsed_from_ponderhit()), Time.minimum());
}
}
// 前回からdepthが増えたかのチェック。
// depthが増えて行っていないなら、同じ深さで再度探索する。
// ここは固定秒での対局であっても、探索に影響する。
// Stockfish 14ではtotalTime * 0.58、Stockfish 16では totalTime * 0.50となっているが
// Stockfish 14の方の定数が勝りそう。(V7.74taya-t3 VS V7.74taya-t4)
// ここはパラメーター調整すべき。
else if (!mainThread->ponder && Time.elapsed() > totalTime * 0.50)
Threads.increaseDepth = false;
else
Threads.increaseDepth = true;
}
}
⇓以前のコードにrollback
// 残り時間的に、次のiterationに行って良いのか、あるいは、探索をいますぐここでやめるべきか?
if (Limits.use_time_management())
{
// まだ停止が確定していない
// (このへんの仕組み、やねうら王では、Stockfishとは異なる)
if (!Threads.stop && Time.search_end == 0)
{
// 1つしか合法手がない(one reply)であるだとか、利用できる時間を使いきっているだとか、
double fallingEval = (69 + 12 * (mainThread->bestPreviousAverageScore - bestValue)
+ 6 * (mainThread->iterValue[iterIdx] - bestValue)) / 781.4;
fallingEval = std::clamp(fallingEval, 0.5, 1.5);
// If the bestMove is stable over several iterations, reduce time accordingly
// もしbestMoveが何度かのiterationにおいて安定しているならば、思考時間もそれに応じて減らす
timeReduction = lastBestMoveDepth + 10 < completedDepth ? 1.63 : 0.73;
double reduction = (1.56 + mainThread->previousTimeReduction) / (2.20 * timeReduction);
// rootでのbestmoveの不安定性。
// bestmoveが不安定であるなら思考時間を増やしたほうが良い。
double bestMoveInstability = 1 + 1.7 * totBestMoveChanges / Threads.size();
#if 0
int complexity = mainThread->complexityAverage.value();
double complexPosition = std::clamp(1.0 + (complexity - 326) / 1618.1, 0.5, 1.5);
double totalTime = Time.optimum() * fallingEval * reduction * bestMoveInstability * complexPosition;
// → やねうら王ではcomplexityを導入しないので、以前のコードにしておく。
#endif
// 合法手が1手しかないときはtotalTime = 0となり、即指しする計算式。
double totalTime = rootMoves.size() == 1 ? 0 :
Time.optimum() * fallingEval * reduction * bestMoveInstability;
// bestMoveが何度も変更になっているならunstablePvFactorが大きくなる。
// failLowが起きてなかったり、1つ前の反復深化から値がよくなってたりするとimprovingFactorが小さくなる。
// Stop the search if we have only one legal move, or if available time elapsed
if (Time.elapsed() > totalTime)
{
// 停止条件を満たした
// 将棋の場合、フィッシャールールではないのでこの時点でも最小思考時間分だけは
// 思考を継続したほうが得なので、思考自体は継続して、キリの良い時間になったらcheck_time()にて停止する。
// ponder中なら、終了時刻はponderhit後から計算して、Time.minimum()。
if (mainThread->ponder)
Time.search_end = Time.minimum();
else
{
// "ponderhit"しているときは、そこからの経過時間を丸める。
// "ponderhit"していないときは開始からの経過時間を丸める。
// そのいずれもTime.elapsed_from_ponderhit()で良い。
Time.search_end = std::max(Time.round_up(Time.elapsed_from_ponderhit()), Time.minimum());
}
}
else if (!mainThread->ponder
&& Time.elapsed() > totalTime * 0.58)
Threads.increaseDepth = false;
else
Threads.increaseDepth = true;
}
}
engine1 = YaneuraOuNNUE_V774y_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V774z2_1024.exe , eval = Li T3,b1000,983 - 92 - 1005(49.45% R-3.85[-16.66,8.97]) winrate black , white = 54.73% , 45.27% ⇨ ここまでrollbackするの駄目っぽい。破棄。
- V7.74z3
-
MOVE_WINのコード、復活させる。
-
else if (!mainThread->ponder
&& Time.elapsed() > totalTime * 0.58)
これだけ適用する。
engine1 = YaneuraOuNNUE_V774y_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V774z3_1024.exe , eval = Li T3,b1000,1451 - 135 - 1414(50.65% R4.49[-6.19,15.16]) winrate black , white = 52.53% , 47.47% ⇨ 優劣不明。よくわからん…。 MOVE_WINのコード、復活させた善悪がわからん。 なくても影響軽微か。滅多に出てこないし…。
- V7.74z4
if (is_ok(m))
tte->save(posKey, value_to_tt(bestValue, ss->ply), ss->ttPv, BOUND_EXACT,
MAX_PLY, m, ss->staticEval);
// [2023/10/17]
// → MOVE_WINの値は、置換表に書き出さないほうがいいと思う。
// probeでこのMOVE_WINのケースを完全に考慮するのは非常に難しい。
// is_ok(m)は、MOVE_WINではない通常の指し手(トライルールの時の51玉のような指し手)は
// 置換表に書き出すという処理。
⇨ このif式をとる。あー、しかしここMAX_PLYだと置換表のreplacement strategy阻害するか。
depthにすべきか…?
if (is_ok(m))
tte->save(posKey, value_to_tt(bestValue, ss->ply), ss->ttPv, BOUND_EXACT,
DEPTH_NONE, m, ss->staticEval);
こう変更する。(DEPTH_NONEは探索せずに求めたからという意味) mate1とかもそうなんか…そうか…。
-
V7.74z5
- Learner::searchのaspiration searchまわり、現在の探索部のaspiration searchのコードの内容を反映させた。
-
V7.74z6
- V7.74z4のdepth、よく考えたらDEPTH_NONEだとこれで枝刈りされなくて書き出し損なのか…。
- MAX_PLY / 4とかでないといかんのか。 ⇨ これやはりいいアイデアじゃなさげ。やめやめ。
engine1 = YaneuraOuNNUE_V774z3_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V774z6_1024.exe , eval = Li T2,b1000,1415 - 112 - 1443(49.51% R-3.4[-14.09,7.28]) winrate black , white = 51.99% , 48.01% ⇨ 少しいい可能性がある?
-
V7.74z7
- qsearch()のmate1plyも置換表に書き出すことにした。
- ほとんど得はしなさそう。 → これやめる。
-
V7.74z8
- V7.74z4から。
- 置換表から取り出した指し手のlegality checkに引っかかったら置換表にhitしなかったことにする。
// ⇑ここ、tte->move()はMove16なので、やねうら王ではpos.to_move()でMoveに変換する必要があることに注意。
// pos.to_move()でlegalityのcheckに引っかかったパターンなので置換表にhitしなかったことにする。
if (tte->move().to_u16() && !ttMove)
ss->ttHit = false;
pvHit = ss->ttHit && tte->is_pv();
- V7.74z9
- V7.74z8から。
- MOVE_WINのこと忘れてた。
if (ttMove)
⇓
if (/* ttMove && */ is_ok(ttMove))
⇨ しかしMOVE_WIN書き出すの筋が良くないのでこれrollbackすることにした。
-
V7.74z10
- update_continuation_histories() で 1,2,4,6でなく1,2,3,4,6に。
- capture()になっていたところ、capture_stage()に変更。
- capture_stage()の実装がcapture()を呼び出しているので、棋力に変化はないはず。
engine1 = YaneuraOuNNUE_V774z6_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V774z10_1024.exe , eval = Li T2,b1000,833 - 58 - 749(52.65% R18.47[4.08,32.85]) winrate black , white = 52.02% , 47.98%
⇨ なんかよわなってる。rollbackしよ…。
-
V7.74z11
- V7.74z4から。 1手詰めsaveするdepthをMAX_PLYから⇓に変更。 std::min(MAX_PLY - 1, depth + 6)
engine1 = YaneuraOuNNUE_V774z6_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V774z11_1024.exe , eval = Li T2,b1000,2877 - 230 - 2893(49.86% R-0.96[-8.49,6.56]) winrate black , white = 50.76% , 49.24% ⇨ 棋力に影響なさそう。
-
V7.74z12
- stat_bonusをStockfish 14の式にする。
// Stockfish 14の時の式の方が良さげ。
int stat_bonus(Depth d) { return std::min(336 * d - 547, 1561); }
int stat_malus(Depth d) { return std::min(336 * d - 547, 1561); }
engine1 = YaneuraOuNNUE_V774z6_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V774z12_1024.exe , eval = Li T2,b1000,1839 - 131 - 1850(49.85% R-1.04[-10.44,8.37]) winrate black , white = 52.24% , 47.76% → 強くなってるとは言い難いのでこれは適用しないでおく。
- V7.74y
-
V7.74x3から。
-
movepick.cppのqsearch()用のコード、以下のようにrollback。
-
{
// 静止探索から呼び出されているので残り深さはゼロ以下。
ASSERT_LV3(d <= 0);
// 王手がかかっているなら王手回避のフェーズへ。さもなくばQSEARCHのフェーズへ。
// stage = (pos.in_check() ? EVASION_TT : QSEARCH_TT) + !(ttm && pos.pseudo_legal(ttm));
// ⇨ Stockfish 16のコード、ttm(置換表の指し手)は無条件でこのMovePickerが返す1番目の指し手としているが、これだと
// TTの指し手だけで千日手になってしまうことがある。これは、将棋ではわりと起こりうる。
// 対策としては、qsearchで千日手チェックをしたり、SEEが悪いならskipするなど。
// ※ ここでStockfish 14のころのように置換表の指し手に条件をつけるのは良くなさげ。(V7.74l3 と V7.74mとの比較)
// Stockfish 14のコード
stage = (pos.in_check() ? EVASION_TT : QSEARCH_TT) +
!(ttm
&& (pos.in_check() || depth > DEPTH_QS_RECAPTURES || to_sq(ttm) == recaptureSquare)
&& pos.pseudo_legal(ttm));
}
- さらにqsearch()のis_repetitionを以下のようにコメントアウト。
#if 0
auto draw_type = pos.is_repetition(ss->ply);
if (draw_type != REPETITION_NONE)
return value_from_tt(draw_value(draw_type, us), ss->ply);
// 16手以内の循環になってないのにqsearchで16手も延長している場合、
// 置換表の指し手だけで長い循環になっている可能性が高く、
// これは引き分け扱いにしてしまう。(やねうら王独自改良)
#endif
if (ss->ply >= MAX_PLY /*|| depth <= -16*/)
return draw_value(REPETITION_DRAW, pos.side_to_move());
engine1 = YaneuraOuNNUE_V774x3_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V774y_1024.exe , eval = Li T3,b2000,548 - 79 - 663(45.25% R-33.09[-49.58,-16.6]) winrate black , white = 54.17% , 45.83% ⇨ 対局回数少ないが、なんかつよなってへんか?771aともやらせてみる。 qsearchで千日手調べるの、よくなさげやな…。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V774y_1024.exe , eval = Li T3,b2000,651 - 77 - 692(48.47% R-10.61[-26.21,4.99]) winrate black , white = 51.75% , 48.25% ⇨ そんなつよなってはなさそう。前よりは良くなったか…。
-
V7.74x1とV7.74x2
- EVASIONでMVV/LVAをcapture()にするのとcapture_or_promotion()にするのとで比較。
V7.74x1
// 王手回避の指し手をスコアリングする。
if (pos.capture(m))
// 捕獲する指し手に関しては簡易SEE + MVV/LVA
V7.74x2
// 王手回避の指し手をスコアリングする。
if (pos.capture_or_promotion(m))
// 捕獲する指し手に関しては簡易SEE + MVV/LVA
engine1 = YaneuraOuNNUE_V774x1_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V774x2_1024.exe , eval = Li T3,b2000,1357 - 165 - 1338(50.35% R2.45[-8.56,13.46]) winrate black , white = 53.14% , 46.86% → 優劣不明
V7.74x3
m.value = (Value)Eval::CapturePieceValue[pos.piece_on(to_sq(m))]
- (Eval::PieceValue[pos.moved_piece_before(m)]/16)
// → /16 は、価値の低い駒にして欲しいが、まずはCapturePieceValueの大きな順になって欲しいので、
// スケールを小さくしている。
+ (1 << 28);
⇨ ここ、ちゃんとLVAにした方がいいと思う。その上で、Promoteの価値も見積もるべき。 ⇨ LVA、PieceValueから計算できるかと思ったら、そうではなかった。
V7.74x2から
m.value = Eval::CapturePieceValuePlusPromote(pos, m)
- Value(LVA(type_of(pos.moved_piece_before(m))))
// ↑ここ、LVAテーブル使わずにPieceValueを64で割るとかできなくもないが、
// 下手にやると、香と桂にような価値が近い駒に対して優先順位がつけられない。
// 愚直にLVAテーブル使うべき。
+ (1 << 28);
// ⇑これは、captureの指し手のスコアがそうでない指し手のスコアより
// 常に大きくなるようにするための下駄履き。
// ※ captureの指し手の方がそうでない指し手より稀なので、この下駄履きは、
// captureの時にしておく。
こう変更してみる。
engine1 = YaneuraOuNNUE_V774x1_1024.exe , eval = Li
engine2 = YaneuraOuNNUE_V774x3_1024.exe , eval = Li
T3,b2000,1171 - 140 - 1259(48.19% R-12.59[-24.19,-0.99]) winrate black , white = 53.54% , 46.46%
⇨ だいぶレート落としてたんだな…。
- V7.74x
- NON_CAPTURES_ALL、CAPTURES_ALL追加。この2つの指し手生成追加。
やねうらお — 今日 14:18
■ captures(駒を取る手)とpawn promotion(歩の成り)との関係
Bonanza時代は、指し手orderingの時に、capturesのなかにpromotions(駒を成る指し手)が含まれていた。
ところが銀など成っても価値はほとんど変わらないので、そんなものを特別扱いしても効果がなくて、Aperyを始めとするStockfishを取り入れたソフトは歩の成りだけに制限した。つまりcaptures + pawn promotionをcapturesとみなした。
つまり、通常探索のorderingは、以下の順番でなされるようになった。
TT(置換表の指し手)→captures(captures + pawn promotion)→killers→quiets(残りの指し手)
ここから進化して、killersはrefutationsと呼ばれるようになり、また、capturesのうち、seeが悪い指し手はbad capturesとして扱い、quietsのあとに回すようになった。
つまり、
TT→captures→refutations→quiets→bad captures
の順になった。
orderingの仕組みが発達すると、pawn promotionをcapturesに入れたほうが良いか微妙になってきた。それでもStockfish 14のころは入れたほうが良かったのだが、現在は怪しくなってきている。
pawn promotionをcapturesに含めないなら、全合法手生成モード(GenerateAllLegalMovesオプション)のために、captures_all(歩や大駒の不成の指し手も生成するcaptures)/non_captures_all を用意しなければならない。
そこでこの2つの指し手生成器をまず用意した。
https://github.com/yaneurao/YaneuraOu/commit/859c91637a00c794aa2c0647020d8213547faaa2
-
V7.74w
- GENERATE_PRO_PLUS追加。
- あり → V7.74w1
- なし → V7.74w2 で比較してみる。
engine1 = YaneuraOuNNUE_V774w1_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V774w2_1024.exe , eval = Li T3,b2000,1449 - 185 - 1636(46.97% R-21.09[-31.39,-10.78]) winrate black , white = 52.93% , 47.07% → PRO_PLUS、よくないっぽいんだよなぁ…。
- GENERATE_PRO_PLUS追加。
-
V7.74v3
- V7.74v2から。
- ProbCutで置換表の指し手はseeの条件外す。 ⇓
stage = PROBCUT_TT + !(ttm && pos.pseudo_legal(ttm));
// TTの指し手は優遇する。(qsearchと同様)
- EVASIONの時にpromotionもMVV/LVAでスコアリングするように
// 王手回避の指し手をスコアリングする。
if (pos.capture_or_promotion(m))
engine1 = YaneuraOuNNUE_V774v2_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V774v3_1024.exe , eval = Li T3,b2000,1671 - 173 - 1446(53.61% R25.12[14.86,35.38]) winrate black , white = 52.68% , 47.32% → これやってたらあかんかったか。
-
V7.74v2
-
V7.74uから。
-
movepicker.cppで、refutationの時にcapture_stage()呼び出してたの間違いだった。これ修正。 capture_or_pawn_promotion()を用いるべきであった。
-
movepicker.cppのStagesの定数でアンダースコアが入っていたもの、アンダースコア削除。
-
movepicker.cppに状態遷移図追加。
engine1 = YaneuraOuNNUE_V774u_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V774v2_1024.exe , eval = Li T3,b2000,550 - 78 - 582(48.59% R-9.82[-26.81,7.16]) winrate black , white = 52.3% , 47.7% ⇨ この精度だとV7.74vとどちらがいいかわからない。ソースコード整理して直接対決させるか。
-
-
V7.74v
- V7.74uから。
- movepicker.cppで CAPTURE_PRO_PLUSで生成するのやめる。
- どうせそのあとのseeで成りが考慮されないので…
- あのsee、正確でないの、よろしくないのではないか…。
⇨ 完全にやめるのは、やはり良くないのか…。
engine1 = YaneuraOuNNUE_V774u_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V774v_1024.exe , eval = Li T3,b2000,597 - 56 - 627(48.77% R-8.52[-24.85,7.82]) winrate black , white = 51.8% , 48.2%
-
V7.74u
-
V7.74sから。
-
movepick.hの更新式、Stockfish 14のコードに戻してみる。
-
// Stockfish 14のコード
entry += bonus - entry * abs(bonus) / D;
// Stockfish 16のコード
// entry += (bonus * D - entry * abs(bonus)) / (D * 5 / 4);
// → この新しい計算式、良くなかった。
// TODO : この係数、パラメーターチューニングで調整すべき。
V7.74tの変更で勝ってた分がなくなるので…。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V774u_1024.exe , eval = Li T3,b2000,166 - 20 - 164(50.3% R2.11[-29.31,33.52]) winrate black , white = 55.76% , 44.24% → 途中なのでよくわからん。再計測する。 T3,b2000,584 - 67 - 619(48.55% R-10.11[-26.59,6.37]) winrate black , white = 50.62% , 49.38%
// V771aを基準比較するのは、相当回数対局させないと難しいのかも知れない。
engine1 = YaneuraOuNNUE_V774t_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V774u_1024.exe , eval = Li T3,b2000,573 - 71 - 606(48.6% R-9.73[-26.37,6.92]) winrate black , white = 53.69% , 46.31%
-
V7.74t
- check_time()インデントがおかしくなっていたの修正。
- check_timeの時刻チェックの頻度、以前のものに戻す。 callsCnt = Limits.nodes ? std::min(512, int(Limits.nodes / 1024)) : 512; ⇓ callsCnt = Limits.nodes ? std::min(1024, int(Limits.nodes / 1024)) : 1024;
⇨ これで、V7.72aと比較してみる。
⇨ いやー、この変更はよくないか。ここでR3ほど損するのは許容することにしないと…。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V774t_1024.exe , eval = Li T3,b2000,618 - 61 - 601(50.7% R4.85[-11.52,21.21]) winrate black , white = 51.27% , 48.73% ⇨ 回数少ないが、super sortありでまだ互角ぐらいか..
-
V7.74s
- NNUE_FIX_OVERFLOW 追加。
-
V7.74r4
-
ENABLE_QUICK_DRAW導入
-
Position::set_repetition_ply()追加
Stockfishのようにrootより遡らない場合、どうもR5ぐらい弱い…。 また、千日手のカウントをするとStateInfoに変数3つ増えるのでこの初期化とかコピーとかの オーバーヘッドがあって、これでR5ぐらい損をする模様。 ENABLE_QUICK_DRAWが定義されている時は千日手の回数のカウントをなしにして、 かつ、rootより遡ることにする。(従来動作)
-
やねうらお — 今日 05:53
残念なことに千日手をきちんと判定しようと思うとR5~R10損することがわかった。
そんなわけで従来動作を復活させた。ENABLE_QUICK_DRAWをdefineしていると従来動作になる。
またトーナメントモード用のビルドだと自動的にENABLE_QUICK_DRAWがdefineされる。
-
V7.74r3
- MAX_REPETITION_PLY導入。
- ANALYSE_MODEをデフォルトにしてコードclean up
- Position::is_repetition2()削除
- Position::is_repetition()整理
たぶん、1,2秒は問題ないだろうから、4秒でテストしておく。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V774r3_1024.exe , eval = Li T3,b4000,638 - 81 - 591(51.91% R13.29[-3.01,29.6]) winrate black , white = 54.6% , 45.4% // USI_Hashが512なので相対的に互角に近くなっている可能性が出てきた。
-
V7.74r2
-
V7.74rから。
-
ANALYSE_MODEオン
-
do_move()の時のrepetitionの処理、間違ってたの修正。
-
if (hand_is_equal_or_superior(stp->hand, st ->hand))
{
st->repetition_type = REPETITION_SUPERIOR;
st->repetition = i;
break;
}
⇓こちらが正しい。
if (hand_is_equal_or_superior(stp->hand, st ->hand))
{
st->repetition_type = REPETITION_INFERIOR;
st->repetition = i;
break;
}
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li
engine2 = YaneuraOuNNUE_V774r2_1024.exe , eval = Li
T3,b1000,3127 - 186 - 2687(53.78% R26.34[18.83,33.86]) winrate black , white = 52.0% , 48.0%
T3,b2000,837 - 83 - 800(51.13% R7.85[-6.27,21.98]) winrate black , white = 52.9% , 47.1%
⇨ なんか1秒は悪いなー。なんなんや…。
2秒ではほぼ変わらんから、これ採用しとくか。
- V7.74r
- V7.74qから。
- V7.74mの改造、取り下げ。
- ANALYSE_MODEオフ
stage = (pos.in_check() ? EVASION_TT : QSEARCH_TT) +
!(ttm
// ttm(置換表の指し手)が次の時だけ、ttmをこのMovePickerが返す1番目の指し手として採用する。
// 1. 王手がかかっている場合
// 2. (depth > DEPTH_QS_RECAPTURESの時)
// 3. ttmが取り返す指し手 (depth <= DEPTH_QS_RECAPTURESの時)
// ※ recaptures は、正確には「取り返す」ではなく、1手前での駒の移動先を今回の駒の移動先とする指し手。
// つまり、直前に動かされた駒を取る指し手
// 3.の条件が厳しいので、ttmだけで千日手にはならない。
//
&& (pos.in_check() || depth > DEPTH_QS_RECAPTURES || to_sq(ttm) == recaptureSquare)
&& pos.pseudo_legal(ttm));
⇓
stage = (pos.in_check() ? EVASION_TT : QSEARCH_TT) + !(ttm && pos.pseudo_legal(ttm));
- PARAM_LMR_MARGIN3削除
// 重要度 ★★★☆☆
// 元の値 = 700 , step = 100
// [PARAM] min:0,max:1024,step:50,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_LMR_MARGIN3 = 700;
-
Change depth - 1 to newDepth : https://github.com/official-stockfish/Stockfish/commit/504bf0e8b8cf2dd818deb623c5ad7e428e504cd8
-
Remove doEvenDeeperSearch : https://github.com/official-stockfish/Stockfish/commit/b59786e750a59d3d7cff2630cf284553f607ed29
-
Reformat some comments : https://github.com/official-stockfish/Stockfish/commit/b4e9ee72e36aadd0e653ac4ab5c07a9e3d639aca
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V774r_1024.exe , eval = Li T3,b1000,2999 - 221 - 2780(51.89% R13.17[5.65,20.7]) winrate black , white = 51.36% , 48.64% T3,b2000,1310 - 121 - 1239(51.39% R9.68[-1.64,21.0]) winrate black , white = 52.22% , 47.78%
-
V7.74q2
-
V7.74qから。
-
ANALYSE_MODEオン。
-
ANALYSE_MODEに、優等局面/劣等局面の判定導入。
-
#if defined(ANALYSE_MODE)
// Calculate the repetition info. It is the ply distance from the previous
// occurrence of the same position, negative in the 3-fold case, or zero
// if the position was not repeated.
// 繰り返し情報を計算します。これは、同じ局面の前回の発生からの手数で(1,2回目)、
// 3回繰り返しの場合は負の値、または局面が繰り返されていない場合はゼロです。
// ⇨ 要するに千日手成立時にだけ負。つまり、やねうら王では、1,2,3回目は正、4回目を負。
st->repetition = 0;
st->repetition_times = 0; // やねうら王独自追加
st->repetition_type = REPETITION_NONE; // やねうら王独自追加
//int end = std::min(st->rule50, st->pliesFromNull);
//int end = st->pliesFromNull;
int end = std::min(16, st->pliesFromNull); // 遡り最大16手
// 最低でも4手はないと同一局面に戻ってこない。
if (end >= 4)
{
StateInfo* stp = st->previous->previous;
for (int i = 4; i <= end; i += 2)
{
stp = stp->previous->previous;
if (stp->board_key() == st->board_key())
{
// 手駒が一致するなら同一局面である。(2手ずつ遡っているので手番は同じである)
if (stp->hand == st->hand)
{
// 同一局面が見つかった。
// 以下、Stockfishのコードは利用せず、将棋風に書き換えてある。
// 繰り返し回数のカウント
st->repetition_times = stp->repetition_times + 1;
// (同一局面の)3回目までは正(4回目以降は負)の手数にする。
// st->repetition_timesは、3回目の時点において、2になっている。
st->repetition = st->repetition_times >= 3 ? -i : i;
// 自分が王手をしている連続王手の千日手なのか?
// 相手が王手をしている連続王手の千日手なのか?
st->repetition_type = (i <= st->continuousCheck[ sideToMove]) ? REPETITION_LOSE
: (i <= st->continuousCheck[~sideToMove]) ? REPETITION_WIN
: REPETITION_DRAW;
// 途中が連続王手でない場合、4回目の同一局面で連続王手の千日手は成立せず、普通の千日手となる。
//
// よって、例えば、3..4回目までの間が連続王手であっても、前回(2..3回目までの間)がREPETITION_DRAW
// であれば、今回をREPETITION_DRAWとして扱わなければならない。
//
// これは、『将棋ガイドブック』P.14に以下のように書かれている。
//
// > 一局中同一局面の最初と4回目出現の局面の間の一方の指し手が王手の連続であった時、
// > 連続王手をしていた側にとって4回目の同一局面が出現した時
// 同様の理屈により、1..2回目が先手の連続王手で、2..3回目が後手の連続王手のような場合も、
// このまま4回目に達した場合、これは普通の千日手局面である。
// ゆえに、3回目以降の同一局面の出現において、
// 前回のrepetition_typeと今回のrepetition_typeが異なるならば、今回のrepetition_typeを
// 普通の千日手(REPETITION_DRAW)として扱わなければならない。
if (stp->repetition_times && st->repetition_type != stp->repetition_type)
st->repetition_type = REPETITION_DRAW;
break;
} else {
// 優等局面か劣等局面であるか。(手番が相手番になっている場合はいま考えない)
if (hand_is_equal_or_superior(st ->hand, stp->hand))
{
st->repetition_type = REPETITION_SUPERIOR;
st->repetition = i;
break;
}
if (hand_is_equal_or_superior(stp->hand, st ->hand))
{
st->repetition_type = REPETITION_SUPERIOR;
st->repetition = i;
break;
}
}
}
}
}
#endif
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li
engine2 = YaneuraOuNNUE_V774q2_1024.exe , eval = Li
T3,b1000,146 - 1 - 3(97.99% R674.89[514.04,835.74]) winrate black , white = 53.69% , 46.31%
⇨ めっさ弱い。何か盛大にバグっている。
-
V7.74q
-
V7.74o4から。
-
ANALYSE_MODE追加。デフォルトOFF。
-
is_repetition2()廃止。is_repetition()を使うように変更。
-
ANALYSE_MODEオフにして計測。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V774q_1024.exe , eval = Li T3,b1000,2936 - 201 - 2863(50.63% R4.37[-3.13,11.88]) winrate black , white = 50.85% , 49.15% T3,b2000,2962 - 282 - 2756(51.8% R12.52[4.96,20.08]) winrate black , white = 52.27% , 47.73%
-
-
V7.74p4
- V7.74p3から。
⇓4回目に達するまで千日手としないように変更してみる。
if (st->repetition && st->repetition < ply)
return st->repetition_type;
return REPETITION_NONE;
⇨ 結論的には、 1. 16手という制限なしに初手まで遡るようにする -R40 2. 4度目の出現までrootより遡らない -R5 3. 優等局面/劣等局面の判定なくす -R10 みたいな感じなのかなー。
1.は、チェスだと平均手数100手ぐらいしかないので、問題にならなかったのが、
将棋だと平均手数160手、多い時は300手ぐらいはあるので、無視できないんだなー。
探索部でdo_move()した以上、repetitionのチェックはするので、repetitionの判定をdo_move()で行うのは
ほとんどロスは無いと見て良さそう。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li
engine2 = YaneuraOuNNUE_V774p4_1024.exe , eval = Li
T3,b1000,2960 - 230 - 2810(51.3% R9.03[1.51,16.56]) winrate black , white = 51.56% , 48.44%
⇨ そんなに悪くはなさそうなんだよなー。R5以下の差。
- V7.74p3
-
V7.74p2から。
-
repetitionの判定、間違ってた。
-
if (st->repetition_times && st->repetition_type != stp->repetition_type)
st->repetition_type = REPETITION_DRAW;
⇓正しい
if (stp->repetition_times && st->repetition_type != stp->repetition_type)
st->repetition_type = REPETITION_DRAW;
これしかしst->repetition_timesはつねに0だから成立しないだけでは…。
- V7.74p2
-
V7.74pから。
-
is_repetition3
-
if (st->repetition)
return st->repetition_type;
return REPETITION_NONE;
- do_moveで、千日手検出のために遡る手数を16に制限。
int end = std::min(16, st->pliesFromNull); // 遡り最大16手
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li
engine2 = YaneuraOuNNUE_V774p2_1024.exe , eval = Li
T3,b1000,3073 - 228 - 2699(53.24% R22.54[15.01,30.08]) winrate black , white = 51.94% , 48.06%
⇨ そこまで悪くない。やはり手数を制限なしに遡ることでR40ぐらい損するのか…。
-
V7.74p
-
is_repetition2をis_repetition3に変更してみる。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V774p_1024.exe , eval = Li T3,b1000,348 - 17 - 245(58.68% R60.97[37.15,84.78]) winrate black , white = 52.95% , 47.05%
⇨ めっさよわい。原因特定する。
-
-
V7.74o4
- null moveの時に⇓も必要なのではないかという結論になった。
// 現局面には王手はかかっていないので、直前には王手はされていない、すなわちこの関数が呼び出された時の
// 非手番側(いまのsideToMove)である
// st->continuousCheck[sideToMove] == 0
// が言える。連続王手の千日手の誤判定を防ぐためにこの関数が呼び出された時の手番側(~sideToMove)も
// 0にリセットする必要がある。
ASSERT_LV3(st->continuousCheck[sideToMove] == 0);
st->continuousCheck[~sideToMove] = 0;
- V7.74o3は、st->hand修正した結果、正常に機能するようになって、null moveが絡む連続王手を間違って判定して、害のほうが大きいからレーティングを落としているのではないかという結論になった。
⇨ これ正解だったようで、このバグ修正によって +R10ぐらい強くなってそう。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li
engine2 = YaneuraOuNNUE_V774o4_1024.exe , eval = Li
T3,b1000,2919 - 225 - 2856(50.55% R3.79[-3.73,11.31]) winrate black , white = 52.76% , 47.24%
- V7.74o3
-
V7.74o2から st->repetitionなどをコメントアウト。
-
Position::UnitTestにassert追加。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V774o3_1024.exe , eval = Li
T3,b1000,2948 - 240 - 2812(51.18% R8.2[0.67,15.74]) winrate black , white = 52.01% , 47.99% T3,b2000,512 - 54 - 434(54.12% R28.71[10.08,47.35]) winrate black , white = 52.01% , 47.99%
-
evaldir suisho20230503
bench
V7.74l3
===========================
Total time (ms) : 60011
Nodes searched : 47859619
Nodes_searched/second : 797514
Nodes_searched/second : 801422
===========================
The bench command has completed.
V7.74o3
===========================
Total time (ms) : 60010
Nodes searched : 47606010
Nodes_searched/second : 793301
Nodes_searched/second : 798568
===========================
The bench command has completed.
→ nps落ちてるわけではなさそうなのになんでこんな弱くなるのだ…。
-
V7.74o2
- V7.74oから⇓をコメントアウト // Increase reduction on repetition (~1 Elo) // 千日手模様ならreductionを増やす。 // → 4手前とmoveが同じであるケースのみ調べる。 if (move == (ss-4)->currentMove && pos.has_repeated()) r += 2;
- Position::do_move()での⇓の更新処理コメントアウトしてなかったのでこれもコメントアウト。 // Calculate the repetition info. It is the ply distance from the previous // occurrence of the same position, negative in the 3-fold case, or zero // if the position was not repeated.
⇨ assert無効化するの忘れてた。そのせいで落ちる模様。
-
V7.74o
- null moveの時にst->handの更新忘れていたの修正
// 手番が変わるので手番側の手駒情報であるst->handの更新が必要。
st->hand = hand[sideToMove];
- このため、千日手判定の時に同一局面なのに同一局面だと判定されないことがあったようだ。
-
V7.74mに戻して、⇑の修正だけ適用して棋力計測。⇓この解除忘れてた。
// Increase reduction on repetition (~1 Elo) // 千日手模様ならreductionを増やす。 // → 4手前とmoveが同じであるケースのみ調べる。 if (move == (ss-4)->currentMove && pos.has_repeated()) r += 2;
⇨ assert無効化するの忘れてた。そのせいで落ちる模様。
- V7.74n
-
V7.74mから。
-
Position::is_repetition3()追加。
-
二度目の同一局面では千日手と判定しないことにした。
- ただしroot以降で探索中に同じ局面に遭遇した場合は千日手と判定して枝刈りする。
-
千日手判定のために遡る手数として16手をやめて、対局開始までずっと遡ることにした。
-
優等局面/劣等局面の判定、やめた。
-
Position::has_repeated()追加。
-
千日手模様の時にreduction増やす。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V774n_1024.exe , eval = Li T3,b1000,606 - 37 - 387(61.03% R77.9[59.32,96.49]) winrate black , white = 50.45% , 49.55% T3,b2000,273 - 19 - 178(60.53% R74.3[46.8,101.8]) winrate black , white = 49.89% , 50.11% ⇨ めっちゃ悪なった。原因調査中。
-
■ 千日手判定の件
2回目の同一局面で千日手(評価値 0)になるの、おかしいやろというコメントをlishogiのcommitterから頂戴している。 https://github.com/yaneurao/YaneuraOu/pull/266#issuecomment-1806947355
確かに人間が指した棋譜を解析させる場合において、2度目で0になられたら困る気はする。(実際はAIなら、もっといい/もっと悪い評価値の局面に誘導できる可能性が高いので)
-
V7.74m move pickerでqsearch時はTTの指し手であろうと、depthが小さい時はrecaptureの指し手に制限する。(以前のコード)
stage = (pos.in_check() ? EVASION_TT : QSEARCH_TT) + !(ttm // ttm(置換表の指し手)が次の時だけ、ttmをこのMovePickerが返す1番目の指し手として採用する。 // 1. 王手がかかっている場合 // 2. (depth > DEPTH_QS_RECAPTURESの時) // 3. ttmが取り返す指し手 (depth <= DEPTH_QS_RECAPTURESの時) // ※ recaptures は、正確には「取り返す」ではなく、1手前での駒の移動先を今回の駒の移動先とする指し手。 // つまり、直前に動かされた駒を取る指し手 // 3.の条件が厳しいので、ttmだけで千日手にはならない。 // && (pos.in_check() || depth > DEPTH_QS_RECAPTURES || to_sq(ttm) == recaptureSquare) && pos.pseudo_legal(ttm));
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V774m_1024.exe , eval = Li T3,b1000,2959 - 199 - 2842(51.01% R7.01[-0.5,14.51]) winrate black , white = 52.73% , 47.27% T3,b2000,2578 - 264 - 2418(51.6% R11.13[3.04,19.22]) winrate black , white = 52.32% , 47.68% ⇨ 計測できないレベルの差。強くなっているとは言い難い。これ採用しないことにする。
-
V7.74l3
- V7.74l2から
// move pickerでsortする閾値 (super sort使用時) // 重要度 ★★★★★ // 元の値 = 1960 , step = 1 // [PARAM] min:0,max:3000,step:480,interval:1,time_rate:1 PARAM_DEFINE PARAM_MOVEPICKER_SORT_TH1 = 2500; ⇑3000から2500に変更してテスト。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V774l3_1024.exe , eval = Li T3,b1000,2946 - 224 - 2830(51.0% R6.98[-0.54,14.5]) winrate black , white = 51.3% , 48.7% T3,b2000,2921 - 286 - 2793(51.12% R7.78[0.22,15.35]) winrate black , white = 53.01% , 46.99%
⇨ V7.74l1よりわずかに強そうなので、これ採用しておく。
-
V7.74l2
- super sort有効
- PARAM_MOVEPICKER_USE_SUPERSORT削除
// move pickerでsuper sortを用いるか // 重要度 ★★★★☆ // 元の値 = 0 , step = 1 // [PARAM] min:0,max:1,step:1,interval:1,time_rate:1,fixed PARAM_DEFINE PARAM_MOVEPICKER_USE_SUPERSORT = 1;
☑・SuperSortもっかい調整して本当に使えないか確認する。
-
V7.74l
- V7.74k4から
-
Fix undefined behavior in search. : https://github.com/official-stockfish/Stockfish/commit/7970236e9ea64796d5c7597cb1aedde737751f07
-
Introduce recapture extensions : https://github.com/official-stockfish/Stockfish/commit/863a1f2b4cb233be3126b244cbd8f6c8b9b4d13c
-
Symmetrize optimism : https://github.com/official-stockfish/Stockfish/commit/f9d8717844643e4ea3723f5ea240bf5d22800df7
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V774l_1024.exe , eval = Li T3,b1000,2965 - 212 - 2823(51.23% R8.53[1.01,16.04]) winrate black , white = 50.83% , 49.17% T3,b2000,2932 - 314 - 2754(51.57% R10.88[3.3,18.46]) winrate black , white = 52.62% , 47.38%
⇨ ちょっとつよなったっぽい。
-
V7.74k4
- V7.74k3から
⇓こう変更 // move pickerでsortする閾値 (super sort使用時) // 重要度 ★★★★★ // 元の値 = 1960 , step = 1 // [PARAM] min:0,max:3000,step:480,interval:1,time_rate:1 PARAM_DEFINE PARAM_MOVEPICKER_SORT_TH1 = 3000;
// move pickerでsortする係数 (super sort使用時) // 重要度 ★★★★★ // 元の値 = 3130 , step = 1 // [PARAM] min:0,max:6000,step:500,interval:1,time_rate:1,fixed PARAM_DEFINE PARAM_MOVEPICKER_SORT_ALPHA1 = 3150;
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V774k4_1024.exe , eval = Li T3,b1000,2991 - 217 - 2792(51.72% R11.96[4.44,19.48]) winrate black , white = 51.69% , 48.31% T3,b2000,3020 - 253 - 2727(52.55% R17.73[10.18,25.28]) winrate black , white = 51.64% , 48.36%
⇨ V7.74k2に対して良いとは言い難いか…。PARAM_MOVEPICKER_SORT_TH1 = 3000でもまだ大きいのか…。2500ぐらいが最適値かな?
-
V7.74k3
-
super sort有効の時に有効になってなかったの修正。
-
tuning parameter無効
-
super sort有効
-
pawn history無効
⇓こう変更 // move pickerでsortする閾値 (super sort使用時) // 重要度 ★★★★★ // 元の値 = 1960 , step = 1 // [PARAM] min:0,max:3000,step:480,interval:1,time_rate:1 PARAM_DEFINE PARAM_MOVEPICKER_SORT_TH1 = 3000;
// move pickerでsortする係数 (super sort使用時) // 重要度 ★★★★★ // 元の値 = 3130 , step = 1 // [PARAM] min:0,max:6000,step:500,interval:1,time_rate:1,fixed PARAM_DEFINE PARAM_MOVEPICKER_SORT_ALPHA1 = 3500;
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V774k3_1024.exe , eval = Li T3,b1000,2942 - 222 - 2836(50.92% R6.37[-1.14,13.89]) winrate black , white = 52.34% , 47.66% T3,b2000,3021 - 323 - 2656(53.21% R22.37[14.77,29.97]) winrate black , white = 52.32% , 47.68%
-
-
V7.74k2
-
tuning parameter無効
-
super sort無効
-
pawn history無効
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V774k2_1024.exe , eval = Li T3,b1000,3062 - 211 - 2727(52.89% R20.13[12.6,27.65]) winrate black , white = 50.75% , 49.25% T3,b2000,1902 - 186 - 1762(51.91% R13.28[3.83,22.73]) winrate black , white = 51.77% , 48.23%
⇨ pawn history結局、無効の方が強そう。
-
-
V7.74k1
-
tuning parameter無効
-
super sort無効
-
pawn history有効
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V774k1_1024.exe , eval = Li T3,b1000,3055 - 233 - 2712(52.97% R20.69[13.15,28.23]) winrate black , white = 51.73% , 48.27% T3,b2000,2019 - 163 - 1668(54.76% R33.18[23.72,42.63]) winrate black , white = 51.86% , 48.14%
-
調整後
#ifndef YANEURAOU_PARAM_H_INCLUDED
#define YANEURAOU_PARAM_H_INCLUDED
// yaneuraou-param.h : 元ファイル
// param_conv.pyというPythonのスクリプトにより、以下のファイルは自動生成されます。
// 1) yaneuraou - param - extern.h
// 2) yaneuraou - param - array.h
// 3) yaneuraou - param - string.h
// 1),2),3)のファイルは手で編集しないでください。
//#if defined(GENSFEN2019)
// 教師局面生成用のパラメーター
// 低depthで強くする ≒ 低depth時の枝刈りを甘くする。
//#include "yaneuraou-param_gen.h"
// → 教師生成時と学習時の探索部の性質が違うのはNNUE型にとってよくないようなのだが、
// これはたぶん許容範囲。
//#else
// パラメーターの説明に "fixed"と書いてあるパラメーターはランダムパラメーター化するときでも変化しない。
// 「前提depth」は、これ以上ならその枝刈りを適用する(かも)の意味。
// 「適用depth」は、これ以下ならその枝刈りを適用する(かも)の意味。
// 現在の値から、min~maxの範囲で、+step,-step,+0を試す。
// interval = 2だと、-2*step,-step,+0,+step,2*stepの5つを試す。
// Reductionsテーブルの初期化用
// 重要度 ★★★★★
// 元の値 = 2037 ,step = 8
// [PARAM] min:1500,max:2500,step:2,interval:2,time_rate:1,fixed
PARAM_DEFINE PARAM_REDUCTIONS_PARAM1 = 2037;
// Reductionの計算式に出てくる定数
// 重要度 ★★★★☆
// 元の値 = 1487 ,step = 128
// [PARAM] min:0,max:2048,step:32,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_REDUCTION_ALPHA = 1487;
// Reductionの計算式に出てくる定数
// 重要度 ★★★★☆
// 元の値 = 808 , step = 128
// [PARAM] min:300,max:1500,step:64,interval:2,time_rate:1,fixed
PARAM_DEFINE PARAM_REDUCTION_BETA = 808;
// Reductionの計算式に出てくる定数
// 重要度 ★★★★☆
// 元の値 = 976 , step = 128
// [PARAM] min:300,max:1500,step:16,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_REDUCTION_GAMMA = 976;
//
// futility pruning
//
// 深さに比例したfutility pruning
// 重要度 ★★★★☆
// 元の値 = 125 , step = 20
// [PARAM] min:100,max:300,step:10,interval:2,time_rate:1,fixed
PARAM_DEFINE PARAM_FUTILITY_MARGIN_ALPHA1 = 125;
// 重要度 ★★★★☆
// 元の値 = 43 , step = 10
// [PARAM] min:10,max:200,step:5,interval:1,time_rate:1,
PARAM_DEFINE PARAM_FUTILITY_MARGIN_ALPHA2 = 43;
// 重要度 ★★★★☆
// 元の値 = 138 , step = 30
// [PARAM] min:100,max:240,step:30,interval:2,time_rate:1,fixed
PARAM_DEFINE PARAM_FUTILITY_MARGIN_BETA = 108;
// 静止探索でのfutility pruning
// 重要度 ★★★★☆
// 1つ前のバージョンの値 = 118。
// 元の値 = 200 , step = 10
// [PARAM] min:50,max:300,step:30,interval:1,time_rate:1,
PARAM_DEFINE PARAM_FUTILITY_MARGIN_QUIET = 170;
// futility pruningの適用depth。
// 重要度 ★★★☆☆
// この制限自体が要らない可能性がある。→ そうでもなかった。→こんなdepthいじらんほうがマシ
// 元の値 = 9 , step = 1
// [PARAM] min:5,max:15,step:1,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_FUTILITY_RETURN_DEPTH = 9;
// 親nodeでのfutilityの適用depth。
// 重要度 ★★★☆☆
// この枝刈り、depthの制限自体が要らないような気がする。→ そうでもなかった。→こんなdepthいじらんほうがマシ
// 元の値 = 13
// [PARAM] min:5,max:20,step:1,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_FUTILITY_AT_PARENT_NODE_DEPTH = 13;
// 重要度 ★★★☆☆
// 元の値 = 127 , step = 10
// [PARAM] min:100,max:400,step:10,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_FUTILITY_AT_PARENT_NODE_ALPHA = 127;
// 重要度 ★★★★☆
// 元の値 = 26 , step = 2
// [PARAM] min:15,max:50,step:2,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_FUTILITY_AT_PARENT_NODE_GAMMA1 = 26;
// lmrのときのseeの値。
// 重要度 ★★★★☆
// Stockfishの7,8割ぐらいの値にするのがよさげ。
// 元の値 = 185 ,step = 40
// [PARAM] min:0,max:300,step:10,interval:1,time_rate:1
PARAM_DEFINE PARAM_LMR_SEE_MARGIN1 = 175;
//
// null move dynamic pruning
//
// 重要度 ★★★☆☆
// 元の値 = 152 , step = 10
// [PARAM] min:50,max:400,step:10,interval:1,time_rate:1,
PARAM_DEFINE PARAM_NULL_MOVE_DYNAMIC_GAMMA = 132;
// 重要度 ★★★☆☆
// 元の値 = 24 , step = 2
// [PARAM] min:10,max:60,step:1,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_NULL_MOVE_MARGIN1 = 24;
// 元の値 = 281 , step = 50
// 重要度 ★★★☆☆
// [PARAM] min:0,max:400,step:50,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_NULL_MOVE_MARGIN4 = 281;
// null moveでbeta値を上回ったときに、これ以下ならreturnするdepth。適用depth。
// 重要度 ★★★☆☆
// 元の値 = 14
// 他のNULL_MOVEの値が悪いと、この枝刈りを適用しないほうが強くなるわけで、
// このdepthがどんどん高い値に発散してしまうので注意。
// この値は、低くなるのが正しいチューニングだと思う。
// [PARAM] min:4,max:20,step:1,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_NULL_MOVE_RETURN_DEPTH = 14;
//
// ProbCut
//
// probcutのmargin
// 重要度 ★★★☆☆
// 式 = beta + PARAM_PROBCUT_MARGIN1 - improving * PARAM_PROBCUT_MARGIN2
// improvingの効果怪しいので抑え気味にしておく。
// 元の値 = 168 , step = 20
// [PARAM] min:100,max:300,step:5,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_PROBCUT_MARGIN1 = 168;
// 元の値 = 70 , step = 10
// 重要度 ★★★☆☆
// [PARAM] min:20,max:100,step:5,interval:2,time_rate:1,fixed
PARAM_DEFINE PARAM_PROBCUT_MARGIN2 = 65;
// 前のバージョンのStockfishではこの値は481。
// 重要度 ★★★☆☆
// 元の値 = 416 , step = 10
// [PARAM] min:20,max:500,step:10,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_PROBCUT_MARGIN3 = 416;
//
// singular extension
//
// singular extensionのsingular betaを計算するときのマージン
// 重要度 ★★★★☆
// 元の値 = 64 , step = 8
// [PARAM] min:16,max:1024,step:4,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_SINGULAR_MARGIN1 = 64;
// singular extensionのsingular betaを計算するときの係数
// 重要度 ★★★★☆
// 自己対局だとすごく強くなって見えるかもしれないが、まやかしである。
// 元の値 = 57 , step = 8
// [PARAM] min:0,max:1024,step:8,interval:2,time_rate:1,fixed
PARAM_DEFINE PARAM_SINGULAR_MARGIN2 = 57;
//
// LMR
//
// LMRのパラメーター
// 重要度 ★★★☆☆
// 元の値 = 51 , step = 4
// [PARAM] min:0,max:128,step:4,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_LMR_MARGIN1 = 51;
// 重要度 ★★☆☆☆
// → 重要なパラメーターではあるが、下手にいじらないほうがよさげ。
// 元の値 = 10 , step = 1
// min:0,max:128,step:1,interval:1,time_rate:1,
// [PARAM] min:13,max:14,step:1,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_LMR_MARGIN2 = 13;
// 重要度 ★★★☆☆
// 元の値 = 700 , step = 100
// [PARAM] min:0,max:1024,step:50,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_LMR_MARGIN3 = 700;
//
// pruning by history
//
// historyによる枝刈りをする深さ。適用depth。
// 重要度 ★★★☆☆
// 元の値 = 6 , step = 1
// [PARAM] min:2,max:16,step:1,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_PRUNING_BY_HISTORY_DEPTH = 6;
// update_all_stats()で、静止探索時のquietMoveとみなすbestvalueとbetaの差(PawnValueより少し小さな値)
// StockfishではPawnValueが210ぐらいなので、それを考慮すること。
// 重要度 ★★★☆☆
// 元の値 = 168 , step = 30
// [PARAM] min:10,max:300,step:30,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_UPDATE_ALL_STATS_EVAL_TH = 168;
//
// misc
//
// fail lowを引き起こしたcounter moveにbonus与える時のevalのmargin値。
// 重要度 ★★★☆☆
// 元の値 = 657 , step = 50
// [PARAM] min:10,max:1000,step:25,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_COUNTERMOVE_FAILLOW_MARGIN = 657;
// aspiration searchの増加量。
// 重要度 ★★☆☆☆
// → 調整が難しいパラメーター。下手にいじらないほうがよさげ。
// 古い評価関数では20ぐらいがベストだったが、NNUEでは17がベストのようだ。評価関数の精度向上とともに徐々に小さくなってきている。
// 元の値 = 10 , step = 1
// [PARAM] min:5,max:30,step:1,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_ASPIRATION_SEARCH_DELTA = 10;
// qsearch()でnull moveのときもevaluate()を呼び出す。
// 重要度 ★☆☆☆☆
// この値が0(false)ならば、null moveのときはeval = 前局面にEval::Tempoを加算した値 とする。
// 計測できる差にならない。
// PARAM_EVAL_TEMPOを変動させていると(適正値から離れていると)、
// evaluate()を呼び出したほうが良いことになってしまうのでこれが1のときのほうが良いことになってしまうので注意。
// 元の値 = 0 , step = 1
// [PARAM] min:0,max:1,step:1,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_QSEARCH_FORCE_EVAL = 0;
// qsearchの時に、see<=0の指し手を枝刈りするか。
// 重要度 ★★★★☆
// 元の値 = 0 , step = 1
// [PARAM] min:0,max:1,step:1,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_QSEARCH_PRUNE_LE0_SEE_MOVE = 0;
// MovePicker
// move pickerでsortする閾値 (super sort使用時)
// 重要度 ★★★★★
// 元の値 = 1960 , step = 1
// [PARAM] min:0,max:3000,step:480,interval:1,time_rate:1
PARAM_DEFINE PARAM_MOVEPICKER_SORT_TH1 = 1960;
// move pickerでsortする係数 (super sort使用時)
// 重要度 ★★★★★
// 元の値 = 3130 , step = 1
// [PARAM] min:0,max:6000,step:500,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_MOVEPICKER_SORT_ALPHA1 = 3130;
// move pickerでsortする閾値 (super sort使用しない時)
// 重要度 ★★★★★
// 元の値 = 1960 , step = 1
// [PARAM] min:-1000,max:3000,step:480,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_MOVEPICKER_SORT_TH2 = 480;
// move pickerでsortする係数 (super sort使用しない時)
// 重要度 ★★★★★
// 元の値 = 3130 , step = 1
// [PARAM] min:0,max:6000,step:500,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_MOVEPICKER_SORT_ALPHA2 = 2630;
// move pickerでsuper sortを用いるか
// 重要度 ★★★★☆
// 元の値 = 0 , step = 1
// [PARAM] min:0,max:1,step:1,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_MOVEPICKER_USE_SUPERSORT = 1;
//
// mate..
//
// 静止探索での1手詰め
// 重要度 ★★☆☆☆
// 元の値 = 1
// → 1スレ2秒で対技巧だと有りのほうが強かったので固定しておく。
// NNUEだと、これ無しのほうが良い可能性がある。
// いったん無しでやって最後に有りに変更して有効か見る。
// 2スレ1,2秒程度だと無しと有意差がなかったが、4秒~8秒では、有りのほうが+R30ぐらい強い。
// [PARAM] min:0,max:1,step:1,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_QSEARCH_MATE1 = 1;
// 通常探索での1手詰め
// 重要度 ★★☆☆☆
// → よくわからないが1スレ2秒で対技巧だと無しのほうが強かった。
// 1スレ3秒にすると有りのほうが強かった。やはり有りのほうが良いのでは..
// 元の値 = 1
// [PARAM] min:0,max:1,step:1,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_SEARCH_MATE1 = 1;
// 1手詰めではなくN手詰めを用いる
// 重要度 ★★☆☆☆
// ※ 3手,5手はコストに見合わないようだ。
// 元の値 = 1
// [PARAM] min:1,max:5,step:2,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_WEAK_MATE_PLY = 1;
//
// move picker
//
// MovePickerの quietのvalue計算用の係数
// 注意 : この調整をONにするためには movepick.cpp の
// 以下の変数を使ってあるところの #if を有効化("#if 1"を"#if 0"に変更)
// する必要がある。
// → すべて掃除されてなくなった
// ABテスト用
// 重要度 ★☆☆☆☆
// [PARAM] min:0,max:1,step:1,interval:1,time_rate:1,fixed
PARAM_DEFINE AB_TEST1 = 1;
// ABテスト用
// 重要度 ★☆☆☆☆
// [PARAM] min:0,max:1,step:1,interval:1,time_rate:1,fixed
PARAM_DEFINE AB_TEST2 = 1;
//#endif // defined(GENSFEN2019)
#endif
.
total : 10513 - 1386 - 11875(46.96% R-21.16)
total : 10513 - 1386 - 11875(46.96% R-21.16)
PARAM_REDUCTION_ALPHA:
1455 : 3539 - 490 - 3979(47.07% R-20.36)
1487 : 3483 - 427 - 3916(47.07% R-20.36)
1519 : 3491 - 469 - 3980(46.73% R-22.77)
PARAM_REDUCTION_BETA:
680 : 2033 - 278 - 2327(46.63% R-23.46)
744 : 2125 - 281 - 2367(47.31% R-18.74)
808 : 2169 - 252 - 2458(46.88% R-21.73)
872 : 2065 - 284 - 2332(46.96% R-21.12)
936 : 2121 - 291 - 2391(47.01% R-20.82)
PARAM_REDUCTION_GAMMA:
944 : 3474 - 473 - 3949(46.8% R-22.26)
960 : 3515 - 445 - 3998(46.79% R-22.37)
976 : 3524 - 468 - 3928(47.29% R-18.85)
PARAM_FUTILITY_MARGIN_ALPHA2:
33 : 2137 - 296 - 2302(48.14% R-12.92)
38 : 2122 - 293 - 2434(46.58% R-23.83)
43 : 2107 - 250 - 2426(46.48% R-24.49)
48 : 2131 - 282 - 2285(48.26% R-12.12)
53 : 2016 - 265 - 2428(45.36% R-32.3)
PARAM_FUTILITY_MARGIN_BETA:
100 : 2062 - 285 - 2399(46.22% R-26.3)
108 : 2145 - 281 - 2265(48.64% R-9.46)
138 : 2089 - 275 - 2428(46.25% R-26.12)
168 : 2108 - 280 - 2345(47.34% R-18.51)
198 : 2109 - 265 - 2438(46.38% R-25.18)
PARAM_FUTILITY_MARGIN_QUIET:
118 : 3579 - 485 - 4010(47.16% R-19.75)
148 : 3443 - 434 - 3936(46.66% R-23.25)
178 : 3491 - 467 - 3929(47.05% R-20.53)
PARAM_LMR_SEE_MARGIN1:
155 : 3450 - 475 - 3895(46.97% R-21.08)
165 : 3525 - 438 - 4058(46.49% R-24.46)
175 : 3538 - 473 - 3922(47.43% R-17.9)
PARAM_NULL_MOVE_DYNAMIC_GAMMA:
132 : 3582 - 480 - 3938(47.63% R-16.46)
142 : 3489 - 430 - 3976(46.74% R-22.7)
152 : 3442 - 476 - 3961(46.49% R-24.4)
PARAM_SINGULAR_MARGIN1:
64 : 5275 - 683 - 5890(47.25% R-19.16)
68 : 5238 - 703 - 5985(46.67% R-23.16)
PARAM_LMR_MARGIN3:
650 : 3478 - 440 - 3912(47.06% R-20.43)
700 : 3519 - 480 - 4034(46.59% R-23.73)
750 : 3516 - 466 - 3929(47.23% R-19.29)
PARAM_UPDATE_ALL_STATS_EVAL_TH:
138 : 3456 - 426 - 3950(46.66% R-23.21)
168 : 3552 - 477 - 3874(47.83% R-15.07)
198 : 3505 - 483 - 4051(46.39% R-25.15)
PARAM_COUNTERMOVE_FAILLOW_MARGIN:
632 : 3505 - 445 - 3916(47.23% R-19.26)
657 : 3515 - 488 - 3911(47.33% R-18.54)
682 : 3493 - 453 - 4048(46.32% R-25.62)
PARAM_MOVEPICKER_SORT_TH1:
1480 : 3521 - 464 - 3979(46.95% R-21.24)
1960 : 3550 - 473 - 3874(47.82% R-15.17)
2440 : 3442 - 449 - 4022(46.11% R-27.05)
- PARAM_MOVEPICKER_SORT_THを1と2に分ける。
- PARAM_MOVEPICKER_SORT_ALPHAを1と2に分ける。
#ifndef YANEURAOU_PARAM_H_INCLUDED
#define YANEURAOU_PARAM_H_INCLUDED
// yaneuraou-param.h : 元ファイル
// param_conv.pyというPythonのスクリプトにより、以下のファイルは自動生成されます。
// 1) yaneuraou - param - extern.h
// 2) yaneuraou - param - array.h
// 3) yaneuraou - param - string.h
// 1),2),3)のファイルは手で編集しないでください。
//#if defined(GENSFEN2019)
// 教師局面生成用のパラメーター
// 低depthで強くする ≒ 低depth時の枝刈りを甘くする。
//#include "yaneuraou-param_gen.h"
// → 教師生成時と学習時の探索部の性質が違うのはNNUE型にとってよくないようなのだが、
// これはたぶん許容範囲。
//#else
// パラメーターの説明に "fixed"と書いてあるパラメーターはランダムパラメーター化するときでも変化しない。
// 「前提depth」は、これ以上ならその枝刈りを適用する(かも)の意味。
// 「適用depth」は、これ以下ならその枝刈りを適用する(かも)の意味。
// 現在の値から、min~maxの範囲で、+step,-step,+0を試す。
// interval = 2だと、-2*step,-step,+0,+step,2*stepの5つを試す。
// Reductionsテーブルの初期化用
// 重要度 ★★★★★
// 元の値 = 2037 ,step = 8
// [PARAM] min:1500,max:2500,step:2,interval:2,time_rate:1,fixed
PARAM_DEFINE PARAM_REDUCTIONS_PARAM1 = 2037;
// Reductionの計算式に出てくる定数
// 重要度 ★★★★☆
// 元の値 = 1487 ,step = 128
// [PARAM] min:0,max:2048,step:32,interval:1,time_rate:1,
PARAM_DEFINE PARAM_REDUCTION_ALPHA = 1487;
// Reductionの計算式に出てくる定数
// 重要度 ★★★★☆
// 元の値 = 808 , step = 128
// [PARAM] min:300,max:1500,step:64,interval:2,time_rate:1,
PARAM_DEFINE PARAM_REDUCTION_BETA = 808;
// Reductionの計算式に出てくる定数
// 重要度 ★★★★☆
// 元の値 = 976 , step = 128
// [PARAM] min:300,max:1500,step:16,interval:1,time_rate:1,
PARAM_DEFINE PARAM_REDUCTION_GAMMA = 960;
//
// futility pruning
//
// 深さに比例したfutility pruning
// 重要度 ★★★★☆
// 元の値 = 125 , step = 20
// [PARAM] min:100,max:300,step:10,interval:2,time_rate:1,fixed
PARAM_DEFINE PARAM_FUTILITY_MARGIN_ALPHA1 = 125;
// 重要度 ★★★★☆
// 元の値 = 43 , step = 10
// [PARAM] min:10,max:200,step:5,interval:2,time_rate:1,
PARAM_DEFINE PARAM_FUTILITY_MARGIN_ALPHA2 = 43;
// 重要度 ★★★★☆
// 元の値 = 138 , step = 30
// [PARAM] min:100,max:240,step:30,interval:2,time_rate:1,
PARAM_DEFINE PARAM_FUTILITY_MARGIN_BETA = 138;
// 静止探索でのfutility pruning
// 重要度 ★★★★☆
// 1つ前のバージョンの値 = 118。どうも118付近がよさげ…。
// 元の値 = 200 , step = 10
// [PARAM] min:50,max:300,step:30,interval:1,time_rate:1,
PARAM_DEFINE PARAM_FUTILITY_MARGIN_QUIET = 148;
// futility pruningの適用depth。
// 重要度 ★★★☆☆
// この制限自体が要らない可能性がある。→ そうでもなかった。→こんなdepthいじらんほうがマシ
// 元の値 = 9 , step = 1
// [PARAM] min:5,max:15,step:1,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_FUTILITY_RETURN_DEPTH = 9;
// 親nodeでのfutilityの適用depth。
// 重要度 ★★★☆☆
// この枝刈り、depthの制限自体が要らないような気がする。→ そうでもなかった。→こんなdepthいじらんほうがマシ
// 元の値 = 13
// [PARAM] min:5,max:20,step:1,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_FUTILITY_AT_PARENT_NODE_DEPTH = 13;
// 重要度 ★★★☆☆
// 元の値 = 127 , step = 10
// [PARAM] min:100,max:400,step:10,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_FUTILITY_AT_PARENT_NODE_ALPHA = 127;
// 重要度 ★★★★☆
// 元の値 = 26 , step = 2
// [PARAM] min:15,max:50,step:2,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_FUTILITY_AT_PARENT_NODE_GAMMA1 = 26;
// lmrのときのseeの値。
// 重要度 ★★★★☆
// Stockfishの7,8割ぐらいの値にするのがよさげ。
// 元の値 = 185 ,step = 40
// [PARAM] min:0,max:300,step:10,interval:1,time_rate:1,
PARAM_DEFINE PARAM_LMR_SEE_MARGIN1 = 165;
//
// null move dynamic pruning
//
// 重要度 ★★★☆☆
// 元の値 = 152 , step = 10
// [PARAM] min:50,max:400,step:10,interval:1,time_rate:1,
PARAM_DEFINE PARAM_NULL_MOVE_DYNAMIC_GAMMA = 142;
// 重要度 ★★★☆☆
// 元の値 = 24 , step = 2
// [PARAM] min:10,max:60,step:1,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_NULL_MOVE_MARGIN1 = 24;
// 元の値 = 281 , step = 50
// 重要度 ★★★☆☆
// [PARAM] min:0,max:400,step:50,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_NULL_MOVE_MARGIN4 = 281;
// null moveでbeta値を上回ったときに、これ以下ならreturnするdepth。適用depth。
// 重要度 ★★★☆☆
// 元の値 = 14
// 他のNULL_MOVEの値が悪いと、この枝刈りを適用しないほうが強くなるわけで、
// このdepthがどんどん高い値に発散してしまうので注意。
// この値は、低くなるのが正しいチューニングだと思う。
// [PARAM] min:4,max:20,step:1,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_NULL_MOVE_RETURN_DEPTH = 14;
//
// ProbCut
//
// probcutのmargin
// 重要度 ★★★☆☆
// 式 = beta + PARAM_PROBCUT_MARGIN1 - improving * PARAM_PROBCUT_MARGIN2
// improvingの効果怪しいので抑え気味にしておく。
// 元の値 = 168 , step = 20
// [PARAM] min:100,max:300,step:5,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_PROBCUT_MARGIN1 = 168;
// 元の値 = 70 , step = 10
// 重要度 ★★★☆☆
// [PARAM] min:20,max:100,step:5,interval:2,time_rate:1,fixed
PARAM_DEFINE PARAM_PROBCUT_MARGIN2 = 65;
// 前のバージョンのStockfishではこの値は481。
// 重要度 ★★★☆☆
// 元の値 = 416 , step = 10
// [PARAM] min:20,max:500,step:10,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_PROBCUT_MARGIN3 = 416;
//
// singular extension
//
// singular extensionのsingular betaを計算するときのマージン
// 重要度 ★★★★☆
// 元の値 = 64 , step = 8
// [PARAM] min:64,max:1024,step:4,interval:1,time_rate:1,
PARAM_DEFINE PARAM_SINGULAR_MARGIN1 = 64;
// singular extensionのsingular betaを計算するときの係数
// 重要度 ★★★★☆
// 自己対局だとすごく強くなって見えるかもしれないが、まやかしである。
// 元の値 = 57 , step = 8
// [PARAM] min:0,max:1024,step:8,interval:2,time_rate:1,fixed
PARAM_DEFINE PARAM_SINGULAR_MARGIN2 = 57;
//
// LMR
//
// LMRのパラメーター
// 重要度 ★★★☆☆
// 元の値 = 51 , step = 4
// [PARAM] min:0,max:128,step:4,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_LMR_MARGIN1 = 51;
// 重要度 ★★☆☆☆
// → 重要なパラメーターではあるが、下手にいじらないほうがよさげ。
// 元の値 = 10 , step = 1
// min:0,max:128,step:1,interval:1,time_rate:1,
// [PARAM] min:13,max:14,step:1,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_LMR_MARGIN2 = 13;
// 重要度 ★★★☆☆
// 元の値 = 700 , step = 100
// [PARAM] min:0,max:1024,step:50,interval:1,time_rate:1,
PARAM_DEFINE PARAM_LMR_MARGIN3 = 700;
//
// pruning by history
//
// historyによる枝刈りをする深さ。適用depth。
// 重要度 ★★★☆☆
// 元の値 = 6 , step = 1
// [PARAM] min:2,max:16,step:1,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_PRUNING_BY_HISTORY_DEPTH = 6;
// update_all_stats()で、静止探索時のquietMoveとみなすbestvalueとbetaの差(PawnValueより少し小さな値)
// StockfishではPawnValueが210ぐらいなので、それを考慮すること。
// 重要度 ★★★☆☆
// 元の値 = 168 , step = 30
// [PARAM] min:10,max:300,step:30,interval:1,time_rate:1,
PARAM_DEFINE PARAM_UPDATE_ALL_STATS_EVAL_TH = 168;
//
// misc
//
// fail lowを引き起こしたcounter moveにbonus与える時のevalのmargin値。
// 重要度 ★★★☆☆
// 元の値 = 657 , step = 50
// [PARAM] min:10,max:1000,step:25,interval:1,time_rate:1,
PARAM_DEFINE PARAM_COUNTERMOVE_FAILLOW_MARGIN = 657;
// aspiration searchの増加量。
// 重要度 ★★☆☆☆
// → 調整が難しいパラメーター。下手にいじらないほうがよさげ。
// 古い評価関数では20ぐらいがベストだったが、NNUEでは17がベストのようだ。評価関数の精度向上とともに徐々に小さくなってきている。
// 元の値 = 10 , step = 1
// [PARAM] min:5,max:30,step:1,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_ASPIRATION_SEARCH_DELTA = 10;
// qsearch()でnull moveのときもevaluate()を呼び出す。
// 重要度 ★☆☆☆☆
// この値が0(false)ならば、null moveのときはeval = 前局面にEval::Tempoを加算した値 とする。
// 計測できる差にならない。
// PARAM_EVAL_TEMPOを変動させていると(適正値から離れていると)、
// evaluate()を呼び出したほうが良いことになってしまうのでこれが1のときのほうが良いことになってしまうので注意。
// 元の値 = 0 , step = 1
// [PARAM] min:0,max:1,step:1,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_QSEARCH_FORCE_EVAL = 0;
// qsearchの時に、see<=0の指し手を枝刈りするか。
// 重要度 ★★★★☆
// 元の値 = 0 , step = 1
// [PARAM] min:0,max:1,step:1,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_QSEARCH_PRUNE_LE0_SEE_MOVE = 0;
// MovePicker
// move pickerでsortする閾値 (super sort使用時)
// 重要度 ★★★★★
// 元の値 = 1960 , step = 1
// [PARAM] min:0,max:3000,step:480,interval:1,time_rate:1
PARAM_DEFINE PARAM_MOVEPICKER_SORT_TH1 = 1960;
// move pickerでsortする係数 (super sort使用時)
// 重要度 ★★★★★
// 元の値 = 3130 , step = 1
// [PARAM] min:0,max:6000,step:500,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_MOVEPICKER_SORT_ALPHA1 = 3130;
// move pickerでsortする閾値 (super sort使用しない時)
// 重要度 ★★★★★
// 元の値 = 1960 , step = 1
// [PARAM] min:-1000,max:3000,step:480,interval:1,time_rate:1
PARAM_DEFINE PARAM_MOVEPICKER_SORT_TH2 = 480;
// move pickerでsortする係数 (super sort使用しない時)
// 重要度 ★★★★★
// 元の値 = 3130 , step = 1
// [PARAM] min:0,max:6000,step:500,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_MOVEPICKER_SORT_ALPHA2 = 2630;
// move pickerでsuper sortを用いるか
// 重要度 ★★★★☆
// 元の値 = 0 , step = 1
// [PARAM] min:0,max:1,step:1,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_MOVEPICKER_USE_SUPERSORT = 1;
//
// mate..
//
// 静止探索での1手詰め
// 重要度 ★★☆☆☆
// 元の値 = 1
// → 1スレ2秒で対技巧だと有りのほうが強かったので固定しておく。
// NNUEだと、これ無しのほうが良い可能性がある。
// いったん無しでやって最後に有りに変更して有効か見る。
// 2スレ1,2秒程度だと無しと有意差がなかったが、4秒~8秒では、有りのほうが+R30ぐらい強い。
// [PARAM] min:0,max:1,step:1,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_QSEARCH_MATE1 = 1;
// 通常探索での1手詰め
// 重要度 ★★☆☆☆
// → よくわからないが1スレ2秒で対技巧だと無しのほうが強かった。
// 1スレ3秒にすると有りのほうが強かった。やはり有りのほうが良いのでは..
// 元の値 = 1
// [PARAM] min:0,max:1,step:1,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_SEARCH_MATE1 = 1;
// 1手詰めではなくN手詰めを用いる
// 重要度 ★★☆☆☆
// ※ 3手,5手はコストに見合わないようだ。
// 元の値 = 1
// [PARAM] min:1,max:5,step:2,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_WEAK_MATE_PLY = 1;
//
// move picker
//
// MovePickerの quietのvalue計算用の係数
// 注意 : この調整をONにするためには movepick.cpp の
// 以下の変数を使ってあるところの #if を有効化("#if 1"を"#if 0"に変更)
// する必要がある。
// → すべて掃除されてなくなった
// ABテスト用
// 重要度 ★☆☆☆☆
// [PARAM] min:0,max:1,step:1,interval:1,time_rate:1,fixed
PARAM_DEFINE AB_TEST1 = 1;
// ABテスト用
// 重要度 ★☆☆☆☆
// [PARAM] min:0,max:1,step:1,interval:1,time_rate:1,fixed
PARAM_DEFINE AB_TEST2 = 1;
//#endif // defined(GENSFEN2019)
#endif
total : 9793 - 1318 - 11576(45.83% R-29.06)
total : 9793 - 1318 - 11576(45.83% R-29.06)
PARAM_REDUCTIONS_PARAM1:
2033 : 1946 - 246 - 2252(46.36% R-25.37)
2035 : 1932 - 275 - 2325(45.38% R-32.17)
2037 : 2054 - 270 - 2345(46.69% R-23.02)
2039 : 1922 - 271 - 2287(45.66% R-30.21)
2041 : 1939 - 256 - 2367(45.03% R-34.65)
PARAM_REDUCTION_ALPHA:
1423 : 1961 - 263 - 2270(46.35% R-25.42)
1455 : 1983 - 260 - 2320(46.08% R-27.27)
1487 : 1883 - 243 - 2299(45.03% R-34.68)
1519 : 2005 - 273 - 2352(46.02% R-27.73)
1551 : 1961 - 279 - 2335(45.65% R-30.32)
PARAM_REDUCTION_BETA:
680 : 1887 - 244 - 2306(45.0% R-34.83)
744 : 1911 - 291 - 2318(45.19% R-33.54)
808 : 1961 - 258 - 2207(47.05% R-20.53)
872 : 2077 - 280 - 2322(47.22% R-19.37)
936 : 1957 - 245 - 2423(44.68% R-37.11)
PARAM_REDUCTION_GAMMA:
944 : 1989 - 241 - 2352(45.82% R-29.12)
960 : 1919 - 252 - 2206(46.52% R-24.21)
976 : 1912 - 278 - 2364(44.71% R-36.86)
992 : 1977 - 269 - 2334(45.86% R-28.84)
1008 : 1996 - 278 - 2320(46.25% R-26.13)
PARAM_FUTILITY_MARGIN_ALPHA2:
33 : 1957 - 252 - 2352(45.42% R-31.94)
38 : 1980 - 283 - 2313(46.12% R-27.0)
43 : 1982 - 254 - 2351(45.74% R-29.66)
48 : 1883 - 261 - 2223(45.86% R-28.84)
53 : 1991 - 268 - 2337(46.0% R-27.83)
PARAM_FUTILITY_MARGIN_BETA:
100 : 1909 - 235 - 2386(44.45% R-38.75)
108 : 1988 - 252 - 2269(46.7% R-22.97)
138 : 1916 - 254 - 2289(45.56% R-30.9)
168 : 2016 - 292 - 2334(46.34% R-25.44)
198 : 1964 - 285 - 2298(46.08% R-27.28)
PARAM_FUTILITY_MARGIN_QUIET:
118 : 1964 - 216 - 2248(46.63% R-23.46)
128 : 1968 - 280 - 2352(45.56% R-30.96)
138 : 1963 - 266 - 2410(44.89% R-35.64)
148 : 1947 - 275 - 2215(46.78% R-22.4)
158 : 1951 - 281 - 2351(45.35% R-32.4)
PARAM_FUTILITY_AT_PARENT_NODE_GAMMA1:
26 : 3250 - 462 - 3794(46.14% R-26.89)
28 : 3252 - 412 - 3920(45.34% R-32.45)
30 : 3291 - 444 - 3862(46.01% R-27.79)
PARAM_LMR_SEE_MARGIN1:
155 : 3233 - 446 - 3853(45.63% R-30.48)
165 : 3250 - 429 - 3896(45.48% R-31.49)
175 : 3310 - 443 - 3827(46.38% R-25.21)
PARAM_NULL_MOVE_DYNAMIC_GAMMA:
122 : 3188 - 458 - 3794(45.66% R-30.23)
132 : 3266 - 412 - 3917(45.47% R-31.57)
142 : 3339 - 448 - 3865(46.35% R-25.41)
PARAM_NULL_MOVE_MARGIN4:
281 : 3344 - 393 - 3867(46.37% R-25.24)
331 : 3123 - 435 - 3867(44.68% R-37.12)
381 : 3326 - 490 - 3842(46.4% R-25.05)
PARAM_PROBCUT_MARGIN1:
168 : 3245 - 451 - 3739(46.46% R-24.62)
173 : 3244 - 410 - 3878(45.55% R-31.01)
178 : 3304 - 457 - 3959(45.49% R-31.42)
PARAM_PROBCUT_MARGIN2:
50 : 1925 - 256 - 2354(44.99% R-34.95)
55 : 1979 - 279 - 2331(45.92% R-28.44)
60 : 1909 - 242 - 2229(46.13% R-26.92)
65 : 2057 - 261 - 2310(47.1% R-20.15)
70 : 1923 - 280 - 2352(44.98% R-34.98)
PARAM_PROBCUT_MARGIN3:
416 : 3383 - 427 - 3928(46.27% R-25.95)
426 : 3202 - 439 - 3845(45.44% R-31.79)
436 : 3208 - 452 - 3803(45.76% R-29.56)
PARAM_SINGULAR_MARGIN1:
64 : 3184 - 447 - 3857(45.22% R-33.31)
68 : 3328 - 429 - 3840(46.43% R-24.86)
72 : 3281 - 442 - 3879(45.82% R-29.09)
PARAM_LMR_MARGIN2:
13 : 4872 - 643 - 5752(45.86% R-28.84)
14 : 4921 - 675 - 5824(45.8% R-29.27)
PARAM_LMR_MARGIN3:
650 : 3274 - 458 - 3832(46.07% R-27.34)
700 : 3168 - 434 - 3851(45.13% R-33.92)
750 : 3351 - 426 - 3893(46.26% R-26.04)
PARAM_UPDATE_ALL_STATS_EVAL_TH:
138 : 3240 - 423 - 3744(46.39% R-25.12)
168 : 3283 - 461 - 3892(45.76% R-29.56)
198 : 3270 - 434 - 3940(45.35% R-32.38)
PARAM_COUNTERMOVE_FAILLOW_MARGIN:
657 : 2002 - 229 - 2264(46.93% R-21.36)
682 : 2000 - 275 - 2210(47.51% R-17.34)
707 : 1881 - 273 - 2378(44.17% R-40.73)
732 : 1957 - 256 - 2337(45.58% R-30.83)
757 : 1953 - 285 - 2387(45.0% R-34.86)
PARAM_MOVEPICKER_SORT_TH:
960 : 3249 - 418 - 3791(46.15% R-26.8)
1960 : 3298 - 468 - 3850(46.14% R-26.88)
2960 : 3246 - 432 - 3935(45.2% R-33.44)
PARAM_MOVEPICKER_SORT_ALPHA:
2630 : 3267 - 455 - 3844(45.94% R-28.25)
3130 : 3264 - 450 - 3887(45.64% R-30.35)
3630 : 3262 - 413 - 3845(45.9% R-28.56)
PARAM_MOVEPICKER_USE_SUPERSORT:
0 : 4908 - 658 - 5900(45.41% R-31.98)
1 : 4885 - 660 - 5676(46.26% R-26.07)
super sortなし
total : 4908 - 658 - 5900(45.41% R-31.98)
total : 4908 - 658 - 5900(45.41% R-31.98)
PARAM_REDUCTIONS_PARAM1:
2033 : 973 - 122 - 1148(45.87% R-28.73)
2035 : 968 - 143 - 1203(44.59% R-37.76)
2037 : 1011 - 129 - 1196(45.81% R-29.19)
2039 : 976 - 136 - 1141(46.1% R-27.13)
2041 : 980 - 128 - 1212(44.71% R-36.91)
PARAM_REDUCTION_ALPHA:
1423 : 964 - 128 - 1146(45.69% R-30.04)
1455 : 979 - 132 - 1172(45.51% R-31.26)
1487 : 935 - 130 - 1210(43.59% R-44.79)
1519 : 1016 - 131 - 1157(46.76% R-22.58)
1551 : 1014 - 137 - 1215(45.49% R-31.42)
PARAM_REDUCTION_BETA:
680 : 951 - 112 - 1168(44.88% R-35.7)
744 : 957 - 147 - 1228(43.8% R-43.31)
808 : 965 - 131 - 1118(46.33% R-25.57)
872 : 1034 - 140 - 1156(47.21% R-19.37)
936 : 1001 - 128 - 1230(44.87% R-35.79)
PARAM_REDUCTION_GAMMA:
944 : 995 - 119 - 1182(45.71% R-29.92)
960 : 958 - 123 - 1128(45.93% R-28.38)
976 : 930 - 149 - 1167(44.35% R-39.44)
992 : 989 - 139 - 1222(44.73% R-36.75)
1008 : 1036 - 128 - 1201(46.31% R-25.67)
PARAM_FUTILITY_MARGIN_ALPHA2:
33 : 974 - 122 - 1175(45.32% R-32.59)
38 : 1007 - 158 - 1202(45.59% R-30.75)
43 : 990 - 116 - 1211(44.98% R-35.0)
48 : 941 - 125 - 1133(45.37% R-32.26)
53 : 996 - 137 - 1179(45.79% R-29.3)
PARAM_FUTILITY_MARGIN_BETA:
100 : 936 - 115 - 1233(43.15% R-47.87)
108 : 996 - 124 - 1159(46.22% R-26.33)
138 : 953 - 136 - 1179(44.7% R-36.97)
168 : 1009 - 149 - 1196(45.76% R-29.54)
198 : 1014 - 134 - 1133(47.23% R-19.28)
PARAM_FUTILITY_MARGIN_QUIET:
118 : 998 - 103 - 1113(47.28% R-18.95)
128 : 975 - 142 - 1187(45.1% R-34.18)
138 : 985 - 140 - 1276(43.56% R-44.97)
148 : 973 - 135 - 1117(46.56% R-23.98)
158 : 977 - 138 - 1207(44.73% R-36.73)
PARAM_FUTILITY_AT_PARENT_NODE_GAMMA1:
26 : 1614 - 234 - 1990(44.78% R-36.38)
28 : 1641 - 199 - 1943(45.79% R-29.35)
30 : 1653 - 225 - 1967(45.66% R-30.21)
PARAM_LMR_SEE_MARGIN1:
155 : 1591 - 221 - 1953(44.89% R-35.61)
165 : 1656 - 214 - 2021(45.04% R-34.6)
175 : 1661 - 223 - 1926(46.31% R-25.71)
PARAM_NULL_MOVE_DYNAMIC_GAMMA:
122 : 1616 - 227 - 1962(45.16% R-33.7)
132 : 1617 - 204 - 1982(44.93% R-35.36)
142 : 1675 - 227 - 1956(46.13% R-26.94)
PARAM_NULL_MOVE_MARGIN4:
281 : 1713 - 195 - 2013(45.97% R-28.03)
331 : 1569 - 206 - 1982(44.18% R-40.59)
381 : 1626 - 257 - 1905(46.05% R-27.51)
PARAM_PROBCUT_MARGIN1:
168 : 1609 - 239 - 1914(45.67% R-30.15)
173 : 1639 - 193 - 1978(45.31% R-32.66)
178 : 1660 - 226 - 2008(45.26% R-33.06)
PARAM_PROBCUT_MARGIN2:
50 : 967 - 136 - 1158(45.51% R-31.31)
55 : 1003 - 139 - 1198(45.57% R-30.86)
60 : 973 - 132 - 1154(45.75% R-29.64)
65 : 1039 - 120 - 1224(45.91% R-28.47)
70 : 926 - 131 - 1166(44.26% R-40.04)
PARAM_PROBCUT_MARGIN3:
416 : 1725 - 195 - 2014(46.14% R-26.91)
426 : 1599 - 251 - 1959(44.94% R-35.27)
436 : 1584 - 212 - 1927(45.12% R-34.05)
PARAM_SINGULAR_MARGIN1:
64 : 1594 - 232 - 1978(44.62% R-37.5)
68 : 1687 - 224 - 1981(45.99% R-27.91)
72 : 1627 - 202 - 1941(45.6% R-30.66)
PARAM_LMR_MARGIN2:
13 : 2455 - 321 - 2945(45.46% R-31.61)
14 : 2453 - 337 - 2955(45.36% R-32.34)
PARAM_LMR_MARGIN3:
650 : 1650 - 238 - 1943(45.92% R-28.4)
700 : 1578 - 221 - 1955(44.66% R-37.22)
750 : 1680 - 199 - 2002(45.63% R-30.46)
PARAM_UPDATE_ALL_STATS_EVAL_TH:
138 : 1595 - 209 - 1914(45.45% R-31.67)
168 : 1681 - 229 - 1994(45.74% R-29.66)
198 : 1632 - 220 - 1992(45.03% R-34.63)
PARAM_COUNTERMOVE_FAILLOW_MARGIN:
657 : 976 - 115 - 1122(46.52% R-24.22)
682 : 985 - 127 - 1138(46.4% R-25.08)
707 : 949 - 143 - 1193(44.3% R-39.75)
732 : 1009 - 125 - 1228(45.11% R-34.12)
757 : 989 - 148 - 1219(44.79% R-36.32)
PARAM_MOVEPICKER_SORT_TH:
960 : 1639 - 205 - 1923(46.01% R-27.76)
1960 : 1661 - 243 - 1978(45.64% R-30.34)
2960 : 1608 - 210 - 1999(44.58% R-37.81)
PARAM_MOVEPICKER_SORT_ALPHA:
2630 : 1671 - 234 - 1966(45.94% R-28.24)
3130 : 1614 - 221 - 1982(44.88% R-35.68)
3630 : 1623 - 203 - 1952(45.4% R-32.06)
PARAM_MOVEPICKER_USE_SUPERSORT:
0 : 4908 - 658 - 5900(45.41% R-31.98)
super sortあり
total : 4885 - 660 - 5676(46.26% R-26.07)
total : 4885 - 660 - 5676(46.26% R-26.07)
PARAM_REDUCTIONS_PARAM1:
2033 : 973 - 124 - 1104(46.85% R-21.94)
2035 : 964 - 132 - 1122(46.21% R-26.37)
2037 : 1043 - 141 - 1149(47.58% R-16.81)
2039 : 946 - 135 - 1146(45.22% R-33.32)
2041 : 959 - 128 - 1155(45.36% R-32.31)
PARAM_REDUCTION_ALPHA:
1423 : 997 - 135 - 1124(47.01% R-20.83)
1455 : 1004 - 128 - 1148(46.65% R-23.28)
1487 : 948 - 113 - 1089(46.54% R-24.09)
1519 : 989 - 142 - 1195(45.28% R-32.87)
1551 : 947 - 142 - 1120(45.82% R-29.15)
PARAM_REDUCTION_BETA:
680 : 936 - 132 - 1138(45.13% R-33.95)
744 : 954 - 144 - 1090(46.67% R-23.15)
808 : 996 - 127 - 1089(47.77% R-15.51)
872 : 1043 - 140 - 1166(47.22% R-19.37)
936 : 956 - 117 - 1193(44.49% R-38.47)
PARAM_REDUCTION_GAMMA:
944 : 994 - 122 - 1170(45.93% R-28.32)
960 : 961 - 129 - 1078(47.13% R-19.96)
976 : 982 - 129 - 1197(45.07% R-34.39)
992 : 988 - 130 - 1112(47.05% R-20.54)
1008 : 960 - 150 - 1119(46.18% R-26.62)
PARAM_FUTILITY_MARGIN_ALPHA2:
33 : 983 - 130 - 1177(45.51% R-31.29)
38 : 973 - 125 - 1111(46.69% R-23.04)
43 : 992 - 138 - 1140(46.53% R-24.16)
48 : 942 - 136 - 1090(46.36% R-25.35)
53 : 995 - 131 - 1158(46.21% R-26.35)
PARAM_FUTILITY_MARGIN_BETA:
100 : 973 - 120 - 1153(45.77% R-29.49)
108 : 992 - 128 - 1110(47.19% R-19.52)
138 : 963 - 118 - 1110(46.45% R-24.68)
168 : 1007 - 143 - 1138(46.95% R-21.25)
198 : 950 - 151 - 1165(44.92% R-35.44)
PARAM_FUTILITY_MARGIN_QUIET:
118 : 966 - 113 - 1135(45.98% R-28.01)
128 : 993 - 138 - 1165(46.01% R-27.75)
138 : 978 - 126 - 1134(46.31% R-25.71)
148 : 974 - 140 - 1098(47.01% R-20.82)
158 : 974 - 143 - 1144(45.99% R-27.95)
PARAM_FUTILITY_AT_PARENT_NODE_GAMMA1:
26 : 1636 - 228 - 1804(47.56% R-16.98)
28 : 1611 - 213 - 1977(44.9% R-35.56)
30 : 1638 - 219 - 1895(46.36% R-25.32)
PARAM_LMR_SEE_MARGIN1:
155 : 1642 - 225 - 1900(46.36% R-25.35)
165 : 1594 - 215 - 1875(45.95% R-28.21)
175 : 1649 - 220 - 1901(46.45% R-24.7)
PARAM_NULL_MOVE_DYNAMIC_GAMMA:
122 : 1572 - 231 - 1832(46.18% R-26.59)
132 : 1649 - 208 - 1935(46.01% R-27.78)
142 : 1664 - 221 - 1909(46.57% R-23.86)
PARAM_NULL_MOVE_MARGIN4:
281 : 1631 - 198 - 1854(46.8% R-22.26)
331 : 1554 - 229 - 1885(45.19% R-33.54)
381 : 1700 - 233 - 1937(46.74% R-22.67)
PARAM_PROBCUT_MARGIN1:
168 : 1636 - 212 - 1825(47.27% R-18.99)
173 : 1605 - 217 - 1900(45.79% R-29.31)
178 : 1644 - 231 - 1951(45.73% R-29.74)
PARAM_PROBCUT_MARGIN2:
50 : 958 - 120 - 1196(44.48% R-38.55)
55 : 976 - 140 - 1133(46.28% R-25.91)
60 : 936 - 110 - 1075(46.54% R-24.05)
65 : 1018 - 141 - 1086(48.38% R-11.23)
70 : 997 - 149 - 1186(45.67% R-30.16)
PARAM_PROBCUT_MARGIN3:
416 : 1658 - 232 - 1914(46.42% R-24.94)
426 : 1603 - 188 - 1886(45.94% R-28.24)
436 : 1624 - 240 - 1876(46.4% R-25.06)
PARAM_SINGULAR_MARGIN1:
64 : 1590 - 215 - 1879(45.83% R-29.01)
68 : 1641 - 205 - 1859(46.89% R-21.67)
72 : 1654 - 240 - 1938(46.05% R-27.53)
PARAM_LMR_MARGIN2:
13 : 2417 - 322 - 2807(46.27% R-25.99)
14 : 2468 - 338 - 2869(46.24% R-26.15)
PARAM_LMR_MARGIN3:
650 : 1624 - 220 - 1889(46.23% R-26.26)
700 : 1590 - 213 - 1896(45.61% R-30.58)
750 : 1671 - 227 - 1891(46.91% R-21.49)
PARAM_UPDATE_ALL_STATS_EVAL_TH:
138 : 1645 - 214 - 1830(47.34% R-18.51)
168 : 1602 - 232 - 1898(45.77% R-29.45)
198 : 1638 - 214 - 1948(45.68% R-30.11)
PARAM_COUNTERMOVE_FAILLOW_MARGIN:
657 : 1026 - 114 - 1142(47.32% R-18.61)
682 : 1015 - 148 - 1072(48.63% R-9.49)
707 : 932 - 130 - 1185(44.02% R-41.72)
732 : 948 - 131 - 1109(46.09% R-27.25)
757 : 964 - 137 - 1168(45.22% R-33.35)
PARAM_MOVEPICKER_SORT_TH:
960 : 1610 - 213 - 1868(46.29% R-25.82)
1960 : 1637 - 225 - 1872(46.65% R-23.3)
2960 : 1638 - 222 - 1936(45.83% R-29.04)
PARAM_MOVEPICKER_SORT_ALPHA:
2630 : 1596 - 221 - 1878(45.94% R-28.27)
3130 : 1650 - 229 - 1905(46.41% R-24.96)
3630 : 1639 - 210 - 1893(46.4% R-25.03)
PARAM_MOVEPICKER_USE_SUPERSORT:
1 : 4885 - 660 - 5676(46.26% R-26.07)
・探索部、改良のアイデアが2,3あるので、それ試す。 → done
1手2スレ4秒,4スレ2秒,8スレ1秒など
total : 12170 - 1602 - 14155(46.23% R-26.25)
total : 12170 - 1602 - 14155(46.23% R-26.25)
PARAM_REDUCTIONS_PARAM1:
2033 : 2483 - 334 - 2848(46.58% R-23.83)
2035 : 2361 - 314 - 2806(45.69% R-30.0)
2037 : 2420 - 312 - 2828(46.11% R-27.07)
2039 : 2397 - 321 - 2795(46.17% R-26.69)
2041 : 2509 - 321 - 2878(46.58% R-23.84)
PARAM_REDUCTION_ALPHA:
1359 : 2342 - 345 - 2937(44.36% R-39.33)
1423 : 2409 - 318 - 2827(46.01% R-27.8)
1487 : 2477 - 325 - 2829(46.68% R-23.08) 範囲縮める
1551 : 2489 - 306 - 2789(47.16% R-19.77)
1615 : 2453 - 308 - 2773(46.94% R-21.3)
PARAM_REDUCTION_BETA:
680 : 2399 - 329 - 2856(45.65% R-30.29)
744 : 2454 - 312 - 2788(46.81% R-22.17)
808 : 2420 - 330 - 2838(46.03% R-27.68)
872 : 2476 - 293 - 2863(46.38% R-25.23)
936 : 2421 - 338 - 2810(46.28% R-25.88)
PARAM_REDUCTION_GAMMA:
912 : 2399 - 332 - 2833(45.85% R-28.89)
944 : 2466 - 302 - 2795(46.87% R-21.76)
976 : 2480 - 344 - 2804(46.93% R-21.33) 範囲縮める
1008 : 2416 - 320 - 2813(46.2% R-26.43)
1040 : 2409 - 304 - 2910(45.29% R-32.82)
PARAM_FUTILITY_MARGIN_ALPHA1:
105 : 2435 - 332 - 2840(46.16% R-26.73)
115 : 2332 - 319 - 2989(43.83% R-43.12)
125 : 2430 - 304 - 2755(46.87% R-21.81)
135 : 2506 - 313 - 2809(47.15% R-19.83)
145 : 2467 - 334 - 2762(47.18% R-19.62)
PARAM_FUTILITY_MARGIN_ALPHA2:
33 : 2439 - 312 - 2809(46.47% R-24.54)
38 : 2402 - 294 - 2776(46.39% R-25.14)
43 : 2389 - 319 - 2888(45.27% R-32.95)
48 : 2479 - 365 - 2845(46.56% R-23.92)
53 : 2461 - 312 - 2837(46.45% R-24.7)
PARAM_FUTILITY_MARGIN_BETA:
100 : 2499 - 307 - 2847(46.75% R-22.65)
108 : 2406 - 303 - 2816(46.07% R-27.33)
138 : 2440 - 332 - 2894(45.74% R-29.64)
168 : 2393 - 316 - 2815(45.95% R-28.21)
198 : 2432 - 344 - 2783(46.63% R-23.42)
PARAM_FUTILITY_MARGIN_QUIET:
118 : 2361 - 296 - 2782(45.91% R-28.5)
128 : 2417 - 369 - 2915(45.33% R-32.54)
138 : 2442 - 319 - 2818(46.43% R-24.88)
148 : 2447 - 306 - 2853(46.17% R-26.67)
158 : 2503 - 312 - 2787(47.32% R-18.67)
PARAM_FUTILITY_AT_PARENT_NODE_ALPHA:
127 : 4001 - 493 - 4597(46.53% R-24.12)
137 : 4083 - 526 - 4691(46.54% R-24.11)
147 : 4086 - 583 - 4867(45.64% R-30.39)
PARAM_FUTILITY_AT_PARENT_NODE_GAMMA1:
28 : 4105 - 576 - 4703(46.61% R-23.62)
30 : 4025 - 526 - 4719(46.03% R-27.63)
32 : 4040 - 500 - 4733(46.05% R-27.5)
PARAM_LMR_SEE_MARGIN1:
165 : 2495 - 321 - 2747(47.6% R-16.72)
175 : 2382 - 313 - 2824(45.75% R-29.57)
185 : 2411 - 315 - 2826(46.04% R-27.59)
195 : 2448 - 330 - 2836(46.33% R-25.56)
205 : 2434 - 323 - 2922(45.44% R-31.74)
PARAM_NULL_MOVE_DYNAMIC_GAMMA:
132 : 4178 - 519 - 4678(47.18% R-19.64)
142 : 3999 - 535 - 4677(46.09% R-27.21)
152 : 3993 - 548 - 4800(45.41% R-31.98)
PARAM_NULL_MOVE_MARGIN4:
181 : 2391 - 325 - 2876(45.4% R-32.08)
231 : 2407 - 326 - 2904(45.32% R-32.61)
281 : 2445 - 333 - 2812(46.51% R-24.29)
331 : 2427 - 322 - 2678(47.54% R-17.1)
381 : 2500 - 296 - 2885(46.43% R-24.88)
PARAM_PROBCUT_MARGIN1:
163 : 3959 - 550 - 4657(45.95% R-28.21)
168 : 4043 - 542 - 4855(45.44% R-31.79)
173 : 4168 - 510 - 4643(47.3% R-18.75)
PARAM_PROBCUT_MARGIN2:
50 : 2404 - 337 - 2793(46.26% R-26.05)
55 : 2410 - 326 - 2775(46.48% R-24.5)
60 : 2456 - 320 - 2855(46.24% R-26.15)
65 : 2460 - 309 - 2857(46.27% R-25.99)
70 : 2440 - 310 - 2875(45.91% R-28.5)
PARAM_PROBCUT_MARGIN3:
396 : 2332 - 352 - 2852(44.98% R-34.97)
406 : 2444 - 290 - 2766(46.91% R-21.5)
416 : 2499 - 310 - 2955(45.82% R-29.12)
426 : 2416 - 338 - 2711(47.12% R-20.01)
436 : 2479 - 312 - 2871(46.34% R-25.5)
PARAM_SINGULAR_MARGIN1:
64 : 2465 - 312 - 2922(45.76% R-29.55)
66 : 2393 - 297 - 2814(45.96% R-28.15)
68 : 2426 - 348 - 2811(46.32% R-25.59)
70 : 2397 - 353 - 2687(47.15% R-19.84)
72 : 2489 - 292 - 2921(46.01% R-27.8)
PARAM_LMR_MARGIN1:
47 : 4030 - 514 - 4710(46.11% R-27.09)
51 : 4093 - 556 - 4728(46.4% R-25.05)
55 : 4047 - 532 - 4717(46.18% R-26.61)
PARAM_LMR_MARGIN2:
12 : 5946 - 784 - 7136(45.45% R-31.69)
13 : 6224 - 818 - 7019(47.0% R-20.88) , 13,14で試す
PARAM_LMR_MARGIN3:
650 : 2412 - 323 - 2809(46.2% R-26.47)
675 : 2399 - 300 - 2799(46.15% R-26.79)
700 : 2486 - 334 - 2853(46.56% R-23.92)
725 : 2401 - 317 - 2915(45.17% R-33.7)
750 : 2472 - 328 - 2779(47.08% R-20.34)
PARAM_UPDATE_ALL_STATS_EVAL_TH:
138 : 2425 - 300 - 2827(46.17% R-26.65)
153 : 2364 - 327 - 2797(45.81% R-29.22)
168 : 2494 - 347 - 2854(46.63% R-23.42)
183 : 2422 - 309 - 2825(46.16% R-26.74)
198 : 2465 - 319 - 2852(46.36% R-25.33)
PARAM_COUNTERMOVE_FAILLOW_MARGIN:
657 : 2454 - 347 - 2826(46.48% R-24.52)
682 : 2390 - 321 - 2847(45.64% R-30.4)
707 : 2494 - 323 - 2869(46.5% R-24.33)
732 : 2484 - 293 - 2806(46.96% R-21.17)
757 : 2348 - 318 - 2807(45.55% R-31.02)
PARAM_MOVEPICKER_SORT_TH:
960 : 2396 - 319 - 2874(45.46% R-31.6)
1460 : 2472 - 301 - 2814(46.77% R-22.51)
1960 : 2431 - 312 - 2881(45.76% R-29.5)
2460 : 2449 - 336 - 2840(46.3% R-25.73)
2960 : 2421 - 334 - 2744(46.87% R-21.76)
PARAM_MOVEPICKER_SORT_ALPHA:
2130 : 2532 - 311 - 2864(46.92% R-21.4)
2630 : 2453 - 304 - 2897(45.85% R-28.9)
3130 : 2349 - 336 - 2769(45.9% R-28.58)
3630 : 2407 - 334 - 2820(46.05% R-27.51)
4130 : 2428 - 317 - 2803(46.42% R-24.95)
PARAM_MOVEPICKER_USE_SUPERSORT:
0 : 6079 - 779 - 7085(46.18% R-26.6)
1 : 6090 - 823 - 7068(46.28% R-25.87)
super sortなし
total : 6079 - 779 - 7085(46.18% R-26.6)
total : 6079 - 779 - 7085(46.18% R-26.6)
PARAM_REDUCTIONS_PARAM1:
2033 : 1180 - 151 - 1443(44.99% R-34.95)
2035 : 1191 - 146 - 1408(45.83% R-29.08)
2037 : 1227 - 169 - 1361(47.41% R-18.01)
2039 : 1237 - 145 - 1411(46.71% R-22.86)
2041 : 1244 - 168 - 1462(45.97% R-28.05)
PARAM_REDUCTION_ALPHA:
1359 : 1198 - 159 - 1471(44.89% R-35.66)
1423 : 1182 - 171 - 1425(45.34% R-32.48)
1487 : 1252 - 160 - 1404(47.14% R-19.91)
1551 : 1206 - 150 - 1406(46.17% R-26.66)
1615 : 1241 - 139 - 1379(47.37% R-18.32)
PARAM_REDUCTION_BETA:
680 : 1206 - 156 - 1478(44.93% R-35.33)
744 : 1250 - 154 - 1402(47.13% R-19.94)
808 : 1204 - 167 - 1396(46.31% R-25.7)
872 : 1257 - 137 - 1395(47.4% R-18.1)
936 : 1162 - 165 - 1414(45.11% R-34.1)
PARAM_REDUCTION_GAMMA:
912 : 1201 - 149 - 1427(45.7% R-29.95)
944 : 1203 - 155 - 1385(46.48% R-24.47)
976 : 1228 - 168 - 1418(46.41% R-24.99)
1008 : 1213 - 152 - 1440(45.72% R-29.8)
1040 : 1234 - 155 - 1415(46.58% R-23.78)
PARAM_FUTILITY_MARGIN_ALPHA1:
105 : 1228 - 154 - 1416(46.44% R-24.75)
115 : 1143 - 157 - 1461(43.89% R-42.64)
125 : 1276 - 150 - 1407(47.56% R-16.98)
135 : 1229 - 149 - 1416(46.47% R-24.6)
145 : 1203 - 169 - 1385(46.48% R-24.47)
PARAM_FUTILITY_MARGIN_ALPHA2:
33 : 1240 - 153 - 1399(46.99% R-20.96)
38 : 1162 - 140 - 1358(46.11% R-27.08)
43 : 1152 - 138 - 1458(44.14% R-40.92)
48 : 1277 - 184 - 1429(47.19% R-19.54)
53 : 1248 - 164 - 1441(46.41% R-24.98)
PARAM_FUTILITY_MARGIN_BETA:
100 : 1239 - 152 - 1387(47.18% R-19.6)
108 : 1164 - 145 - 1419(45.06% R-34.41)
138 : 1242 - 157 - 1470(45.8% R-29.28)
168 : 1195 - 151 - 1425(45.61% R-30.58)
198 : 1239 - 174 - 1384(47.24% R-19.23)
PARAM_FUTILITY_MARGIN_QUIET:
118 : 1180 - 129 - 1430(45.21% R-33.38)
128 : 1190 - 191 - 1461(44.89% R-35.64)
138 : 1254 - 155 - 1363(47.92% R-14.48)
148 : 1208 - 138 - 1464(45.21% R-33.39)
158 : 1247 - 166 - 1367(47.7% R-15.96)
PARAM_FUTILITY_AT_PARENT_NODE_ALPHA:
127 : 2043 - 229 - 2298(47.06% R-20.43)
137 : 2050 - 244 - 2315(46.96% R-21.12)
147 : 1986 - 306 - 2472(44.55% R-38.03)
PARAM_FUTILITY_AT_PARENT_NODE_GAMMA1:
28 : 1999 - 286 - 2296(46.54% R-24.06)
30 : 2025 - 268 - 2413(45.63% R-30.45)
32 : 2055 - 225 - 2376(46.38% R-25.21)
PARAM_LMR_SEE_MARGIN1:
165 : 1207 - 149 - 1391(46.46% R-24.65)
175 : 1218 - 149 - 1398(46.56% R-23.94)
185 : 1217 - 152 - 1445(45.72% R-29.83)
195 : 1204 - 165 - 1387(46.47% R-24.58)
205 : 1233 - 164 - 1464(45.72% R-29.83)
PARAM_NULL_MOVE_DYNAMIC_GAMMA:
132 : 2085 - 246 - 2351(47.0% R-20.86)
142 : 2005 - 269 - 2373(45.8% R-29.27)
152 : 1989 - 264 - 2361(45.72% R-29.78)
PARAM_NULL_MOVE_MARGIN4:
181 : 1219 - 165 - 1481(45.15% R-33.82)
231 : 1195 - 167 - 1472(44.81% R-36.22)
281 : 1215 - 148 - 1383(46.77% R-22.5)
331 : 1211 - 167 - 1332(47.62% R-16.54)
381 : 1239 - 132 - 1417(46.65% R-23.32)
PARAM_PROBCUT_MARGIN1:
163 : 1968 - 267 - 2329(45.8% R-29.26)
168 : 2026 - 252 - 2430(45.47% R-31.59)
173 : 2085 - 260 - 2326(47.27% R-19.0)
PARAM_PROBCUT_MARGIN2:
50 : 1209 - 167 - 1397(46.39% R-25.11)
55 : 1225 - 157 - 1398(46.7% R-22.95)
60 : 1236 - 161 - 1420(46.54% R-24.11)
65 : 1212 - 143 - 1412(46.19% R-26.53)
70 : 1197 - 151 - 1458(45.08% R-34.27)
PARAM_PROBCUT_MARGIN3:
396 : 1176 - 185 - 1402(45.62% R-30.54)
406 : 1175 - 135 - 1393(45.76% R-29.57)
416 : 1255 - 149 - 1523(45.18% R-33.62)
426 : 1195 - 158 - 1343(47.08% R-20.28)
436 : 1278 - 152 - 1424(47.3% R-18.79)
PARAM_SINGULAR_MARGIN1:
64 : 1259 - 151 - 1460(46.3% R-25.73)
66 : 1192 - 157 - 1412(45.78% R-29.42)
68 : 1246 - 170 - 1389(47.29% R-18.87)
70 : 1151 - 163 - 1360(45.84% R-28.99)
72 : 1231 - 138 - 1464(45.68% R-30.11)
PARAM_LMR_MARGIN1:
47 : 2003 - 257 - 2376(45.74% R-29.67)
51 : 2047 - 258 - 2383(46.21% R-26.4)
55 : 2029 - 264 - 2326(46.59% R-23.73)
PARAM_LMR_MARGIN2:
12 : 2930 - 384 - 3547(45.24% R-33.2)
13 : 3149 - 395 - 3538(47.09% R-20.23)
PARAM_LMR_MARGIN3:
650 : 1209 - 156 - 1455(45.38% R-32.17)
675 : 1203 - 134 - 1396(46.29% R-25.85)
700 : 1249 - 165 - 1384(47.44% R-17.83)
725 : 1199 - 156 - 1469(44.94% R-35.28)
750 : 1219 - 168 - 1381(46.88% R-21.68)
PARAM_UPDATE_ALL_STATS_EVAL_TH:
138 : 1219 - 133 - 1416(46.26% R-26.02)
153 : 1178 - 166 - 1428(45.2% R-33.43)
168 : 1253 - 158 - 1434(46.63% R-23.44)
183 : 1173 - 157 - 1402(45.55% R-30.98)
198 : 1256 - 165 - 1405(47.2% R-19.47)
PARAM_COUNTERMOVE_FAILLOW_MARGIN:
657 : 1187 - 157 - 1381(46.22% R-26.3)
682 : 1202 - 156 - 1404(46.12% R-26.99)
707 : 1267 - 164 - 1475(46.21% R-26.41)
732 : 1219 - 149 - 1406(46.44% R-24.79)
757 : 1204 - 153 - 1419(45.9% R-28.54)
PARAM_MOVEPICKER_SORT_TH:
960 : 1157 - 143 - 1432(44.69% R-37.04)
1460 : 1223 - 159 - 1380(46.98% R-20.98)
1960 : 1225 - 159 - 1452(45.76% R-29.53)
2460 : 1223 - 164 - 1435(46.01% R-27.77)
2960 : 1251 - 154 - 1386(47.44% R-17.8)
PARAM_MOVEPICKER_SORT_ALPHA:
2130 : 1259 - 152 - 1436(46.72% R-22.85)
2630 : 1208 - 151 - 1407(46.2% R-26.49)
3130 : 1197 - 173 - 1386(46.34% R-25.47)
3630 : 1219 - 161 - 1452(45.64% R-30.39)
4130 : 1196 - 142 - 1404(46.0% R-27.85)
PARAM_MOVEPICKER_USE_SUPERSORT:
0 : 6079 - 779 - 7085(46.18% R-26.6)
- super sortあり。
total : 6090 - 823 - 7068(46.28% R-25.87)
total : 6090 - 823 - 7068(46.28% R-25.87)
PARAM_REDUCTIONS_PARAM1:
2033 : 1303 - 183 - 1405(48.12% R-13.09)
2035 : 1170 - 168 - 1397(45.58% R-30.8)
2037 : 1193 - 143 - 1467(44.85% R-35.92)
2039 : 1159 - 176 - 1384(45.58% R-30.82)
2041 : 1265 - 153 - 1415(47.2% R-19.47)
PARAM_REDUCTION_ALPHA:
1359 : 1144 - 186 - 1464(43.87% R-42.85)
1423 : 1227 - 147 - 1402(46.67% R-23.16)
1487 : 1225 - 165 - 1425(46.23% R-26.27)
1551 : 1283 - 156 - 1383(48.12% R-13.04)
1615 : 1211 - 169 - 1394(46.49% R-24.45)
PARAM_REDUCTION_BETA:
680 : 1193 - 173 - 1377(46.42% R-24.92)
744 : 1203 - 158 - 1386(46.47% R-24.6)
808 : 1216 - 163 - 1442(45.75% R-29.61)
872 : 1219 - 156 - 1467(45.38% R-32.17)
936 : 1259 - 173 - 1396(47.42% R-17.94)
PARAM_REDUCTION_GAMMA:
912 : 1198 - 183 - 1406(46.01% R-27.81)
944 : 1263 - 147 - 1409(47.27% R-19.0)
976 : 1252 - 176 - 1386(47.46% R-17.66)
1008 : 1203 - 168 - 1373(46.7% R-22.96)
1040 : 1174 - 149 - 1494(44.0% R-41.87)
PARAM_FUTILITY_MARGIN_ALPHA1:
105 : 1207 - 178 - 1423(45.89% R-28.6)
115 : 1189 - 162 - 1528(43.76% R-43.58)
125 : 1154 - 154 - 1348(46.12% R-26.99)
135 : 1277 - 164 - 1393(47.83% R-15.1)
145 : 1263 - 165 - 1376(47.86% R-14.89)
PARAM_FUTILITY_MARGIN_ALPHA2:
33 : 1199 - 159 - 1410(45.96% R-28.16)
38 : 1239 - 154 - 1418(46.63% R-23.44)
43 : 1237 - 181 - 1429(46.4% R-25.07)
48 : 1202 - 181 - 1415(45.93% R-28.34)
53 : 1213 - 148 - 1396(46.49% R-24.41)
PARAM_FUTILITY_MARGIN_BETA:
100 : 1260 - 155 - 1459(46.34% R-25.47)
108 : 1242 - 158 - 1397(47.06% R-20.43)
138 : 1197 - 175 - 1423(45.69% R-30.04)
168 : 1198 - 165 - 1390(46.29% R-25.82)
198 : 1193 - 170 - 1399(46.03% R-27.67)
PARAM_FUTILITY_MARGIN_QUIET:
118 : 1181 - 167 - 1352(46.62% R-23.49)
128 : 1227 - 178 - 1454(45.77% R-29.49)
138 : 1188 - 164 - 1454(44.97% R-35.1)
148 : 1239 - 168 - 1388(47.16% R-19.73)
158 : 1255 - 146 - 1420(46.92% R-21.46)
PARAM_FUTILITY_AT_PARENT_NODE_ALPHA:
127 : 1958 - 264 - 2298(46.01% R-27.81)
137 : 2032 - 282 - 2376(46.1% R-27.17)
147 : 2100 - 277 - 2394(46.73% R-22.76)
PARAM_FUTILITY_AT_PARENT_NODE_GAMMA1:
28 : 2106 - 290 - 2407(46.67% R-23.21)
30 : 1999 - 258 - 2305(46.45% R-24.74)
32 : 1985 - 275 - 2356(45.73% R-29.77)
PARAM_LMR_SEE_MARGIN1:
165 : 1288 - 172 - 1356(48.71% R-8.94)
175 : 1164 - 164 - 1426(44.94% R-35.27)
185 : 1194 - 163 - 1381(46.37% R-25.28)
195 : 1244 - 165 - 1448(46.21% R-26.38)
205 : 1200 - 159 - 1457(45.16% R-33.71)
PARAM_NULL_MOVE_DYNAMIC_GAMMA:
132 : 2093 - 273 - 2327(47.35% R-18.41)
142 : 1994 - 266 - 2303(46.4% R-25.03)
152 : 2003 - 284 - 2438(45.1% R-34.14)
PARAM_NULL_MOVE_MARGIN4:
181 : 1172 - 160 - 1395(45.66% R-30.26)
231 : 1212 - 159 - 1431(45.86% R-28.85)
281 : 1230 - 185 - 1428(46.28% R-25.93)
331 : 1215 - 155 - 1346(47.44% R-17.79)
381 : 1261 - 164 - 1468(46.21% R-26.4)
PARAM_PROBCUT_MARGIN1:
163 : 1991 - 283 - 2327(46.11% R-27.09)
168 : 2017 - 290 - 2424(45.42% R-31.93)
173 : 2082 - 250 - 2317(47.33% R-18.58)
PARAM_PROBCUT_MARGIN2:
50 : 1195 - 170 - 1396(46.12% R-27.01)
55 : 1185 - 169 - 1377(46.25% R-26.09)
60 : 1220 - 159 - 1435(45.95% R-28.2)
65 : 1247 - 166 - 1443(46.36% R-25.36)
70 : 1243 - 159 - 1417(46.73% R-22.76)
PARAM_PROBCUT_MARGIN3:
396 : 1156 - 167 - 1450(44.36% R-39.36)
406 : 1269 - 155 - 1373(48.03% R-13.68)
416 : 1244 - 161 - 1431(46.5% R-24.33)
426 : 1221 - 180 - 1368(47.16% R-19.75)
436 : 1200 - 160 - 1446(45.35% R-32.39)
PARAM_SINGULAR_MARGIN1:
64 : 1206 - 161 - 1461(45.22% R-33.32)
66 : 1200 - 140 - 1402(46.12% R-27.03)
68 : 1180 - 178 - 1421(45.37% R-32.28)
70 : 1246 - 190 - 1327(48.43% R-10.94)
72 : 1258 - 154 - 1457(46.34% R-25.51)
PARAM_LMR_MARGIN1:
47 : 2026 - 257 - 2333(46.48% R-24.51)
51 : 2046 - 298 - 2345(46.6% R-23.69)
55 : 2018 - 268 - 2390(45.78% R-29.39)
PARAM_LMR_MARGIN2:
12 : 3016 - 400 - 3588(45.67% R-30.17)
13 : 3074 - 423 - 3480(46.9% R-21.55)
PARAM_LMR_MARGIN3:
650 : 1203 - 167 - 1354(47.05% R-20.54)
675 : 1196 - 166 - 1403(46.02% R-27.73)
700 : 1236 - 169 - 1468(45.71% R-29.88)
725 : 1202 - 161 - 1445(45.41% R-31.99)
750 : 1253 - 160 - 1398(47.27% R-19.02)
PARAM_UPDATE_ALL_STATS_EVAL_TH:
138 : 1206 - 167 - 1411(46.08% R-27.27)
153 : 1185 - 161 - 1367(46.43% R-24.82)
168 : 1241 - 189 - 1420(46.64% R-23.41)
183 : 1249 - 152 - 1423(46.74% R-22.66)
198 : 1209 - 154 - 1447(45.52% R-31.22)
PARAM_COUNTERMOVE_FAILLOW_MARGIN:
657 : 1267 - 190 - 1445(46.72% R-22.84)
682 : 1188 - 165 - 1443(45.15% R-33.78)
707 : 1227 - 159 - 1393(46.83% R-22.04)
732 : 1264 - 144 - 1400(47.45% R-17.75)
757 : 1144 - 165 - 1387(45.2% R-33.46)
PARAM_MOVEPICKER_SORT_TH:
960 : 1239 - 176 - 1442(46.21% R-26.36)
1460 : 1249 - 142 - 1434(46.55% R-23.99)
1960 : 1206 - 153 - 1429(45.77% R-29.47)
2460 : 1226 - 172 - 1405(46.6% R-23.67)
2960 : 1170 - 180 - 1358(46.28% R-25.89)
PARAM_MOVEPICKER_SORT_ALPHA:
2130 : 1273 - 159 - 1428(47.13% R-19.96)
2630 : 1245 - 153 - 1490(45.52% R-31.21)
3130 : 1152 - 163 - 1383(45.44% R-31.75)
3630 : 1188 - 173 - 1368(46.48% R-24.51)
4130 : 1232 - 175 - 1399(46.83% R-22.08)
PARAM_MOVEPICKER_USE_SUPERSORT:
1 : 6090 - 823 - 7068(46.28% R-25.87)
- wasm用のビルド修正
wasm用のビルドでコケてた件、最新のemsdkだとビルドに失敗するとのことであった。(なんでかは知らん) そこで少し前のバージョンを指定することでビルド自体は成功するそうであった。
// ということは、このまま放置しておけば、emsdkの方でfixされて、またビルドに成功するようになる可能性もあったのか…。
https://github.com/yaneurao/YaneuraOu/commit/95c9c9d794c1427d1ba7ffa0c49096b66207acea
V7.74param2
- 探索パラメーター増やしつつ、調整するか…。
- PawnHistory有効化
- パラメーター増やす
- PARAM_MOVEPICKER_SORT_TH導入
- SuperSortテスト
total : 7265 - 888 - 8375(46.45% R-24.7)
total : 7265 - 888 - 8375(46.45% R-24.7)
PARAM_REDUCTIONS_PARAM1:
2029 : 1412 - 200 - 1672(45.78% R-29.36)
2033 : 1458 - 199 - 1701(46.15% R-26.78)
2037 : 1478 - 154 - 1674(46.89% R-21.63) このへんで悪くなさそう..
2041 : 1468 - 155 - 1672(46.75% R-22.6)
2045 : 1449 - 180 - 1656(46.67% R-23.2)
PARAM_REDUCTION_ALPHA:
1231 : 1446 - 171 - 1741(45.37% R-32.25)
1359 : 1471 - 172 - 1677(46.73% R-22.77)
1487 : 1454 - 202 - 1698(46.13% R-26.95) このへんで悪くなさそう
1615 : 1444 - 164 - 1617(47.17% R-19.66)
1743 : 1450 - 179 - 1642(46.9% R-21.6)
PARAM_REDUCTION_BETA:
680 : 1466 - 185 - 1616(47.57% R-16.92)
744 : 1467 - 158 - 1683(46.57% R-23.86)
808 : 1453 - 171 - 1689(46.24% R-26.15) よくわからん..
872 : 1435 - 172 - 1716(45.54% R-31.07)
936 : 1444 - 202 - 1671(46.36% R-25.36)
PARAM_REDUCTION_GAMMA:
976 : 1462 - 181 - 1637(47.18% R-19.64) 元の値
1040 : 1441 - 165 - 1650(46.62% R-23.53)
1104 : 1484 - 172 - 1646(47.41% R-18.0)
1168 : 1473 - 186 - 1703(46.38% R-25.2)
1232 : 1405 - 184 - 1739(44.69% R-37.05)
PARAM_FUTILITY_MARGIN_ALPHA1:
100 : 1446 - 177 - 1716(45.73% R-29.74)
105 : 1434 - 182 - 1751(45.02% R-34.69)
125 : 1446 - 169 - 1606(47.38% R-18.23)
145 : 1484 - 177 - 1654(47.29% R-18.84)
165 : 1455 - 183 - 1648(46.89% R-21.64)
PARAM_FUTILITY_MARGIN_ALPHA2:
23 : 1485 - 178 - 1751(45.89% R-28.62)
33 : 1492 - 203 - 1546(49.11% R-6.18)
43 : 1502 - 152 - 1625(48.03% R-13.67)
53 : 1423 - 168 - 1736(45.05% R-34.54)
63 : 1363 - 187 - 1717(44.25% R-40.11)
PARAM_FUTILITY_MARGIN_BETA:
100 : 1458 - 155 - 1668(46.64% R-23.38)
108 : 1456 - 169 - 1664(46.67% R-23.2)
138 : 1455 - 197 - 1693(46.22% R-26.32)
168 : 1441 - 199 - 1680(46.17% R-26.66)
198 : 1455 - 168 - 1670(46.56% R-23.94)
PARAM_FUTILITY_MARGIN_QUIET:
108 : 1468 - 192 - 1718(46.08% R-27.32)
118 : 1428 - 167 - 1707(45.55% R-31.0)
128 : 1473 - 182 - 1636(47.38% R-18.23)
138 : 1423 - 174 - 1689(45.73% R-29.77)
148 : 1473 - 173 - 1625(47.55% R-17.06)
PARAM_FUTILITY_AT_PARENT_NODE_ALPHA:
117 : 1436 - 189 - 1680(46.08% R-27.26)
127 : 1429 - 182 - 1637(46.61% R-23.61)
137 : 1470 - 197 - 1716(46.14% R-26.88)
147 : 1489 - 150 - 1651(47.42% R-17.94)
157 : 1441 - 170 - 1691(46.01% R-27.79)
PARAM_FUTILITY_AT_PARENT_NODE_GAMMA1:
22 : 1398 - 171 - 1648(45.9% R-28.58)
24 : 1493 - 181 - 1725(46.4% R-25.09)
26 : 1460 - 186 - 1703(46.16% R-26.74)
28 : 1448 - 159 - 1658(46.62% R-23.53)
30 : 1466 - 191 - 1641(47.18% R-19.59) わからん..
PARAM_LMR_SEE_MARGIN1:
145 : 1451 - 173 - 1722(45.73% R-29.75)
165 : 1460 - 186 - 1681(46.48% R-24.49)
185 : 1434 - 165 - 1693(45.86% R-28.84)
205 : 1460 - 184 - 1608(47.59% R-16.77)
225 : 1460 - 180 - 1671(46.63% R-23.45)
PARAM_NULL_MOVE_DYNAMIC_GAMMA:
132 : 1453 - 160 - 1625(47.21% R-19.44)
142 : 1493 - 167 - 1650(47.5% R-17.37)
152 : 1409 - 185 - 1637(46.26% R-26.06)
162 : 1460 - 199 - 1772(45.17% R-33.64)
172 : 1450 - 177 - 1691(46.16% R-26.71)
PARAM_NULL_MOVE_MARGIN1:
21 : 1427 - 185 - 1687(45.83% R-29.08)
22 : 1416 - 183 - 1720(45.15% R-33.79)
23 : 1507 - 191 - 1653(47.69% R-16.06)
24 : 1424 - 165 - 1601(47.07% R-20.35) このへんか
25 : 1491 - 164 - 1714(46.52% R-24.21)
PARAM_NULL_MOVE_MARGIN4:
181 : 1413 - 185 - 1715(45.17% R-33.65)
231 : 1437 - 177 - 1609(47.18% R-19.64)
281 : 1464 - 172 - 1711(46.11% R-27.08)
331 : 1460 - 186 - 1674(46.59% R-23.76)
381 : 1491 - 168 - 1666(47.23% R-19.28)
PARAM_PROBCUT_MARGIN1:
158 : 1466 - 196 - 1701(46.29% R-25.83)
163 : 1429 - 173 - 1631(46.7% R-22.97)
168 : 1488 - 160 - 1590(48.34% R-11.52) このへんでよさげ
173 : 1417 - 174 - 1753(44.7% R-36.96)
178 : 1465 - 185 - 1700(46.29% R-25.84)
PARAM_PROBCUT_MARGIN2:
50 : 1479 - 152 - 1656(47.18% R-19.64)
60 : 1471 - 175 - 1625(47.51% R-17.3) このへんか?
70 : 1395 - 176 - 1717(44.83% R-36.08)
80 : 1465 - 189 - 1667(46.78% R-22.44)
90 : 1455 - 196 - 1710(45.97% R-28.05)
PARAM_PROBCUT_MARGIN3:
396 : 1494 - 195 - 1692(46.89% R-21.62)
406 : 1465 - 171 - 1688(46.46% R-24.61)
416 : 1402 - 173 - 1684(45.43% R-31.84)
426 : 1469 - 176 - 1644(47.19% R-19.55)
436 : 1435 - 173 - 1667(46.26% R-26.03)
PARAM_SINGULAR_MARGIN1:
64 : 1422 - 174 - 1684(45.78% R-29.38)
68 : 1489 - 180 - 1708(46.57% R-23.84) わからん..
72 : 1434 - 195 - 1700(45.76% R-29.56)
76 : 1471 - 161 - 1620(47.59% R-16.76)
80 : 1449 - 178 - 1663(46.56% R-23.93)
PARAM_LMR_MARGIN1:
47 : 2467 - 297 - 2827(46.6% R-23.66)
51 : 2388 - 297 - 2802(46.01% R-27.77)
55 : 2410 - 294 - 2746(46.74% R-22.67)
PARAM_LMR_MARGIN2:
11 : 3651 - 436 - 4262(46.14% R-26.88)
12 : 3614 - 452 - 4113(46.77% R-22.47) こっちか 12,13を試す
PARAM_LMR_MARGIN3:
600 : 1396 - 190 - 1667(45.58% R-30.82)
650 : 1496 - 188 - 1672(47.22% R-19.32)
700 : 1449 - 171 - 1637(46.95% R-21.19)
750 : 1460 - 188 - 1681(46.48% R-24.49)
800 : 1464 - 151 - 1718(46.01% R-27.79)
PARAM_UPDATE_ALL_STATS_EVAL_TH:
108 : 1470 - 193 - 1683(46.62% R-23.51)
138 : 1408 - 157 - 1653(46.0% R-27.87)
168 : 1479 - 188 - 1637(47.46% R-17.63) このへんか
198 : 1447 - 181 - 1698(46.01% R-27.79)
200 : 39 - 2 - 40(49.37% R-4.4)
228 : 1422 - 167 - 1664(46.08% R-27.3)
PARAM_COUNTERMOVE_FAILLOW_MARGIN:
557 : 1401 - 161 - 1670(45.62% R-30.51)
607 : 1441 - 182 - 1730(45.44% R-31.75)
657 : 1492 - 185 - 1696(46.8% R-22.26)
707 : 1464 - 173 - 1640(47.16% R-19.72)
757 : 1467 - 187 - 1639(47.23% R-19.26)
total : 5266 - 550 - 6184(45.99% R-27.92)
total : 5266 - 550 - 6184(45.99% R-27.92)
PARAM_REDUCTIONS_PARAM1:
2021 : 1053 - 104 - 1259(45.54% R-31.04)
2029 : 1017 - 120 - 1243(45.0% R-34.86)
2037 : 1091 - 105 - 1237(46.86% R-21.82) このへん
2045 : 1042 - 102 - 1170(47.11% R-20.13)
2053 : 1063 - 119 - 1275(45.47% R-31.59)
PARAM_REDUCTION_ALPHA:
1231 : 1016 - 109 - 1253(44.78% R-36.42)
1359 : 1051 - 120 - 1257(45.54% R-31.09)
1487 : 1079 - 109 - 1227(46.79% R-22.33)
1615 : 1052 - 119 - 1263(45.44% R-31.76)
1743 : 1068 - 93 - 1184(47.42% R-17.91)
PARAM_REDUCTION_BETA:
552 : 999 - 109 - 1237(44.68% R-37.12)
680 : 1071 - 101 - 1235(46.44% R-24.75)
808 : 1081 - 112 - 1234(46.7% R-23.0)
936 : 1025 - 112 - 1268(44.7% R-36.96)
1064 : 1090 - 116 - 1210(47.39% R-18.14)
PARAM_REDUCTION_GAMMA:
720 : 1046 - 112 - 1234(45.88% R-28.71)
848 : 1044 - 84 - 1281(44.9% R-35.54)
976 : 1106 - 116 - 1214(47.67% R-16.19)
1104 : 1061 - 134 - 1226(46.39% R-25.11)
1232 : 1009 - 104 - 1229(45.08% R-34.26)
PARAM_FUTILITY_MARGIN_ALPHA1:
100 : 1047 - 103 - 1245(45.68% R-30.09)
105 : 1056 - 118 - 1251(45.77% R-29.44)
125 : 1011 - 109 - 1203(45.66% R-30.21)
145 : 1093 - 105 - 1238(46.89% R-21.64)
165 : 1059 - 115 - 1247(45.92% R-28.39)
PARAM_FUTILITY_MARGIN_ALPHA2:
23 : 1060 - 116 - 1196(46.99% R-20.97)
33 : 1023 - 98 - 1198(46.06% R-27.43)
43 : 1058 - 113 - 1279(45.27% R-32.95)
53 : 1059 - 108 - 1271(45.45% R-31.7)
63 : 1066 - 115 - 1240(46.23% R-26.27)
PARAM_FUTILITY_MARGIN_BETA:
100 : 1069 - 120 - 1215(46.8% R-22.24)
108 : 1071 - 90 - 1258(45.99% R-27.96)
138 : 1024 - 117 - 1216(45.71% R-29.85)
168 : 1041 - 106 - 1281(44.83% R-36.04)
198 : 1061 - 117 - 1214(46.64% R-23.4)
PARAM_FUTILITY_MARGIN_QUIET:
98 : 1050 - 123 - 1287(44.93% R-35.36)
108 : 1039 - 106 - 1212(46.16% R-26.75)
118 : 1065 - 105 - 1242(46.16% R-26.71)
128 : 1052 - 108 - 1227(46.16% R-26.73) このへん?
138 : 1060 - 108 - 1216(46.57% R-23.85)
PARAM_FUTILITY_AT_PARENT_NODE_ALPHA:
107 : 1073 - 124 - 1291(45.39% R-32.13)
117 : 1092 - 110 - 1257(46.49% R-24.45)
127 : 1041 - 107 - 1231(45.82% R-29.12)
137 : 1053 - 116 - 1229(46.14% R-26.85) このへん?
147 : 1007 - 93 - 1176(46.13% R-26.95)
PARAM_FUTILITY_AT_PARENT_NODE_GAMMA1:
24 : 1785 - 173 - 2059(46.44% R-24.81)
26 : 1736 - 189 - 2089(45.39% R-32.16)
28 : 1745 - 188 - 2036(46.15% R-26.79)
PARAM_LMR_SEE_MARGIN1:
105 : 1027 - 96 - 1251(45.08% R-34.27)
145 : 1069 - 121 - 1281(45.49% R-31.43)
185 : 1082 - 101 - 1200(47.41% R-17.98) 範囲しぼる
225 : 1063 - 120 - 1232(46.32% R-25.63)
265 : 1025 - 112 - 1220(45.66% R-30.25)
PARAM_NULL_MOVE_DYNAMIC_GAMMA:
132 : 1085 - 109 - 1210(47.28% R-18.94)
142 : 1029 - 97 - 1298(44.22% R-40.34)
152 : 1046 - 102 - 1236(45.84% R-28.99)
162 : 1024 - 124 - 1214(45.76% R-29.57)
172 : 1082 - 118 - 1226(46.88% R-21.71)
PARAM_NULL_MOVE_MARGIN1:
20 : 1029 - 105 - 1252(45.11% R-34.08)
22 : 1124 - 108 - 1211(48.14% R-12.95) このへん?
24 : 1067 - 117 - 1233(46.39% R-25.12)
26 : 1032 - 122 - 1217(45.89% R-28.64)
28 : 1014 - 98 - 1271(44.38% R-39.24)
PARAM_NULL_MOVE_MARGIN4:
181 : 1028 - 98 - 1260(44.93% R-35.35)
231 : 1079 - 120 - 1205(47.24% R-19.19)
281 : 1018 - 117 - 1298(43.96% R-42.21)
331 : 1129 - 108 - 1224(47.98% R-14.03)
381 : 1012 - 107 - 1197(45.81% R-29.17)
PARAM_PROBCUT_MARGIN1:
128 : 1095 - 104 - 1238(46.94% R-21.32)
148 : 1041 - 112 - 1325(44.0% R-41.91)
168 : 1068 - 101 - 1170(47.72% R-15.85)
188 : 1004 - 93 - 1216(45.23% R-33.28)
208 : 1058 - 140 - 1235(46.14% R-26.87)
PARAM_PROBCUT_MARGIN2:
50 : 1078 - 110 - 1263(46.05% R-27.51)
60 : 1056 - 112 - 1201(46.79% R-22.35)
70 : 1009 - 97 - 1216(45.35% R-32.42)
80 : 1102 - 110 - 1257(46.71% R-22.86)
90 : 1021 - 121 - 1247(45.02% R-34.74)
PARAM_PROBCUT_MARGIN3:
396 : 1022 - 113 - 1277(44.45% R-38.7)
406 : 1081 - 113 - 1226(46.86% R-21.87)
416 : 1012 - 119 - 1255(44.64% R-37.39)
426 : 1060 - 102 - 1226(46.37% R-25.27)
436 : 1091 - 103 - 1200(47.62% R-16.54)
PARAM_SINGULAR_MARGIN1:
48 : 997 - 100 - 1207(45.24% R-33.2)
56 : 1077 - 114 - 1259(46.1% R-27.12)
64 : 1015 - 106 - 1287(44.09% R-41.25)
72 : 1083 - 114 - 1228(46.86% R-21.83) このへん
80 : 1094 - 116 - 1203(47.63% R-16.5)
PARAM_SINGULAR_MARGIN2:
41 : 1042 - 111 - 1248(45.5% R-31.34)
49 : 1040 - 100 - 1242(45.57% R-30.84)
57 : 1078 - 123 - 1211(47.09% R-20.21) ☑
65 : 1062 - 107 - 1213(46.68% R-23.09)
73 : 1044 - 109 - 1270(45.12% R-34.04)
PARAM_LMR_MARGIN1:
47 : 1771 - 182 - 2072(46.08% R-27.27)
51 : 1778 - 190 - 2119(45.62% R-30.48)
55 : 1717 - 178 - 1993(46.28% R-25.89)
PARAM_LMR_MARGIN2:
9 : 1773 - 169 - 2049(46.39% R-25.13)
10 : 1695 - 198 - 2110(44.55% R-38.05)
11 : 1798 - 183 - 2025(47.03% R-20.65) ☑ 11,12
PARAM_LMR_MARGIN3:
500 : 1043 - 101 - 1225(45.99% R-27.94)
600 : 1076 - 105 - 1224(46.78% R-22.39)
700 : 1082 - 102 - 1255(46.3% R-25.77) 範囲しぼる
800 : 1050 - 116 - 1218(46.3% R-25.78)
900 : 1015 - 126 - 1262(44.58% R-37.84)
PARAM_UPDATE_ALL_STATS_EVAL_TH:
108 : 1106 - 114 - 1232(47.31% R-18.74)
138 : 1003 - 108 - 1295(43.65% R-44.39)
168 : 1023 - 112 - 1225(45.51% R-31.3)
198 : 1076 - 119 - 1227(46.72% R-22.81)
200 : 1058 - 97 - 1205(46.75% R-22.6)
PARAM_COUNTERMOVE_FAILLOW_MARGIN:
557 : 1080 - 107 - 1266(46.04% R-27.6)
607 : 1030 - 105 - 1237(45.43% R-31.81)
657 : 1016 - 120 - 1189(46.08% R-27.32)
707 : 1071 - 106 - 1258(45.99% R-27.96)
757 : 1069 - 112 - 1234(46.42% R-24.93)
PARAM_QSEARCH_PRUNE_LE0_SEE_MOVE:
0 : 2715 - 280 - 3069(46.94% R-21.29) ☑
1 : 2551 - 270 - 3115(45.02% R-34.7)
V7.74j2
-
qsearchでcaptureとcheck以外は指し手を進めないようにしてみる。
次のように修正する。
// 置換表の指し手であろうが、captureでもcheckでもない指し手ではこれ以上局面を進めない。 // (やねうら王独自改良) // ※ 王手がかかっている局面は、下手にcontinueすると、詰みの局面と勘違いしてしまうのでcontinueしたらダメ。 // → ここにdepth < -4 などの条件追加したほうがいいかも。 if (!ss->inCheck && !(givesCheck || capture)) continue;
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V774j2_1024.exe , eval = Li T2,r300,1556 - 58 - 1386(52.89% R20.1[9.55,30.65]) winrate black , white = 51.97% , 48.03% T2,b1000,1583 - 101 - 1316(54.61% R32.09[21.43,42.75]) winrate black , white = 51.88% , 48.12% T2,b2000,538 - 43 - 439(55.07% R35.33[16.96,53.7]) winrate black , white = 52.51% , 47.49%
→ そこまで悪くないが…弱くはなってるか。
V7.74j
-
qsearchでcaptureとcheck以外は指し手を進めないようにしてみる。
// 置換表の指し手であろうが、captureでもcheckでもない指し手ではこれ以上局面を進めない。 // (やねうら王独自改良) // → ここにdepth < -4 などの条件追加したほうがいいかも。 if (!givesCheck && !capture) continue;
→ めっちゃ成績わるかった。 王手がかかってる局面は、指し手調べないと間違えて詰みだと判定してしまうからか…。
V7.74i
- PanwHistory無効化
- V7.74h無効化
- V7.74e採用
- V7.74gのdepth制限採用
- 探索パラメーター、いったんリセット
→ これでoptimizerにかけることにするか。
・以前のバージョンでなぜqsearchで千日手にならないのかよく考える。 → see <= 0の指し手、枝刈りしてるからじゃね?
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li
engine2 = YaneuraOuNNUE_V774i_1024.exe , eval = Li
T2,b1000,1515 - 92 - 1393(52.1% R14.58[3.98,25.19]) winrate black , white = 51.07% , 48.93%
T2,b2000,1501 - 126 - 1373(52.23% R15.48[4.82,26.15]) winrate black , white = 52.37% , 47.63%
T2,b4000,1138 - 105 - 927(55.11% R35.63[22.99,48.26]) winrate black , white = 52.11% , 47.89%
→ そんな悪くないんだよなー。4秒では弱いか…。
→ パラメーターリセットして、PawnHistory有効化してレーティングどうなのかという問題はあるか。
V7.74h
-
PanwHistory無効化
-
qsearchでcaptureとcheck以外は指し手を進めないようにしてみる。 → ぜんぜんあかんかった。 → これ、is_legalの前にテストしてたから、合法手がないことになってしまうのか…。 → moveCountのインクリメント終わってからやらないといけない&continueで書かないといけない…ということか。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V774h_1024.exe , eval = Li T2,b1000,279 - 9 - 132(67.88% R130.01[99.86,160.16]) winrate black , white = 49.88% , 50.12% // 置換表の指し手であろうが、captureでもcheckでもない指し手ではこれ以上局面を進めない。 // (やねうら王独自改良) // → ここにdepth < -4 などの条件追加したほうがいいかも。 if (!givesCheck && !capture) return ss->staticEval;
やねうらお — 今日 11:00
原因コード特定できた。
if (futilityBase <= alpha && !pos.see_ge(move, VALUE_ZERO + 1))
{
bestValue = std::max(bestValue, futilityBase);
ASSERT_LV3(bestValue != -VALUE_INFINITE);
continue;
}
以前のqsearchには⇑のコードがあった。see_ge(move, 1)となってて、要するにSEE値 ≧ 1でなければ、その指し手ではdo_move(局面を進める)しないことになっている。
つまりは、置換表の指し手(これは王手と駒を取る手以外の手であることがある)に対しても、それが駒得であることを強要する非常につよい枝刈りとなっている。
逆につよすぎる枝刈りではないかと心配になるぐらいだ。
V7.74g
-
V7.74dやめ。
-
V7.74e採用。
-
V7.74fやめ。
-
PawnHistory有効化
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V774g_1024.exe , eval = Li T2,b1000,1494 - 86 - 1420(51.27% R8.82[-1.76,19.41]) winrate black , white = 51.17% , 48.83% T2,b2000,1578 - 134 - 1288(55.06% R35.28[24.55,46.0]) winrate black , white = 51.57% , 48.43% T2,b4000,1488 - 185 - 1327(52.86% R19.89[9.11,30.68]) winrate black , white = 52.36% , 47.64% → R20ぐらい悪くなった…。4秒ではそうでもないか…。
・PawnKey導入 → 探索パラメーター調整後、再度棋力計測する → 計測するまでもなく悪そう。今回は採用見送り。
-
Double weight of pawn history for quiet move ordering. : https://github.com/official-stockfish/Stockfish/commit/80b0e3754303c44bdcc53c01339a955d5677cd64
-
Remove pawn history from ProbCut constructor : https://github.com/official-stockfish/Stockfish/commit/d0e87104aa782176735442e1f6668f91014f07eb → probcutの時のMovePickerではpawn historyを使わないようになった。
-
qsearchの時に、depth < -16 なら draw_value返す。
auto draw_type = pos.is_repetition2(16, ss->ply); if (draw_type != REPETITION_NONE) return value_from_tt(draw_value(draw_type, pos.side_to_move()), ss->ply);
// 16手以内の循環になってないのにqsearchで16手も延長している場合、 // 置換表の指し手だけで長い循環になっている可能性が高く、 // これは引き分け扱いにしてしまう。(やねうら王独自改良)
if (ss->ply >= MAX_PLY || depth <= -16) return draw_value(REPETITION_DRAW, pos.side_to_move());
V7.74f
-
qsearchで一定以上深い時に置換表の指し手を無視する。
-
V7.74d,eは採用したまま。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V774f_1024.exe , eval = Li T2,b1000,1528 - 85 - 1387(52.42% R16.82[6.22,27.41]) winrate black , white = 52.38% , 47.62% T2,b2000,1526 - 120 - 1354(52.99% R20.77[10.11,31.44]) winrate black , white = 51.81% , 48.19% T2,b4000,943 - 112 - 845(52.74% R19.06[5.53,32.59]) winrate black , white = 52.18% , 47.82%
// やねうら王独自拡張 // // ある程度深い探索において置換表の指し手を無視する。 // (置換表の指し手は優遇されているが、それによって千日手になるのは本意ではない) if (d <= DEPTH_QS_RECAPTURES) ttMove = ttm = MOVE_NONE;
→ これ、ttHit == trueで ttMove != MOVE_NONEのままになるから、 成績はどうあれ、MovePickerでやるのは、間違ってるわ。
-
qsearch()の千日手チェックまわりの問題。
⇓千日手チェック入れないとqsearchでこの局面でdepth = -100まで行く。 sfen l+BS3g1l/1S1GG4/1kp1p2pp/pr7/lpsp4+r/2Pn1PP2/PPNSP4/3K1G3/L8 b N4Pbnp 213
やねうらお — 今日 15:27
なんか原因がわかった。
qsearch()では、残りdepthは負になるのだけど、
depth == -1 の時だけ 駒を取る手 + 王手 を生成
depth < -1 の時は、駒を取る手だけを生成
これでなんで王手で追い回す循環になるのかと言うと、ttMove(置換表の指し手)は、優遇されてて、depth < -1でもttMoveの指し手で局面を進めるのだ。
その結果、ttMoveだけで循環局面になりMAX_PLYになるまで再帰してしまう。
王手回避の指し手は基本的にはすべて調べるので、王手で追い回された時に2通りの逃げ方があると、2通りの循環ができて組み合わせ爆発を起こすのだ。
qsearchのttMove以前のStockfishではここまで優遇されてなかったのだが、それがここ1年半ほどで優遇されるようになった結果、このような頻繁に現象が起きるようになったようである。
そこで
・qsearch()で千日手チェック
・延長する条件を厳しく
・depth < -5の時に局面を ttMoveで進めない
みたいな対策が必要になると思われる。
V7.74e
-
MovePickerでのqsearchの時は、歩の成りは生成しないようにする。
-
MovePickerでのqsearchの時は、歩の成らずはGenerateAllLegalMovesがオンでも生成しないようにする。
-
V7.74dは採用したまま
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V774e_1024.exe , eval = Li T2,b1000,1528 - 84 - 1388(52.4% R16.69[6.1,27.29]) winrate black , white = 50.72% , 49.28% T2,b2000,1505 - 119 - 1376(52.24% R15.57[4.91,26.22]) winrate black , white = 53.0% , 47.0% T2,b4000,1503 - 164 - 1333(53.0% R20.85[10.1,31.6]) winrate black , white = 51.97% , 48.03% → 改善してるかどうかはよくわからない…。
やねうらお — 今日 22:59
qsearch()でMovePicker、captureの指し手と歩の成りも生成しているのだが(search()のMovePickerと共通のコードになってて)、qsearchは王手と駒を取るSEE >=0 の指し手だけで十分なわけで、歩の成りの生成は無駄なような気がしてきた。😥 (将棋ソフト開発して10年目にして気づいたやつ)
V7.74d
-
V7.74cやめ
-
qsearch()のSEE < -90で枝刈りしている件、-89に変更。
// Do not search moves with bad enough SEE values (~5 Elo) // SEEが十分悪い指し手は探索しない。 // → 無駄な王手ラッシュみたいなのを抑制できる? // これ-90だとPawnValueなので歩損を許してしまう。 // -89以上にしたほうがいいような? if (!pos.see_ge(move, Value(-90))) continue; ⇓ if (!pos.see_ge(move, Value(- Eval::PawnValue + 1))) continue;
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V774d_1024.exe , eval = Li T2,b1000,1490 - 87 - 1423(51.15% R7.99[-2.6,18.58]) winrate black , white = 51.94% , 48.06% T2,b2000,1484 - 140 - 1376(51.89% R13.13[2.43,23.82]) winrate black , white = 52.73% , 47.27% T2,b4000,1517 - 172 - 1311(53.64% R25.35[14.58,36.13]) winrate black , white = 53.18% , 46.82%
V7.74c
-
qsearch()のnon-capture evasions、古いコードにしてみる。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V774c_1024.exe , eval = Li T2,b1000,1560 - 92 - 1348(53.65% R25.37[14.75,36.0]) winrate black , white = 52.51% , 47.49% T2,b2000,1491 - 117 - 1392(51.72% R11.94[1.29,22.58]) winrate black , white = 52.65% , 47.35% → そんなわるないか?
#if 0 // If static exchange evaluation is much worse than what is needed to not // fall below alpha we can prune this move if (futilityBase > alpha && !pos.see_ge(move, (alpha - futilityBase) * 4)) { bestValue = alpha; continue; } #else // 以下は、Stockfishの古いコードだが、⇓こちらの方が将棋に適合するかも。 // 無駄王手を抑制できる。 // // TODO : // ここで生成されている指し手は、成りと歩の成りだけだが、SEEで歩の成りに加点していないので、 // ここでcontinueしてしまう。 // そもそもqsearchで歩の成りは生成しなくていいような気もする。
// Do not search moves with negative SEE values (~5 Elo)
if ( bestValue > VALUE_TB_LOSS_IN_MAX_PLY
&& !pos.see_ge(move))
continue;
#endif
qsearchで延長のlimit入れたほうがいいんじゃないかな…。 それか、futility制限するだとか…。
V7.74b
-
assertに引っかかるUnitTestを削除。
-
探索中に引っかかるassertがあったの削除。
-
ProbCutで歩の成りが返ってくるが、このhistory、captureのところ見てたの修正。
-
qsearchで千日手チェック、やはり入れることにした。 ⇑pawn_historyは無効化してテスト。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V774b_1024.exe , eval = Li T2,b1000,1575 - 62 - 1363(53.61% R25.11[14.54,35.68]) winrate black , white = 51.43% , 48.57% T2,b2000,1550 - 123 - 1327(53.88% R26.98[16.3,37.67]) winrate black , white = 52.55% , 47.45% T2,b4000,1488 - 160 - 1352(52.39% R16.65[5.92,27.38]) winrate black , white = 53.13% , 46.87%
ブログのコメント欄。
やねうらお
2023年11月6日 19:43 より:編集
qsearch()の千日手判定を削除したから、固定depthで回していると、循環があってMAX_PLYまで探索が行って(その間に他の枝とかも調べたりで)探索が終わらないだとか、MAX_PLYにいくまでにstack使い切って落ちるだとか、たぶんそのへんではないかと思います。(これはコンパイル時にstack明示的に指定して増やしてないとそういうことが置きます)
取り急ぎ、qsearchの千日手判定を復活させることにしました。
Discordの書き込み。
やねうらお — 今日 19:46
そういや、qsearchで王手延長するの、あれ、どこかで抑制するようにした覚えがあるんすけど、qsearchのコードがStockfishのほうで変化があって、それ取り込んだからか、いつの間にかなくなってますな…。(これも原因なのかな…)
やねうらお — 今日 19:47
チェスでは、そんなに王手が続かないのかな…。それとも千日手チェックをしてるから、回避できてるのかな?
やねうらお — 今日 19:51
qsearchで、ある局面で王手が2通りあって、どちらでも循環してると、MAX_PLYに行くまでにこの2択の分岐が延々とあって、指数関数的な組み合わせを調べることになるから、(王手の限り延長し続けると)探索が終わらないのだ。😵💫
テスト用のベンチマークコマンド。
bench 1024 1 20 default depth
===========================
Total time (ms) : 17407
Nodes searched : 18404320
Nodes_searched/second : 1057294
bench 1024 1 25 default depth
===========================
Total time (ms) : 203149
Nodes searched : 216613758
Nodes_searched/second : 1066280
===========================
bench 1024 1 30 default depth
Threads 8
unittest auto_player_loop 1000 auto_player_depth 12
V7.74a
-
pawn history有効化して比較。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V774a_1024.exe , eval = Li T2,b1000,1493 - 92 - 1415(51.34% R9.32[-1.28,19.92]) winrate black , white = 52.72% , 47.28% T2,b2000,955 - 79 - 816(53.92% R27.33[13.71,40.94]) winrate black , white = 51.38% , 48.62% T2,b4000,413 - 37 - 400(50.8% R5.56[-14.48,25.59]) winrate black , white = 50.06% , 49.94%
→ これ有効化したところで、ほぼ変わらん説あるな…。 → よくわからんのであとで再度比較しよう。
V7.73z2
-
update_statsのところ修正漏れがあったのでなおした。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V773z2_1024.exe , eval = Li T2,b1000,1480 - 102 - 1418(51.07% R7.43[-3.18,18.05]) winrate black , white = 51.55% , 48.45% T2,b2000,583 - 56 - 511(53.29% R22.9[5.59,40.21]) winrate black , white = 51.1% , 48.9%
V7.73z
- Set reduction to 0 if the move is a TT move : https://github.com/official-stockfish/Stockfish/commit/d4b46ea6db7caf71cad3c36d0ef8c0162a743aba
- Use stat_malus when decreasing stats : https://github.com/official-stockfish/Stockfish/commit/442c294a07836e9e32ad8b3bad49a853cc6f47de
- Enhance some comments : https://github.com/official-stockfish/Stockfish/commit/791419aab529e714271ebc03d1d84ad4e7e9879a
V7.73y5
-
capture_stage()をcapture_or_valuable_promotion()に変更してみる。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V773y5_1024.exe , eval = Li T2,b1000,1558 - 102 - 1340(53.76% R26.19[15.54,36.83]) winrate black , white = 50.76% , 49.24% T2,b2000,1583 - 116 - 1231(56.25% R43.69[32.83,54.55]) winrate black , white = 51.24% , 48.76% → かなり悪くなった…。
V7.73y4
-
capture_stage()をcapture_or_pawn_promotion()に変更してみる。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V773y4_1024.exe , eval = Li T2,b1000,1543 - 93 - 1364(53.08% R21.42[10.8,32.04]) winrate black , white = 50.12% , 49.88% T2,b2000,1527 - 118 - 1355(52.98% R20.76[10.1,31.42]) winrate black , white = 52.39% , 47.61%
V7.73y3
-
move_picker.cpp、capture_stage()に変更するの忘れてた。 全部変更して、capture_stage()をcaptureに変更してみる。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V773y3_1024.exe , eval = Li T2,b1000,1505 - 82 - 1413(51.58% R10.96[0.37,21.54]) winrate black , white = 50.69% , 49.31% T2,b2000,1507 - 137 - 1356(52.64% R18.34[7.65,29.04]) winrate black , white = 51.62% , 48.38%
V7.73y2
- capture_stage()をcaptureに変更してみる。
bool capture_stage(Move m) const
{
//return capture_or_pawn_promotion(m);
// → R10ぐらい弱かった
return capture(m);
}
V7.73y
-
探索部、一通りStockfishと見比べた。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V773y_1024.exe , eval = Li T2,b1000,1540 - 99 - 1361(53.09% R21.47[10.84,32.09]) winrate black , white = 53.53% , 46.47%
V7.73x
-
capture_stage()追加。
-
Stockfishでcapture_stage()になっているところはそれに倣うことにした。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V773x_1024.exe , eval = Li T2,b1000,1566 - 76 - 1358(53.56% R24.76[14.16,35.35]) winrate black , white = 51.68% , 48.32% T2,b2000,1549 - 129 - 1322(53.95% R27.53[16.83,38.23]) winrate black , white = 50.51% , 49.49%
→ なんか弱くなってる気がする。 capture_stage、やっぱりあかんのちゃう? capture_stageをcapture_or_pawn_promotionにするのではなく単にcaptureとした方がいいか?
V7.73w
- yaneuraou.search.cppの字下げおかしくしてたところ修正した。
- 処理の順番、Stockfishに近くした。(機能的な変化はないはず)
- 探索部にコメント大量に追記。
V7.73v
- PARAM_FUTILITY_AT_PARENT_NODE_MARGIN1削除
- Tweaking the futility pruning formula : ttps://github.com/official-stockfish/Stockfish/commit/7f97ba775ece910402108d7a7b11ce645185d300
// 親nodeでのfutility margin
// 重要度 ★★★★☆
// 元の値 = 77 , step = 10
// [PARAM] min:30,max:400,step:5,interval:2,time_rate:1,
PARAM_DEFINE PARAM_FUTILITY_AT_PARENT_NODE_MARGIN1 = 67;
- 一つ前のcommitでMATE_ENGINEなどがビルドエラーになってたの修正。
V7.73u2
-
パラメーター、前回調整済みのやつに戻してテスト。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V773u2_1024.exe , eval = Li T2,b1000,1530 - 83 - 1387(52.45% R17.05[6.45,27.64]) winrate black , white = 52.25% , 47.75% T2,b2000,1509 - 139 - 1352(52.74% R19.09[8.39,29.78]) winrate black , white = 52.95% , 47.05% → こっちのほうが優れていそう…。
V7.73u
-
see_geのテスト追加した。 → ありゃ、test通らへん。see_ge()バグってるのか…。 → 駒打ちの時のseeの計算間違ってた。修正した。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V773u_1024.exe , eval = Li T2,r300,1156 - 50 - 1074(51.84% R12.78[0.67,24.89]) winrate black , white = 51.84% , 48.16% T2,b1000,1422 - 113 - 1465(49.26% R-5.18[-15.81,5.46]) winrate black , white = 53.48% , 46.52% T2,b2000,1201 - 101 - 1038(53.64% R25.34[13.23,37.45]) winrate black , white = 51.9% , 48.1%
V7.73t3
-
パラメーターデフォルトに戻してテストしてみる。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V773t3_1024.exe , eval = Li T2,r300,1612 - 54 - 1334(54.72% R32.88[22.31,43.46]) winrate black , white = 51.56% , 48.44% T2,b1000,1154 - 61 - 875(56.88% R48.08[35.27,60.88]) winrate black , white = 49.98% , 50.02% T2,b2000,524 - 43 - 403(56.53% R45.61[26.69,64.53]) winrate black , white = 54.69% , 45.31% T2,b4000,242 - 24 - 204(54.26% R29.67[2.54,56.81]) winrate black , white = 53.81% , 46.19%
V7.73t2
-
see_geのコード間違っていたの修正。
-
see_geのUnitTest書いた。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V773t2_1024.exe , eval = Li T2,r300,1553 - 68 - 1379(52.97% R20.64[10.07,31.21]) winrate black , white = 50.38% , 49.62% T2,b1000,1650 - 107 - 1243(57.03% R49.21[38.48,59.94]) winrate black , white = 52.47% , 47.53% T2,b2000,1312 - 92 - 976(57.34% R51.39[39.32,63.47]) winrate black , white = 50.74% , 49.26% T2,b4000,641 - 58 - 431(59.79% R68.95[51.16,86.74]) winrate black , white = 51.12% , 48.88% → めっさ弱くなっとる。
V7.73t
-
SEEのコード刷新。
- least_significant_square_bb()追加。
- BitboardのUnitTestにleast_significant_square_bbのテスト追加。
- BitboardのUnitTestのdecrementのコードが間違っていたの修正。
V7.73rでpinnersの処理修正したのはいいが、これ修正された結果、今度は、SEEの処理が間違ってることになっていた。
SEEのコード、Stockfishの最新版に合わせて刷新したほうがいいと思う…が、これ大変ややこしい処理で将棋独自のコードもふんだんにあるので、大改造になった。
⇓は元のPosition::see_ge()のコード。
// 次にtoの升で捕獲される駒
// 成りなら成りを評価したほうが良い可能性があるが、このあとの取り合いで指し手の成りを評価していないので…。
PieceType nextVictim = drop ? move_dropped_piece(m) : type_of(piece_on(from));
// 以下のwhileで想定している手番。
// 移動させる駒側の手番から始まるものとする。
// 次に列挙すべきは、この駒を取れる敵の駒なので、相手番に。
// ※「stm」とは"side to move"(手番側)を意味する用語。
Color us = color_of(moved_piece_after(m));
Color stm = ~us;
// 取り合いにおける収支。取った駒の価値と取られた駒の価値の合計。
// いまthresholdを超えるかどうかが問題なので、この分だけbiasを加えておく。
Value balance = (Value)Eval::CapturePieceValue[piece_on(to)] - threshold;
// この時点でマイナスになっているので早期にリターン。
if (balance < VALUE_ZERO)
return false;
// nextVictim == Kingの場合もある。玉が取られる指し手は考えなくて良いので
// この場合プラス収支と考えてよく、CapturePieceValue[KING] == 0が格納されているので
// 以下の式によりtrueが返る。
balance -= (Value)Eval::CapturePieceValue[nextVictim];
if (balance >= VALUE_ZERO)
return true;
// 相手側の手番ならtrue、自分側の手番であるならfalse
bool relativeStm = true;
// いま、以下のwhileのなかで想定している手番側の、sqの地点に利く駒
Bitboard stmAttackers;
// 盤上の駒(取り合いしていくうちにここから駒が無くなっていく)
// すでにfromとtoの駒は取られたはずなので消しておく。
Bitboard occupied = pieces() ^ from ^ to;
// すべてのattackerを列挙する。
Bitboard attackers = attackers_to(to, occupied) & occupied;
while (true)
{
stmAttackers = attackers & pieces(stm);
// pinnersが元の升にいる限りにおいては、pinされた駒から王以外への移動は許さない。
if (!(pinners(~stm) & occupied))
stmAttackers &= ~st->blockersForKing[stm];
// 手番側のtoに利いている駒がもうないなら、手番側の負けである。
if (!stmAttackers)
break;
// 次に価値の低い攻撃駒を調べて取り除く。
nextVictim = min_attacker(*this, to, stmAttackers, occupied, attackers);
stm = ~stm; // 相手番に
// Negamax the balance with alpha = balance, beta = balance+1 and
// add nextVictim's value.
//
// (balance, balance+1) -> (-balance-1, -balance)
//
ASSERT_LV3(balance < VALUE_ZERO);
balance = -balance - 1 - CapturePieceValue[nextVictim];
// もしbalanceがnextVictimを取り去っても依然として非負(0か正)であるなら、これをもって勝利である。
// ただし最後に玉が残って、相手側がまだattackerを持っているときはstmを反転しないといけないので注意。
if (balance >= VALUE_ZERO)
{
if (nextVictim == KING && (attackers & pieces(stm)))
stm = ~stm;
break;
}
ASSERT_LV3(nextVictim != KING);
}
return us != stm; // 上のループは、手番側のtoへの利きがある駒が尽きたときに抜ける
// min_attacker()はsee_ge()で使われるヘルパー関数であり、(目的升toに利く)
// 手番側の最も価値の低い攻撃駒の場所を特定し、その見つけた駒をビットボードから取り除き
// その背後にあった遠方駒をスキャンする。(あればstmAttackersに追加する)
// またこの関数はmin_attacker<PAWN>()として最初呼び出され、PAWNの攻撃駒がなければ次に
// KNIGHTの..というように徐々に攻撃駒をアップグレードしていく。
// occupied = 駒のある場所のbitboard。今回発見された駒は取り除かれる。
// stmAttackers = 手番側の攻撃駒
// attackers = toに利く駒(先後両方)。min_attacker(toに利く最小の攻撃駒)を見つけたら、その駒を除去して
// その影にいたtoに利く攻撃駒をattackersに追加する。
// uncapValue = 最後にこの駒が取れなかったときにこの駒が「成り」の指し手だった場合、その価値分の損失が
// 出るのでそれが返る。
// 返し値は今回発見されたtoに利く最小の攻撃駒。これがtoの地点において成れるなら成ったあとの駒を返すべき。
PieceType min_attacker(const Position& pos, const Square& to
, const Bitboard& stmAttackers, Bitboard& occupied, Bitboard& attackers
) {
// 駒種ごとのbitboardのうち、攻撃駒の候補を調べる
//: Bitboard b = stmAttackers & bb[Pt];
// 歩、香、桂、銀、金(金相当の駒)、角、飛、馬、龍…の順で取るのに使う駒を調べる。
// 金相当の駒については、細かくしたほうが良いかどうかは微妙。
Bitboard b;
b = stmAttackers & pos.pieces(PAWN); if (b) goto found;
b = stmAttackers & pos.pieces(LANCE); if (b) goto found;
b = stmAttackers & pos.pieces(KNIGHT); if (b) goto found;
b = stmAttackers & pos.pieces(SILVER); if (b) goto found;
b = stmAttackers & pos.pieces(GOLDS); if (b) goto found;
b = stmAttackers & pos.pieces(BISHOP); if (b) goto found;
b = stmAttackers & pos.pieces(ROOK); if (b) goto found;
b = stmAttackers & pos.pieces(HORSE); if (b) goto found;
b = stmAttackers & pos.pieces(DRAGON); if (b) goto found;
// 攻撃駒があるというのが前提条件だから、以上の駒で取れなければ、最後は玉でtoの升に移動出来て駒を取れるはず。
// 玉を移動させた結果、影になっていた遠方駒によってこの王が取られることはないから、
// sqに利く遠方駒が追加されることはなく、このままreturnすれば良い。
return KING;
found:;
// bにあった駒を取り除く
Square sq = b.pop();
occupied ^= sq;
// このときpinされているかの判定を入れられるなら入れたほうが良いのだが…。
// この攻撃駒の種類によって場合分け
// sqにあった駒が消えるので、toから見てsqの延長線上にある駒を追加する。
auto dirs = directions_of(to, sq);
if (dirs) switch(pop_directions(dirs))
{
// 斜め方向なら斜め方向の升をスキャンしてその上にある角・馬を足す
case DIRECT_RU: attackers |= rayEffect<DIRECT_RU>(to, occupied) & pos.pieces<BISHOP_HORSE>(); break;
case DIRECT_LD: attackers |= rayEffect<DIRECT_LD>(to, occupied) & pos.pieces<BISHOP_HORSE>(); break;
case DIRECT_RD: attackers |= rayEffect<DIRECT_RD>(to, occupied) & pos.pieces<BISHOP_HORSE>(); break;
case DIRECT_LU: attackers |= rayEffect<DIRECT_LU>(to, occupied) & pos.pieces<BISHOP_HORSE>(); break;
// 上方向に移動した時の背後の駒によってtoの地点に利くのは、後手の香 + 先後の飛車
case DIRECT_U : attackers |= rayEffect<DIRECT_U >(to, occupied) & (pos.pieces<ROOK_DRAGON>() | pos.pieces<WHITE, LANCE>()); break;
// 下方向に移動した時の背後の駒によってtoの地点に利くのは、先手の香 + 先後の飛車
case DIRECT_D : attackers |= rayEffect<DIRECT_D >(to, occupied) & (pos.pieces<ROOK_DRAGON>() | pos.pieces<BLACK, LANCE>()); break;
// 左右方向に移動した時の背後の駒によってtoの地点に利くのは、飛車・龍。
case DIRECT_L : attackers |= rayEffect<DIRECT_L> (to, occupied) & pos.pieces<ROOK_DRAGON>(); break;
case DIRECT_R : attackers |= rayEffect<DIRECT_R> (to, occupied) & pos.pieces<ROOK_DRAGON>(); break;
default: UNREACHABLE; break;
}
else {
// DIRECT_MISC
ASSERT_LV3(!(bishopStepEffect(to) & sq));
ASSERT_LV3(!((rookStepEffect(to) & sq)));
}
// toに利く攻撃駒は、occupiedのその升が1になっている駒に限定する。
// 処理した駒はoccupiedのその升が0になるので自動的に除外される。
attackers &= occupied;
// この駒が成れるなら、成りの値を返すほうが良いかも。
// ※ 最後にこの地点に残る駒を返すべきなのか。相手が取る/取らないを選択するので。
return type_of(pos.piece_on(sq));
}
} // namespace
-
skill level関連で、assertに引っかかってたの修正。
→ 落ちないけど全敗した。なんぞこれ。
V7.73s
-
Remove razoring history update. : https://github.com/official-stockfish/Stockfish/commit/1cb9afbdc04fbb864ee48babe56c1e88867d11e9 → すっきり
-
Simplifying two formulas : https://github.com/official-stockfish/Stockfish/commit/101d2bb8eae2c93c94013f56eae3af4faf8886f9 → 助かる
-
Update pawn history based on static eval difference : https://github.com/official-stockfish/Stockfish/commit/b4b704e6866bde21c69cd53457a6a91a15182b36 → pawn historyもともと採用していないので関係ない
-
Prefetch TT entries in probcut : https://github.com/official-stockfish/Stockfish/commit/e277dda7166992536124891e212d6d6a866f8a12 → 採用せず
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V773s_1024.exe , eval = Li T2,b1000,826 - 35 - 749(52.44% R17.0[2.59,31.41]) winrate black , white = 51.87% , 48.13% → 変わってなさげ。
engine1 = YaneuraOuNNUE_V773r_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V773s_1024.exe , eval = Li T2,b1000,758 - 55 - 707(51.74% R12.1[-2.84,27.04]) winrate black , white = 52.7% , 47.3% → 計測途中だが、計測する価値なさそうなので、中断。
V7.73r
-
Position::pinners[]を求める処理、修正。
-
Position::pinners()追加。
やねうらお — 今日 12:00 遡ってていくと、pinners[c]のcの意味を以下のStockfishのcommitの時点で私が勘違いして取り込んでいた。これにより、SEEの計算が間違うし、いままでずっと間違えていたのだが、しかしpinnerが絡むようなSEEは滅多に出てこないので棋力低下はほぼ見らなかったのだ。
それでこれを今回正しい感じに修正したから、benchの値が異なるというのが真相のようであった。
https://github.com/official-stockfish/Stockfish/commit/1f7ff8406d323e634a2aa1e1264042340707cdd9
あと、 // 王 歩 ^飛 ^飛 // のようなケースにおいては、この両方の飛車がpinnersとして列挙される。(SEEの処理でこういう列挙がなされて欲しいので) pinnersはこういう仕様になっている必要があるようであった。この点、私の理解が足りていなかった。修正した。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V773r_1024.exe , eval = Li T2,b1000,1550 - 101 - 1349(53.47% R24.13[13.49,34.77]) winrate black , white = 51.71% , 48.29% T2,b2000,1472 - 134 - 1264(53.8% R26.46[15.51,37.42]) winrate black , white = 52.6% , 47.4%
engine1 = YaneuraOuNNUE_V773q_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V773r_1024.exe , eval = Li T2,b1000,1480 - 110 - 1410(51.21% R8.42[-2.21,19.05]) winrate black , white = 49.79% , 50.21% T2,b2000,1329 - 117 - 1294(50.67% R4.64[-6.52,15.79]) winrate black , white = 49.87% , 50.13% → 弱なってる。SEEの処理の修正も必要なのでは…。
V7.73q2
-
Position.h/cppを今回の一連の改良前のバージョンに戻してみて比較。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V773q2_1024.exe , eval = Li T2,r300,624 - 30 - 596(51.15% R7.98[-8.38,24.34]) winrate black , white = 51.72% , 48.28% T2,b1000,1496 - 102 - 1402(51.62% R11.27[0.65,21.89]) winrate black , white = 50.66% , 49.34% T2,b1000,1488 - 102 - 1410(51.35% R9.35[-1.26,19.97]) winrate black , white = 52.73% , 47.27% T2,b2000,1444 - 141 - 1335(51.96% R13.63[2.79,24.48]) winrate black , white = 52.97% , 47.03%
engine1 = YaneuraOuNNUE_V773q2_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V771a_1024.exe , eval = Li T2,b1000,1396 - 95 - 1509(48.06% R-13.52[-24.13,-2.91]) winrate black , white = 50.88% , 49.12%
→ よくわからんので、benchとって比較する。
V7.73q
-
MVV/LVAのLVAの処理が間違っていたの修正。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V773q_1024.exe , eval = Li T2,b1000,1538 - 76 - 1386(52.6% R18.08[7.5,28.66]) winrate black , white = 50.82% , 49.18%
→ 計測できない差。
V7.73p2
- Limits.bench削除してビルド通らなくなっていたのを修正。
V7.73p
-
SkillLevelエンジンオプション削除。(使えてないので)
-
search.h / yaneuraou-search.cpp 、namespaceでインデント下げるのやめる。
-
LimitsType::bench削除。
-
CapturePieceValuePlusPromote() → namespace Evalに移動。
-
探索部のコメント、リンク先等の修正。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V773p_1024.exe , eval = Li T2,b1000,1528 - 101 - 1371(52.71% R18.83[8.21,29.46]) winrate black , white = 51.12% , 48.88%
V7.73o
-
quietの指し手、やっぱり64→32手にする。
-
探索パラメーター、調整後のやつに戻す。 → しかしparam1のほうがparam2よりいいのはなぜなのだ…。
-
MovePicker.cpp
- EVASION_ のように "_" を入れていたのを削る。
- capture() → capture_or_pawn_promotion()に変更する。
- MVV/LVAのLVAのコード掃除する。
- 歩の成りをcaptureとして扱う時のscoreのordering改良。
-
MovePicker.h、おかしいところがないかを見直す。 → なかった。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V773o_1024.exe , eval = Li T2,b1000,1507 - 104 - 1389(52.04% R14.16[3.54,24.79]) winrate black , white = 50.14% , 49.86% → 弱くはなってないので間違った修正はしてなさそう。
V7.73n
-
探索パラメーターをいったんすべて元(Stockfish16)に値に戻す。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V773n_1024.exe , eval = Li T2,b1000,1521 - 92 - 1387(52.3% R16.02[5.41,26.63]) winrate black , white = 51.44% , 48.56% → 少し弱いかも知れないが、ほぼ変わらんか…。
V7.73m2
-
quietの指し手、64手→32手に戻す。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V773m2_1024.exe , eval = Li T2,b1000,1484 - 88 - 1428(50.96% R6.68[-3.91,17.27]) winrate black , white = 51.51% , 48.49% → 32手のほうが若干強いな…。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V773m2_1024.exe , eval = Li T8,b1000,1215 - 142 - 1023(54.29% R29.88[17.76,42.0]) winrate black , white = 51.97% , 48.03% T8,b1000,1271 - 144 - 1135(52.83% R19.66[7.99,31.33]) winrate black , white = 53.37% , 46.63% T8,b1000,1261 - 135 - 1114(53.09% R21.53[9.79,33.28]) winrate black , white = 52.55% , 47.45%
V7.73m
- quietの指し手、32手→64手に戻す。
Stockfishの以下の変更、良くなかった気がする。
Move pv[MAX_PLY + 1], capturesSearched[32], quietsSearched[32];
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li
engine2 = YaneuraOuNNUE_V773m_1024.exe , eval = Li
T2,b1000,1489 - 107 - 1404(51.47% R10.21[-0.42,20.84]) winrate black , white = 52.3% , 47.7%
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503
engine2 = YaneuraOuNNUE_V773m_1024.exe , eval = suisho20230503
T2,b1000,1500 - 97 - 1403(51.67% R11.61[1.0,22.22]) winrate black , white = 53.12% , 46.88%
→ この状態でまだR10ほど弱いのか…。
V7.73l
-
現在の探索パラメーターで。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V773l_1024.exe , eval = Li T2,b1000,1517 - 107 - 1376(52.44% R16.95[6.31,27.58]) winrate black , white = 52.02% , 47.98% T2,b2000,1508 - 119 - 1373(52.34% R16.29[5.64,26.95]) winrate black , white = 50.95% , 49.05% T4,b2000,1499 - 175 - 1326(53.06% R21.3[10.53,32.07]) winrate black , white = 51.29% , 48.71% → あんま良くないか…。
→ よわなってへんか.. 調整ミスってそう..なんでなん…。なんかまだバグがある可能性が…? → 調整自体はできているようなのだが、どこかバグがあるのではないかと…。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V773l_1024.exe , eval = Li T2,b1000,1390 - 107 - 1503(48.05% R-13.58[-24.21,-2.95]) winrate black , white = 52.23% , 47.77%
#ifndef YANEURAOU_PARAM_H_INCLUDED
#define YANEURAOU_PARAM_H_INCLUDED
// yaneuraou-param.h : 元ファイル
// param_conv.pyというPythonのスクリプトにより、以下のファイルは自動生成されます。
// 1) yaneuraou - param - extern.h
// 2) yaneuraou - param - array.h
// 3) yaneuraou - param - string.h
// 1),2),3)のファイルは手で編集しないでください。
//#if defined(GENSFEN2019)
// 教師局面生成用のパラメーター
// 低depthで強くする ≒ 低depth時の枝刈りを甘くする。
//#include "yaneuraou-param_gen.h"
// → 教師生成時と学習時の探索部の性質が違うのはNNUE型にとってよくないようなのだが、
// これはたぶん許容範囲。
//#else
// パラメーターの説明に "fixed"と書いてあるパラメーターはランダムパラメーター化するときでも変化しない。
// 「前提depth」は、これ以上ならその枝刈りを適用する(かも)の意味。
// 「適用depth」は、これ以下ならその枝刈りを適用する(かも)の意味。
// 現在の値から、min~maxの範囲で、+step,-step,+0を試す。
// interval = 2だと、-2*step,-step,+0,+step,2*stepの5つを試す。
// Reductionsテーブルの初期化用
// 重要度 ★★★★★
// 前のバージョンの値 = 2057
// 元の値 = 2037 ,step = 8
// [PARAM] min:1500,max:2500,step:1,interval:2,time_rate:1,
PARAM_DEFINE PARAM_REDUCTIONS_PARAM1 = 2035;
// Reductionの計算式に出てくる定数
// 重要度 ★★★★☆
// 元の値 = 1487 ,step = 128
// [PARAM] min:0,max:2048,step:64,interval:2,time_rate:1,
PARAM_DEFINE PARAM_REDUCTION_ALPHA = 1615;
// Reductionの計算式に出てくる定数
// 重要度 ★★★★☆
// 元の値 = 808 , step = 128
// [PARAM] min:300,max:1500,step:64,interval:2,time_rate:1,
PARAM_DEFINE PARAM_REDUCTION_BETA = 552;
// Reductionの計算式に出てくる定数
// 重要度 ★★★★☆
// 元の値 = 976 , step = 128
// [PARAM] min:300,max:1500,step:32,interval:2,time_rate:1,
PARAM_DEFINE PARAM_REDUCTION_GAMMA = 976;
//
// futility pruning
//
// 深さに比例したfutility pruning
// 重要度 ★★★★☆
// 元の値 = 125 , step = 20
// [PARAM] min:100,max:300,step:5,interval:2,time_rate:1,
PARAM_DEFINE PARAM_FUTILITY_MARGIN_ALPHA1 = 125;
// 重要度 ★★★★☆
// 元の値 = 43 , step = 10
// [PARAM] min:10,max:200,step:2,interval:2,time_rate:1,
PARAM_DEFINE PARAM_FUTILITY_MARGIN_ALPHA2 = 38;
// 重要度 ★★★★☆
// 元の値 = 138 , step = 30
// [PARAM] min:100,max:240,step:5,interval:2,time_rate:1,
PARAM_DEFINE PARAM_FUTILITY_MARGIN_BETA = 100;
// 静止探索でのfutility pruning
// 重要度 ★★★★☆
// 1つ前のバージョンの値 = 118。
// 元の値 = 200 , step = 10
// [PARAM] min:50,max:300,step:10,interval:2,time_rate:1,
PARAM_DEFINE PARAM_FUTILITY_MARGIN_QUIET = 200;
// futility pruningの適用depth。
// 重要度 ★★★☆☆
// この制限自体が要らない可能性がある。→ そうでもなかった。→こんなdepthいじらんほうがマシ
// 元の値 = 9 , step = 1
// [PARAM] min:5,max:15,step:1,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_FUTILITY_RETURN_DEPTH = 9;
// 親nodeでのfutilityの適用depth。
// 重要度 ★★★☆☆
// この枝刈り、depthの制限自体が要らないような気がする。→ そうでもなかった。→こんなdepthいじらんほうがマシ
// 元の値 = 13
// [PARAM] min:5,max:20,step:1,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_FUTILITY_AT_PARENT_NODE_DEPTH = 13;
// 親nodeでのfutility margin
// 重要度 ★★★★☆
// 元の値 = 77 , step = 10
// [PARAM] min:30,max:400,step:5,interval:2,time_rate:1,
PARAM_DEFINE PARAM_FUTILITY_AT_PARENT_NODE_MARGIN1 = 67;
// 重要度 ★★★☆☆
// 元の値 = 124 , step = 10
// [PARAM] min:100,max:400,step:1,interval:2,time_rate:1,
PARAM_DEFINE PARAM_FUTILITY_AT_PARENT_NODE_ALPHA = 122;
// 重要度 ★★★★☆
// 元の値 = 26 , step = 2
// [PARAM] min:15,max:50,step:1,interval:1,time_rate:1,
PARAM_DEFINE PARAM_FUTILITY_AT_PARENT_NODE_GAMMA1 = 27;
// lmrのときのseeの値。
// 重要度 ★★★★☆
// 元の値 = 185 ,step = 40
// [PARAM] min:0,max:300,step:5,interval:2,time_rate:1,
PARAM_DEFINE PARAM_LMR_SEE_MARGIN1 = 215;
//
// null move dynamic pruning
//
// 重要度 ★★★☆☆
// 元の値 = 152 , step = 10
// [PARAM] min:50,max:400,step:3,interval:2,time_rate:1,
PARAM_DEFINE PARAM_NULL_MOVE_DYNAMIC_GAMMA = 152;
// 重要度 ★★★☆☆
// 元の値 = 24 , step = 2
// Stockfishの前バージョンではこの値は15。
// [PARAM] min:10,max:60,step:1,interval:2,time_rate:1,
PARAM_DEFINE PARAM_NULL_MOVE_MARGIN1 = 20;
// 元の値 = 281 , step = 50
// 重要度 ★★★☆☆
// Stockfishの前バージョンではこの値は198。
// [PARAM] min:0,max:400,step:5,interval:2,time_rate:1,
PARAM_DEFINE PARAM_NULL_MOVE_MARGIN4 = 281;
// null moveでbeta値を上回ったときに、これ以下ならreturnするdepth。適用depth。
// 重要度 ★★★☆☆
// 元の値 = 14
// 他のNULL_MOVEの値が悪いと、この枝刈りを適用しないほうが強くなるわけで、
// このdepthがどんどん高い値に発散してしまうので注意。
// この値は、低くなるのが正しいチューニングだと思う。
// [PARAM] min:4,max:20,step:1,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_NULL_MOVE_RETURN_DEPTH = 14;
//
// ProbCut
//
// probcutのmargin
// 重要度 ★★★☆☆
// 式 = beta + PARAM_PROBCUT_MARGIN1 - improving * PARAM_PROBCUT_MARGIN2
// improvingの効果怪しいので抑え気味にしておく。
// 元の値 = 168 , step = 20
// [PARAM] min:100,max:300,step:5,interval:2,time_rate:1,
PARAM_DEFINE PARAM_PROBCUT_MARGIN1 = 183;
// 元の値 = 70 , step = 10
// 重要度 ★★★☆☆
// [PARAM] min:20,max:100,step:1,interval:2,time_rate:1,
PARAM_DEFINE PARAM_PROBCUT_MARGIN2 = 70;
// 前のバージョンのStockfishではこの値は481。
// 重要度 ★★★☆☆
// 元の値 = 416 , step = 10
// [PARAM] min:20,max:500,step:4,interval:2,time_rate:1,
PARAM_DEFINE PARAM_PROBCUT_MARGIN3 = 408;
//
// singular extension
//
// singular extensionのsingular betaを計算するときのマージン
// 重要度 ★★★★☆
// 元の値 = 64 , step = 8
// [PARAM] min:0,max:1024,step:8,interval:2,time_rate:1,
PARAM_DEFINE PARAM_SINGULAR_MARGIN1 = 64;
// singular extensionのsingular betaを計算するときの係数
// 重要度 ★★★★☆
// 自己対局だとすごく強くなって見えるかもしれないが、まやかしである。
// 元の値 = 57 , step = 8
// [PARAM] min:0,max:1024,step:4,interval:2,time_rate:1,
PARAM_DEFINE PARAM_SINGULAR_MARGIN2 = 49;
//
// LMR
//
// LMRのパラメーター
// 重要度 ★★★★☆
// 元の値 = 51 , step = 4
// [PARAM] min:0,max:128,step:1,interval:1,time_rate:1,
PARAM_DEFINE PARAM_LMR_MARGIN1 = 53;
// 重要度 ★★☆☆☆
// → 重要なパラメーターではあるが、下手にいじらないほうがよさげ。
// 元の値 = 10 , step = 1
// [PARAM] min:0,max:128,step:1,interval:1,time_rate:1,
PARAM_DEFINE PARAM_LMR_MARGIN2 = 11;
// 重要度 ★★★☆☆
// 元の値 = 700 , step = 100
// [PARAM] min:0,max:1024,step:4,interval:2,time_rate:1,
PARAM_DEFINE PARAM_LMR_MARGIN3 = 700;
//
// pruning by history
//
// historyによる枝刈りをする深さ。適用depth。
// 重要度 ★★★☆☆
// 元の値 = 6 , step = 1
// [PARAM] min:2,max:16,step:1,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_PRUNING_BY_HISTORY_DEPTH = 6;
// update_all_stats()で、静止探索時のquietMoveとみなすbestvalueとbetaの差(PawnValueより少し小さな値)
// StockfishではPawnValueが210ぐらいなので、それを考慮すること。
// 重要度 ★★★☆☆
// 元の値 = 168 , step = 30
// [PARAM] min:10,max:200,step:5,interval:2,time_rate:1,
PARAM_DEFINE PARAM_UPDATE_ALL_STATS_EVAL_TH = 80;
//
// misc
//
// fail lowを引き起こしたcounter moveにbonus与える時のevalのmargin値。
// 重要度 ★★★☆☆
// 元の値 = 657 , step = 50
// [PARAM] min:10,max:1000,step:5,interval:2,time_rate:1,
PARAM_DEFINE PARAM_COUNTERMOVE_FAILLOW_MARGIN = 677;
// aspiration searchの増加量。
// 重要度 ★★☆☆☆
// → 調整が難しいパラメーター。下手にいじらないほうがよさげ。
// 古い評価関数では20ぐらいがベストだったが、NNUEでは17がベストのようだ。評価関数の精度向上とともに徐々に小さくなってきている。
// 元の値 = 10 , step = 1
// [PARAM] min:5,max:30,step:1,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_ASPIRATION_SEARCH_DELTA = 10;
// qsearch()でnull moveのときもevaluate()を呼び出す。
// 重要度 ★☆☆☆☆
// この値が0(false)ならば、null moveのときはeval = 前局面にEval::Tempoを加算した値 とする。
// 計測できる差にならない。
// PARAM_EVAL_TEMPOを変動させていると(適正値から離れていると)、
// evaluate()を呼び出したほうが良いことになってしまうのでこれが1のときのほうが良いことになってしまうので注意。
// 元の値 = 0 , step = 1
// [PARAM] min:0,max:1,step:1,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_QSEARCH_FORCE_EVAL = 0;
//
// mate..
//
// 静止探索での1手詰め
// 重要度 ★★☆☆☆
// 元の値 = 1
// → 1スレ2秒で対技巧だと有りのほうが強かったので固定しておく。
// NNUEだと、これ無しのほうが良い可能性がある。
// いったん無しでやって最後に有りに変更して有効か見る。
// 2スレ1,2秒程度だと無しと有意差がなかったが、4秒~8秒では、有りのほうが+R30ぐらい強い。
// [PARAM] min:0,max:1,step:1,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_QSEARCH_MATE1 = 1;
// 通常探索での1手詰め
// 重要度 ★★☆☆☆
// → よくわからないが1スレ2秒で対技巧だと無しのほうが強かった。
// 1スレ3秒にすると有りのほうが強かった。やはり有りのほうが良いのでは..
// 元の値 = 1
// [PARAM] min:0,max:1,step:1,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_SEARCH_MATE1 = 1;
// 1手詰めではなくN手詰めを用いる
// 重要度 ★★☆☆☆
// ※ 3手,5手はコストに見合わないようだ。
// 元の値 = 1
// [PARAM] min:1,max:5,step:2,interval:1,time_rate:1,fixed
PARAM_DEFINE PARAM_WEAK_MATE_PLY = 1;
//
// move picker
//
// MovePickerの quietのvalue計算用の係数
// 注意 : この調整をONにするためには movepick.cpp の
// 以下の変数を使ってあるところの #if を有効化("#if 1"を"#if 0"に変更)
// する必要がある。
// → すべて掃除されてなくなった
// ABテスト用
// 重要度 ★☆☆☆☆
// [PARAM] min:0,max:1,step:1,interval:1,time_rate:1,fixed
PARAM_DEFINE AB_TEST1 = 1;
// ABテスト用
// 重要度 ★☆☆☆☆
// [PARAM] min:0,max:1,step:1,interval:1,time_rate:1,fixed
PARAM_DEFINE AB_TEST2 = 1;
//#endif // defined(GENSFEN2019)
#endif
V7.73param2
total : 5529 - 387 - 6084(47.61% R-16.62)
total : 5529 - 387 - 6084(47.61% R-16.62)
PARAM_REDUCTIONS_PARAM1:
2035 : 1143 - 83 - 1207(48.64% R-9.46)
2037 : 1107 - 84 - 1217(47.63% R-16.46)
2039 : 1085 - 54 - 1247(46.53% R-24.17)
2041 : 1086 - 98 - 1201(47.49% R-17.49)
2043 : 1108 - 68 - 1212(47.76% R-15.59)
PARAM_REDUCTION_ALPHA:
1231 : 1077 - 65 - 1244(46.4% R-25.04)
1359 : 1101 - 82 - 1205(47.75% R-15.68)
1487 : 1115 - 77 - 1275(46.65% R-23.29)
1615 : 1122 - 73 - 1176(48.83% R-8.17)
1743 : 1114 - 90 - 1184(48.48% R-10.59)
PARAM_REDUCTION_BETA:
552 : 1167 - 65 - 1180(49.72% R-1.92)
680 : 1120 - 77 - 1168(48.95% R-7.29)
808 : 1082 - 79 - 1305(45.33% R-32.55)
936 : 1073 - 86 - 1219(46.82% R-22.16)
1064 : 1087 - 80 - 1212(47.28% R-18.91)
PARAM_REDUCTION_GAMMA:
720 : 1119 - 61 - 1210(48.05% R-13.58)
848 : 1108 - 91 - 1205(47.9% R-14.58)
976 : 1144 - 87 - 1208(48.64% R-9.46)
1104 : 1070 - 71 - 1203(47.07% R-20.35)
1232 : 1088 - 77 - 1258(46.38% R-25.22)
PARAM_FUTILITY_MARGIN_ALPHA1:
105 : 1055 - 80 - 1196(46.87% R-21.79)
110 : 1107 - 89 - 1287(46.24% R-26.17)
115 : 1141 - 80 - 1228(48.16% R-12.77)
120 : 1094 - 48 - 1194(47.81% R-15.19)
125 : 1132 - 90 - 1179(48.98% R-7.07)
PARAM_FUTILITY_MARGIN_ALPHA2:
33 : 1072 - 81 - 1179(47.62% R-16.53)
38 : 1100 - 71 - 1186(48.12% R-13.08)
43 : 1109 - 101 - 1221(47.6% R-16.71)
48 : 1177 - 65 - 1284(47.83% R-15.12)
53 : 1071 - 69 - 1214(46.87% R-21.77)
PARAM_FUTILITY_MARGIN_BETA:
100 : 1115 - 70 - 1181(48.56% R-9.99)
108 : 1115 - 80 - 1235(47.45% R-17.76)
138 : 1121 - 86 - 1233(47.62% R-16.54)
168 : 1127 - 77 - 1266(47.1% R-20.2)
198 : 1051 - 74 - 1169(47.34% R-18.48)
PARAM_FUTILITY_MARGIN_QUIET:
160 : 1059 - 76 - 1205(46.78% R-22.44)
180 : 1156 - 93 - 1234(48.37% R-11.34)
200 : 1072 - 78 - 1182(47.56% R-16.97)
220 : 1127 - 60 - 1212(48.18% R-12.63)
240 : 1115 - 80 - 1251(47.13% R-19.99)
PARAM_FUTILITY_AT_PARENT_NODE_MARGIN1:
57 : 1113 - 73 - 1180(48.54% R-10.15)
67 : 1110 - 79 - 1149(49.14% R-6.0)
77 : 1098 - 89 - 1241(46.94% R-21.27)
87 : 1112 - 67 - 1289(46.31% R-25.66)
97 : 1096 - 79 - 1225(47.22% R-19.33)
PARAM_FUTILITY_AT_PARENT_NODE_ALPHA:
120 : 1125 - 63 - 1195(48.49% R-10.49)
122 : 1135 - 73 - 1171(49.22% R-5.42)
124 : 1058 - 83 - 1228(46.28% R-25.89)
126 : 1114 - 88 - 1211(47.91% R-14.5)
128 : 1097 - 80 - 1279(46.17% R-26.67)
PARAM_FUTILITY_AT_PARENT_NODE_GAMMA1:
25 : 1792 - 127 - 2078(46.3% R-25.72)
26 : 1865 - 144 - 2023(47.97% R-14.13)
27 : 1872 - 116 - 1983(48.56% R-10.01)
PARAM_LMR_SEE_MARGIN1:
195 : 1113 - 71 - 1252(47.06% R-20.44)
205 : 1081 - 87 - 1205(47.29% R-18.86)
215 : 1112 - 71 - 1189(48.33% R-11.63)
225 : 1100 - 69 - 1193(47.97% R-14.1)
235 : 1123 - 89 - 1245(47.42% R-17.92)
PARAM_NULL_MOVE_DYNAMIC_GAMMA:
146 : 1092 - 77 - 1218(47.27% R-18.97)
149 : 1126 - 77 - 1214(48.12% R-13.07)
152 : 1059 - 75 - 1173(47.45% R-17.76)
155 : 1099 - 89 - 1253(46.73% R-22.78)
158 : 1153 - 69 - 1226(48.47% R-10.66)
PARAM_NULL_MOVE_MARGIN1:
17 : 1048 - 80 - 1227(46.07% R-27.39)
19 : 1111 - 74 - 1166(48.79% R-8.39)
21 : 1105 - 77 - 1227(47.38% R-18.19)
23 : 1119 - 76 - 1232(47.6% R-16.71)
25 : 1146 - 80 - 1232(48.19% R-12.57)
PARAM_NULL_MOVE_MARGIN4:
251 : 1045 - 66 - 1174(47.09% R-20.22)
266 : 1132 - 92 - 1258(47.36% R-18.33)
281 : 1125 - 90 - 1177(48.87% R-7.85)
296 : 1077 - 62 - 1260(46.08% R-27.26)
311 : 1150 - 77 - 1215(48.63% R-9.55)
PARAM_PROBCUT_MARGIN1:
168 : 1105 - 85 - 1278(46.37% R-25.27)
173 : 1040 - 75 - 1162(47.23% R-19.27)
178 : 1107 - 78 - 1231(47.35% R-18.44)
183 : 1156 - 78 - 1187(49.34% R-4.6)
188 : 1121 - 71 - 1226(47.76% R-15.55)
PARAM_PROBCUT_MARGIN2:
66 : 1068 - 78 - 1218(46.72% R-22.83)
68 : 1176 - 71 - 1227(48.94% R-7.37)
70 : 1091 - 81 - 1212(47.37% R-18.27)
72 : 1096 - 73 - 1171(48.35% R-11.5)
74 : 1098 - 84 - 1256(46.64% R-23.35)
PARAM_PROBCUT_MARGIN3:
400 : 1091 - 71 - 1224(47.13% R-19.98)
408 : 1101 - 80 - 1163(48.63% R-9.52)
416 : 1098 - 84 - 1258(46.6% R-23.63)
424 : 1090 - 68 - 1229(47.0% R-20.85)
432 : 1149 - 84 - 1210(48.71% R-8.99)
PARAM_SINGULAR_MARGIN1:
48 : 1057 - 88 - 1203(46.77% R-22.48)
56 : 1086 - 60 - 1231(46.87% R-21.77)
64 : 1112 - 71 - 1169(48.75% R-8.68)
72 : 1151 - 71 - 1190(49.17% R-5.79)
80 : 1123 - 97 - 1291(46.52% R-24.22)
PARAM_SINGULAR_MARGIN2:
41 : 1104 - 75 - 1223(47.44% R-17.78)
45 : 1088 - 82 - 1226(47.02% R-20.74)
49 : 1112 - 65 - 1220(47.68% R-16.1)
53 : 1115 - 88 - 1221(47.73% R-15.78)
57 : 1110 - 77 - 1194(48.18% R-12.67)
PARAM_LMR_MARGIN1:
49 : 1098 - 71 - 1200(47.78% R-15.43)
50 : 1093 - 70 - 1221(47.23% R-19.24)
51 : 1102 - 76 - 1256(46.73% R-22.72)
52 : 1128 - 87 - 1240(47.64% R-16.45)
53 : 1108 - 83 - 1167(48.7% R-9.01)
PARAM_LMR_MARGIN2:
10 : 1849 - 121 - 2000(48.04% R-13.64)
11 : 1868 - 144 - 2094(47.15% R-19.84)
12 : 1812 - 122 - 1990(47.66% R-16.28)
PARAM_LMR_MARGIN3:
676 : 1136 - 82 - 1259(47.43% R-17.86)
688 : 1070 - 73 - 1223(46.66% R-23.22)
700 : 1142 - 79 - 1199(48.78% R-8.46)
712 : 1108 - 84 - 1232(47.35% R-18.43)
724 : 1073 - 69 - 1171(47.82% R-15.18)
PARAM_UPDATE_ALL_STATS_EVAL_TH:
80 : 1113 - 87 - 1183(48.48% R-10.6)
85 : 1090 - 68 - 1202(47.56% R-16.99)
90 : 1115 - 88 - 1277(46.61% R-23.57)
95 : 1129 - 65 - 1234(47.78% R-15.45)
100 : 1082 - 79 - 1188(47.67% R-16.24)
PARAM_COUNTERMOVE_FAILLOW_MARGIN:
637 : 1079 - 61 - 1208(47.18% R-19.62)
647 : 1125 - 66 - 1226(47.85% R-14.94)
657 : 1082 - 94 - 1159(48.28% R-11.94)
667 : 1096 - 80 - 1291(45.92% R-28.45)
677 : 1147 - 86 - 1200(48.87% R-7.85)
V7.73k
- Introduce asymmetric optimism : https://github.com/official-stockfish/Stockfish/commit/908811c24ab53d2cb1bebc1138427e21fefa8054
V7.73param1
total : 5336 - 372 - 5615(48.73% R-8.85)
total : 5336 - 372 - 5615(48.73% R-8.85)
PARAM_REDUCTIONS_PARAM1:
2033 : 1056 - 79 - 1143(48.02% R-13.75)
2035 : 1024 - 80 - 1124(47.67% R-16.19)
2037 : 1070 - 67 - 1103(49.24% R-5.28)
2039 : 1083 - 64 - 1145(48.61% R-9.67) ✔
2041 : 1103 - 82 - 1100(50.07% R0.47)
PARAM_REDUCTION_ALPHA:
1231 : 1092 - 79 - 1125(49.26% R-5.17)
1359 : 1047 - 79 - 1164(47.35% R-18.4)
1487 : 1060 - 66 - 1126(48.49% R-10.49) ようわからん
1615 : 1034 - 82 - 1140(47.56% R-16.95)
1743 : 1103 - 66 - 1060(50.99% R6.91)
PARAM_REDUCTION_BETA:
552 : 1076 - 67 - 1125(48.89% R-7.74)
680 : 1092 - 76 - 1124(49.28% R-5.02)
808 : 1016 - 70 - 1106(47.88% R-14.74) ようわからん
936 : 1080 - 60 - 1177(47.85% R-14.94)
1064 : 1072 - 99 - 1083(49.74% R-1.77)
PARAM_REDUCTION_GAMMA:
720 : 1049 - 59 - 1134(48.05% R-13.54)
848 : 1060 - 76 - 1112(48.8% R-8.32)
976 : 1114 - 82 - 1122(49.82% R-1.24)
1104 : 1054 - 86 - 1142(48.0% R-13.93)
1232 : 1059 - 69 - 1105(48.94% R-7.39)
PARAM_FUTILITY_MARGIN_ALPHA1:
105 : 1014 - 78 - 1098(48.01% R-13.83)
115 : 1117 - 80 - 1099(50.41% R2.82) ✔
125 : 1070 - 73 - 1100(49.31% R-4.8)
135 : 1049 - 73 - 1169(47.29% R-18.82)
145 : 1086 - 68 - 1149(48.59% R-9.8)
PARAM_FUTILITY_MARGIN_ALPHA2:
33 : 1078 - 72 - 1126(48.91% R-7.57)
38 : 1036 - 81 - 1110(48.28% R-11.99)
43 : 1083 - 64 - 1138(48.76% R-8.61)
48 : 1087 - 80 - 1097(49.77% R-1.59)
53 : 1052 - 75 - 1144(47.91% R-14.56)
PARAM_FUTILITY_MARGIN_BETA:
100 : 1066 - 77 - 1100(49.22% R-5.45)
108 : 1097 - 76 - 1124(49.39% R-4.22)
138 : 1054 - 66 - 1161(47.58% R-16.8)
168 : 1063 - 78 - 1103(49.08% R-6.42)
198 : 1056 - 75 - 1127(48.37% R-11.3)
PARAM_FUTILITY_MARGIN_QUIET:
160 : 1082 - 70 - 1101(49.56% R-3.02)
180 : 1089 - 83 - 1118(49.34% R-4.57)
200 : 1013 - 82 - 1109(47.74% R-15.73)
220 : 1079 - 66 - 1170(47.98% R-14.07)
240 : 1073 - 71 - 1117(49.0% R-6.98)
PARAM_FUTILITY_AT_PARENT_NODE_MARGIN1:
57 : 1102 - 61 - 1150(48.93% R-7.41)
67 : 1056 - 86 - 1105(48.87% R-7.88)
77 : 1056 - 74 - 1119(48.55% R-10.07)
87 : 1047 - 69 - 1153(47.59% R-16.75)
97 : 1075 - 82 - 1088(49.7% R-2.09)
PARAM_FUTILITY_AT_PARENT_NODE_ALPHA:
114 : 1033 - 85 - 1095(48.54% R-10.13)
119 : 1091 - 63 - 1145(48.79% R-8.39)
124 : 1072 - 75 - 1118(48.95% R-7.3) step = 2
129 : 1083 - 84 - 1113(49.32% R-4.75)
134 : 1057 - 65 - 1144(48.02% R-13.74)
PARAM_FUTILITY_AT_PARENT_NODE_GAMMA1:
24 : 1061 - 75 - 1129(48.45% R-10.79)
25 : 1079 - 84 - 1132(48.8% R-8.33)
26 : 1060 - 74 - 1113(48.78% R-8.48) interval = 1
27 : 1049 - 62 - 1096(48.9% R-7.61)
28 : 1087 - 77 - 1145(48.7% R-9.03)
PARAM_LMR_SEE_MARGIN1:
195 : 1096 - 78 - 1100(49.91% R-0.63)
205 : 1047 - 80 - 1153(47.59% R-16.75)
215 : 1070 - 59 - 1120(48.86% R-7.93)
225 : 1125 - 80 - 1133(49.82% R-1.23)
235 : 998 - 75 - 1109(47.37% R-18.32)
PARAM_NULL_MOVE_DYNAMIC_GAMMA:
142 : 1078 - 87 - 1092(49.68% R-2.24)
147 : 1085 - 68 - 1120(49.21% R-5.52)
152 : 1104 - 73 - 1122(49.6% R-2.81) step = 3
157 : 1078 - 69 - 1106(49.36% R-4.45)
162 : 991 - 75 - 1175(45.75% R-29.59)
PARAM_NULL_MOVE_MARGIN1:
22 : 1072 - 57 - 1142(48.42% R-10.99) 21 , step = 2 // 前の値が15だから。
23 : 1039 - 71 - 1129(47.92% R-14.43)
24 : 1060 - 77 - 1109(48.87% R-7.85)
25 : 1144 - 80 - 1095(51.09% R7.6)
26 : 1021 - 87 - 1140(47.25% R-19.15)
PARAM_NULL_MOVE_MARGIN4:
230 : 1102 - 66 - 1087(50.34% R2.38)
243 : 1061 - 82 - 1152(47.94% R-14.29)
256 : 1058 - 76 - 1155(47.81% R-15.24)
269 : 1033 - 67 - 1123(47.91% R-14.51)
282 : 1082 - 81 - 1098(49.63% R-2.55) ✔ 元の値が281だから。
PARAM_PROBCUT_MARGIN1:
163 : 1050 - 76 - 1152(47.68% R-16.11)
173 : 1083 - 67 - 1109(49.41% R-4.12)
183 : 1067 - 74 - 1055(50.28% R1.96)
193 : 1024 - 68 - 1182(46.42% R-24.93)
203 : 1112 - 87 - 1117(49.89% R-0.78)
PARAM_PROBCUT_MARGIN2:
64 : 1056 - 54 - 1096(49.07% R-6.46)
66 : 1092 - 80 - 1163(48.43% R-10.94)
68 : 1062 - 87 - 1158(47.84% R-15.03)
70 : 1053 - 81 - 1107(48.75% R-8.69) ✔ 元の値が70なので
72 : 1073 - 70 - 1091(49.58% R-2.89)
PARAM_PROBCUT_MARGIN3:
400 : 1059 - 81 - 1180(47.3% R-18.79)
408 : 1072 - 67 - 1086(49.68% R-2.25)
416 : 1067 - 72 - 1138(48.39% R-11.19)
424 : 1050 - 79 - 1133(48.1% R-13.22)
432 : 1088 - 73 - 1078(50.23% R1.6)
PARAM_SINGULAR_MARGIN1:
48 : 1041 - 78 - 1094(48.76% R-8.63)
56 : 1057 - 71 - 1131(48.31% R-11.76)
64 : 1042 - 81 - 1120(48.2% R-12.54)
72 : 1117 - 77 - 1133(49.64% R-2.47)
80 : 1079 - 65 - 1137(48.69% R-9.1)
PARAM_SINGULAR_MARGIN2:
37 : 1030 - 69 - 1172(46.78% R-22.44)
41 : 1143 - 78 - 1093(51.12% R7.77)
45 : 1033 - 75 - 1109(48.23% R-12.33)
49 : 1081 - 78 - 1100(49.56% R-3.03)
53 : 1049 - 72 - 1141(47.9% R-14.6)
PARAM_LMR_MARGIN1:
47 : 1081 - 70 - 1126(48.98% R-7.09)
49 : 1068 - 93 - 1076(49.81% R-1.3)
51 : 1078 - 67 - 1111(49.25% R-5.24) , step = 1
53 : 1095 - 67 - 1136(49.08% R-6.39)
55 : 1014 - 75 - 1166(46.51% R-24.26)
PARAM_LMR_MARGIN2:
11 : 1097 - 83 - 1123(49.41% R-4.07) ✔ 元の値が10なので..
12 : 1088 - 67 - 1095(49.84% R-1.11)
13 : 1007 - 77 - 1135(47.01% R-20.79)
14 : 1081 - 72 - 1122(49.07% R-6.47)
15 : 1063 - 73 - 1140(48.25% R-12.15)
PARAM_LMR_MARGIN3:
650 : 1032 - 80 - 1091(48.61% R-9.66)
675 : 1071 - 65 - 1138(48.48% R-10.54)
700 : 1101 - 86 - 1164(48.61% R-9.67) ✔ step = 12
725 : 1067 - 63 - 1101(49.22% R-5.45)
750 : 1065 - 78 - 1121(48.72% R-8.9)
PARAM_UPDATE_ALL_STATS_EVAL_TH:
70 : 1064 - 60 - 1132(48.45% R-10.76)
80 : 1048 - 81 - 1109(48.59% R-9.83)
90 : 1081 - 85 - 1105(49.45% R-3.81) , step = 5
100 : 1106 - 64 - 1129(49.49% R-3.58)
110 : 1037 - 82 - 1140(47.63% R-16.45)
PARAM_COUNTERMOVE_FAILLOW_MARGIN:
627 : 1086 - 92 - 1081(50.12% R0.8)
642 : 1081 - 84 - 1146(48.54% R-10.14)
657 : 1053 - 68 - 1092(49.09% R-6.32) , step = 10に。
672 : 1074 - 73 - 1167(47.93% R-14.43)
687 : 1042 - 55 - 1129(48.0% R-13.93)
V7.73j
-
bench 1スレdepth指定で毎回探索ノード数が異なる件、修正。
やねうらお — 今日 07:24 benchコマンドで探索node数が一致しない原因が一瞬で判明した。
なんと、PV出力の時に局面を進めるためにdo_moveしているのだが、それによりnode数が加算されてるからであった。benchコマンドでは 置換表を漁らないようにするなどの対策が必要であることがわかった。
-
bench 1スレdepth指定で毎回探索ノード数が異なる件 → 要調査 bench 1024 1 18 default depth
-
ベンチを取るごとにnode数が変わる原因調査。 → なんか知らん間に解決してた。どこの修正で解決したのかはわからん…。 bench 1024 1 24 default depth
=========================== Total time (ms) : 122007 Nodes searched : 143252293 Nodes_searched/second : 1174131
→ わずかに一致してない。やはり未初期化のテーブルが何かしら存在する。 もうちょっと簡単に発生する条件がないか? → V7.71aの段階でこの現象起きるやん…。なんぞこれ…。
bench 1024 1 20 default depth
=========================== Total time (ms) : 21791 Nodes searched : 24632346 Nodes_searched/second : 1130390
Total time (ms) : 21258 Nodes searched : 24632330 Nodes_searched/second : 1158732 =========================== 連続bench Total time (ms) : 18721 Nodes searched : 22207412 Nodes_searched/second : 1186230
→ もしかしてPV出力のためのhashのprobeが影響してるのか?
やねうらお — 今日 07:04 ・PawnKey導入 → 再度調整して棋力計測する ・今回の一連の更新で、著しく棋力が低下したcommitを二分探索で特定 → 完了。 ・まだ取り込んでないStockfishのcommitを取り込む : → 完了 ・benchで1スレ固定depthで探索ノード数が変わる件調査 → まだ ・探索パラメーターの調整 → やりなおし
あと ・null moveの時にNNUEの計算端折れる件、調査する。 ・やねうら王のGitHubのCIでコケてる件、調査。(やりたくない) ・探索部の改良のアイデア思いついたので試す。 ・AVX512用のbuild、調査する。 そこまで終わったらやねうら王はV8.00になるだす🤤 (あと2週間ぐらいかかりそう…)
V7.73i
- super sort実施の条件を調整する。
- ただし、ビルドオプションで無効化したまま。
V7.73h2
-
super sortで特定条件だけsortかけてみる。以下の条件ならそこまで悪くはないはずだが…。
// depth大きくて指し手の数も多い時だけsuper sortを使うとどう? if ((depth >= 15 && endMoves - cur >= 32) || (depth >= 10 && endMoves - cur >= 64) || (depth >= 5 && endMoves - cur >= 96) ) partial_super_sort(cur, endMoves , -3000 * depth); else partial_insertion_sort(cur, endMoves, -3000 * depth); engine1 = YaneuraOuNNUE_V773h_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V773h2_1024.exe , eval = Li T2,b1000,1386 - 86 - 1528(47.56% R-16.94[-27.54,-6.35]) winrate black , white = 52.09% , 47.91% → やはりsupersort、うまく使えば速いっぽいな…。条件調整するか…。 engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V773h2_1024.exe , eval = Li T2,b1000,1438 - 90 - 1472(49.42% R-4.06[-14.65,6.53]) winrate black , white = 52.37% , 47.63% → h2でやっと元のと互角ぐらいか…これはつらい。 engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V773h2_1024.exe , eval = suisho20230503 T2,b1000,1542 - 89 - 1369(52.97% R20.67[10.06,31.28]) winrate black , white = 51.87% , 48.13% → 水匠だとなんか裏目に出てるんやろか…。まだ互角にならん。 engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V773h2_1024.exe , eval = Li T2,b2000,1524 - 131 - 1345(53.12% R21.71[11.02,32.39]) winrate black , white = 52.25% , 47.75% → Liでも裏目に出てるのか…。なんなんやろな、これ。2秒だからか。そういや2秒の計測してなかったな…。 engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V773h2_1024.exe , eval = suisho20230503 T2,b2000,1471 - 124 - 1405(51.15% R7.97[-2.68,18.63]) winrate black , white = 52.29% , 47.71% → 水匠だと裏目には出てないが、改善効果が薄いな…。
V7.73h
- MovePickerのcaptureの指し手を全数sortするつもりが、間違えてquietのほうでそれやってたの修正。
-
これでR40ぐらい損してた模様。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V773h_1024.exe , eval = Li T2,b1000,1463 - 88 - 1449(50.24% R1.67[-8.92,12.26]) winrate black , white = 51.99% , 48.01% → これでやっと以前のバージョンと互角かー。
engine1 = YaneuraOuNNUE_V773c_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V773h_1024.exe , eval = Li T2,b1000,1360 - 79 - 1561(46.56% R-23.95[-34.54,-13.35]) winrate black , white = 50.94% , 49.06% → このバグでR25近く失ってた。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V773h_1024.exe , eval = Li T2,b2000,1485 - 135 - 1380(51.83% R12.74[2.06,23.42]) winrate black , white = 52.88% , 47.12% → まだ水匠だと互角にはなってないのか…。なんでなん…。2秒計測だからか…。
-
V7.73g
-
Rewarding Quiet Moves that Enable Razoring : https://github.com/official-stockfish/Stockfish/commit/d30af4f669fa9a47e26a54967c571ffa7987d660
-
探索パラメーター調整中だが、いったん、Stockfishの最新までのcommitはすべて取りこむ。
-
MovePickerのソース、少し修正。(機能的変更は無し)
engine1 = YaneuraOuNNUE_V773c_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V773g_1024.exe , eval = Li T2,b1000,1433 - 99 - 1468(49.4% R-4.19[-14.8,6.42]) winrate black , white = 51.74% , 48.26% → わずかに強くなったっぽい。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V773g_1024.exe , eval = Li T2,b1000,1618 - 93 - 1289(55.66% R39.49[28.82,50.16]) winrate black , white = 51.32% , 48.68%
V7.73f2
-
history statsの添字順を速度低下なしにStockfishに合わせる。(tanuki-さんのアイデア)
-
もともと以下のような問題があった。このcommitは、これを解決するものである。
やねうらお — 今日 14:25 ■ history statsの件
将棋だと81升で2のべき乗ではないので、行き先の升(to)が配列の末尾の添字にくると嫌。pc(piece)は32種類なので、これは末尾にくるのは歓迎。
そんなわけでStockfishで hist[pc][to] となってるコードをすべて hist[to][pc] のように書き換えているのだが、たまに間違えてStockfishのコードのまま書いて、いつの間にか棋力が低下していることがある。
久しぶりにソースコードいじった時などは「この変数、添字入れ替えてるんだっけ?」みたいなのをいちいち変数定義を見て確認しないといけない。
このせいで、メンテナンスコストが馬鹿にならない。
これStockfishの順番に倣うとnpsが1,2%低下するとは思うんだけど、それによってR2か3失うことになる。でも、逆に言うとR2か3って、探索パラメーターの調整を少し頑張ればなんとかなる範囲であって、こんなところ拘るの良くないのではないかと思い始めている。
試してみてnps 2%以内の低下なら、この変更、行うかも知れん。 > Stockfishの添字順にする
engine1 = YaneuraOuNNUE_V773c_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V773f2_1024.exe , eval = Li T2,b1000,1786 - 114 - 1780(50.08% R0.58[-8.98,10.15]) winrate black , white = 50.14% , 49.86% → 今回の改造で微塵も弱くなっていない。よいよい。
V7.73f
-
history statsの添字順をStockfishに合わせる。(tanuki-さんのアイデア)
- まずは1つだけ書き換えてみた。
engine1 = YaneuraOuNNUE_V773c_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V773f_1024.exe , eval = Li T2,b1000,2238 - 142 - 2250(49.87% R-0.93[-9.46,7.6]) winrate black , white = 52.45% , 47.55%
V7.73e3
- 計測したら弱くなってたのでpawn_keyは #if defined(ENABLE_PAWN_HISTORY) #endif のように ENABLE_PAWN_HISTORY が定義されている時だけ有効になるようにした。
V7.73e2
-
pawn_key返す時に >> 1忘れていたの修正。 Key pawn_key() const { return st->pawn_key() >> 1; }
engine1 = YaneuraOuNNUE_V773c_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V773e2_1024.exe , eval = Li T2,b1000,1340 - 81 - 1279(51.16% R8.09[-3.07,19.26]) winrate black , white = 51.81% , 48.19% → pawn key導入して弱くなっている。導入中止。
V7.73e
- Introduce pawn structure based history : https://github.com/official-stockfish/Stockfish/commit/b0658f09b93185e2b43d4b2d6f0daa30c36ebcc2
Stockfishで新たにPawn History(pawn = 歩 に相当する駒でこれ専用のhistory stats)が導入された) 盤上のすべてのpawnのstructure(すべてのpawnによる配置)に対してhistory bonusを与えるということのようだ。これにより、陣形の良し悪しみたいなのに対してbonusを加点できるということのようである。
原理としてはpawnが動いた時にZobrist Keyによるpawn hash keyを更新しておき、その下位9bitをstructureのkeyとしてpawn historyの表引きを行うというものだ。
わりと簡単な構造だが、Stockfishの場合、Position(局面)クラスにnoPawns(盤上にpawnがないというフラグ)というメンバー変数があったことからも、pawnの盤上での役割が大きく、意味があるようである。将棋の場合、歩が盤上からすべてなかろうとさしたる意味はないが..(ある筋の歩が切れていることには意味があるだろうが…)
- SQUARE_NB 定義(Stockfishとの互換性維持のために定義)
V7.73d
- Learner::init_for_game()追加。
V7.73c
-
MovePickerのcaptureの計算式、間違ってたの修正。 m.value = 7 * int(Eval::CapturePieceValue[pos.piece_on(to_sq(m))] + (*captureHistory)[to_sq(m)][pos.moved_piece_after(m)][type_of(pos.piece_on(to_sq(m)))]) / 16;
⇓ m.value = (7 * int(Eval::CapturePieceValue[pos.piece_on(to_sq(m))]) + (*captureHistory)[to_sq(m)][pos.moved_piece_after(m)][type_of(pos.piece_on(to_sq(m)))]) / 16; → これ修正したけど強さ変わらず。なんなのか…。 → 他にどのcommitで弱くなっているのか特定して、それ巻き戻したほうがいいかも。
-
Simplify futility pruning formula : https://github.com/official-stockfish/Stockfish/commit/871ab55f01f844bd24ed768c5e734ed2c956ef78
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V773c_1024.exe , eval = Li T2,b1000,937 - 64 - 739(55.91% R41.24[27.18,55.29]) winrate black , white = 51.85% , 48.15% → これでもまだR40ほど弱いのか…。
V7.73b
-
現在のパラメーターで
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V773b_1024.exe , eval = Li T2,b1000,1025 - 51 - 804(56.04% R42.19[28.73,55.65]) winrate black , white = 51.45% , 48.55%
→ 探索パラメーターの調整がうまく機能していることは確認できた。(まだR40も弱いけども..)
total : 6645 - 455 - 9012(42.44% R-52.93)
total : 6645 - 455 - 9012(42.44% R-52.93)
PARAM_REDUCTIONS_PARAM1:
2029 : 1366 - 77 - 1844(42.55% R-52.12)
2033 : 1315 - 96 - 1794(42.3% R-53.96)
2037 : 1343 - 79 - 1757(43.32% R-46.68) , step = 2に
2041 : 1291 - 102 - 1860(40.97% R-63.43)
2045 : 1330 - 101 - 1757(43.08% R-48.37)
PARAM_REDUCTION_ALPHA:
1496 : 1297 - 82 - 1791(42.0% R-56.06)
1528 : 1303 - 94 - 1801(41.98% R-56.23)
1560 : 1340 - 96 - 1824(42.35% R-53.57)
1592 : 1338 - 105 - 1783(42.87% R-49.88) , step = 16に
1624 : 1367 - 78 - 1813(42.99% R-49.05)
PARAM_REDUCTION_BETA:
791 : 1308 - 87 - 1800(42.08% R-55.47)
855 : 1388 - 90 - 1804(43.48% R-45.54) , step = 32に
919 : 1363 - 100 - 1794(43.17% R-47.73)
983 : 1289 - 89 - 1841(41.18% R-61.92)
1047 : 1297 - 89 - 1773(42.25% R-54.31)
PARAM_REDUCTION_GAMMA:
817 : 1349 - 68 - 1814(42.65% R-51.45)
881 : 1318 - 82 - 1840(41.74% R-57.96)
945 : 1368 - 90 - 1770(43.59% R-44.75) , step = 32に
1009 : 1290 - 110 - 1805(41.68% R-58.35)
1073 : 1320 - 105 - 1783(42.54% R-52.23)
PARAM_FUTILITY_MARGIN_ALPHA1:
100 : 1378 - 114 - 1847(42.73% R-50.89)
106 : 1350 - 81 - 1833(42.41% R-53.13)
126 : 1317 - 71 - 1737(43.12% R-48.09) , step = 10に
146 : 1343 - 103 - 1844(42.14% R-55.07)
166 : 1257 - 86 - 1751(41.79% R-57.58)
PARAM_FUTILITY_MARGIN_ALPHA2:
22 : 1333 - 100 - 1811(42.4% R-53.24)
32 : 1323 - 98 - 1828(41.99% R-56.17)
42 : 1272 - 85 - 1807(41.31% R-60.99) , step = 5に
52 : 1369 - 90 - 1775(43.54% R-45.12)
62 : 1348 - 82 - 1791(42.94% R-49.36)
PARAM_FUTILITY_MARGIN_BETA:
100 : 1309 - 91 - 1761(42.64% R-51.53)
108 : 1358 - 93 - 1805(42.93% R-49.43)
138 : 1318 - 92 - 1845(41.67% R-58.43) わからん
168 : 1284 - 91 - 1772(42.02% R-55.96)
198 : 1376 - 88 - 1829(42.93% R-49.44)
PARAM_FUTILITY_MARGIN_QUIET:
160 : 1293 - 81 - 1779(42.09% R-55.43)
180 : 1337 - 100 - 1776(42.95% R-49.32)
200 : 1313 - 99 - 1873(41.21% R-61.71) , step = 10に
220 : 1400 - 78 - 1795(43.82% R-43.17)
240 : 1302 - 97 - 1789(42.12% R-55.2)
PARAM_FUTILITY_AT_PARENT_NODE_MARGIN1:
60 : 1324 - 102 - 1814(42.19% R-54.7)
70 : 1370 - 84 - 1792(43.33% R-46.65)
80 : 1343 - 83 - 1867(41.84% R-57.23) わからん
90 : 1282 - 88 - 1807(41.5% R-59.63)
100 : 1326 - 98 - 1732(43.36% R-46.4)
PARAM_FUTILITY_AT_PARENT_NODE_ALPHA:
102 : 1408 - 104 - 1766(44.36% R-39.36)
112 : 1386 - 78 - 1878(42.46% R-52.77)
122 : 1347 - 89 - 1764(43.3% R-46.85) , step = 5に
132 : 1288 - 90 - 1776(42.04% R-55.81)
142 : 1216 - 94 - 1828(39.95% R-70.82)
PARAM_FUTILITY_AT_PARENT_NODE_GAMMA1:
23 : 1330 - 94 - 1774(42.85% R-50.04)
25 : 1371 - 99 - 1803(43.19% R-47.58)
27 : 1360 - 85 - 1813(42.86% R-49.94) , step = 1に
29 : 1324 - 76 - 1820(42.11% R-55.27)
31 : 1260 - 101 - 1802(41.15% R-62.15)
PARAM_LMR_SEE_MARGIN1:
205 : 1262 - 91 - 1835(40.75% R-65.03)
215 : 1364 - 96 - 1756(43.72% R-43.88) ✔
225 : 1401 - 86 - 1847(43.13% R-48.01)
235 : 1323 - 105 - 1783(42.59% R-51.84)
245 : 1295 - 77 - 1791(41.96% R-56.33)
PARAM_NULL_MOVE_DYNAMIC_GAMMA:
152 : 1420 - 99 - 1844(43.5% R-45.39) ✔
157 : 1329 - 94 - 1763(42.98% R-49.09)
162 : 1296 - 84 - 1797(41.9% R-56.78)
167 : 1287 - 93 - 1805(41.62% R-58.76)
172 : 1313 - 85 - 1803(42.14% R-55.09)
PARAM_NULL_MOVE_MARGIN1:
22 : 1279 - 82 - 1802(41.51% R-59.55)
23 : 1356 - 76 - 1796(43.02% R-48.82)
24 : 1295 - 96 - 1766(42.31% R-53.89) わからん
25 : 1340 - 94 - 1824(42.35% R-53.57)
26 : 1375 - 107 - 1824(42.98% R-49.09)
PARAM_NULL_MOVE_MARGIN4:
231 : 1308 - 91 - 1731(43.04% R-48.68)
256 : 1373 - 99 - 1797(43.31% R-46.75) ✔ step = 13
281 : 1292 - 89 - 1868(40.89% R-64.05)
306 : 1294 - 93 - 1841(41.28% R-61.25)
331 : 1378 - 83 - 1775(43.7% R-43.98)
PARAM_PROBCUT_MARGIN1:
138 : 1362 - 97 - 1845(42.47% R-52.73)
153 : 1284 - 92 - 1817(41.41% R-60.32)
168 : 1303 - 87 - 1772(42.37% R-53.41)
183 : 1423 - 85 - 1777(44.47% R-38.59) ✔ step = 10に
198 : 1273 - 94 - 1801(41.41% R-60.27)
PARAM_PROBCUT_MARGIN2:
62 : 1269 - 82 - 1769(41.77% R-57.71)
66 : 1412 - 95 - 1776(44.29% R-39.84)
70 : 1339 - 91 - 1753(43.31% R-46.8) 68 step = 2に
74 : 1325 - 97 - 1854(41.68% R-58.36)
78 : 1300 - 90 - 1860(41.14% R-62.23)
PARAM_PROBCUT_MARGIN3:
400 : 1325 - 79 - 1760(42.95% R-49.32)
408 : 1279 - 91 - 1870(40.62% R-65.99)
416 : 1351 - 101 - 1822(42.58% R-51.96) わからん
424 : 1343 - 88 - 1761(43.27% R-47.07)
432 : 1347 - 96 - 1799(42.82% R-50.27)
PARAM_SINGULAR_MARGIN1:
48 : 1322 - 91 - 1797(42.39% R-53.33)
56 : 1345 - 96 - 1830(42.36% R-53.49)
64 : 1290 - 90 - 1852(41.06% R-62.82) わからん
72 : 1344 - 94 - 1806(42.67% R-51.33)
80 : 1344 - 84 - 1727(43.76% R-43.56)
PARAM_SINGULAR_MARGIN2:
37 : 1287 - 96 - 1847(41.07% R-62.76)
43 : 1375 - 101 - 1722(44.4% R-39.09)
49 : 1334 - 82 - 1769(42.99% R-49.03) 45 step = 4
55 : 1318 - 93 - 1836(41.79% R-57.58)
61 : 1331 - 83 - 1838(42.0% R-56.07)
PARAM_LMR_MARGIN1:
47 : 1423 - 91 - 1861(43.33% R-46.62)
49 : 1254 - 87 - 1849(40.41% R-67.46)
51 : 1279 - 86 - 1795(41.61% R-58.88) わからん
53 : 1337 - 86 - 1808(42.51% R-52.43)
55 : 1352 - 105 - 1699(44.31% R-39.69)
PARAM_LMR_MARGIN2:
10 : 1335 - 101 - 1881(41.51% R-59.56)
11 : 1276 - 89 - 1790(41.62% R-58.8)
12 : 1354 - 89 - 1783(43.16% R-47.81)
13 : 1338 - 83 - 1711(43.88% R-42.72)
14 : 1342 - 93 - 1847(42.08% R-55.49)
PARAM_LMR_MARGIN3:
540 : 1253 - 86 - 1847(40.42% R-67.41)
620 : 1346 - 88 - 1772(43.17% R-47.77)
700 : 1396 - 72 - 1774(44.04% R-41.63) step = 25に
780 : 1305 - 100 - 1816(41.81% R-57.4)
860 : 1345 - 109 - 1803(42.73% R-50.91)
PARAM_UPDATE_ALL_STATS_EVAL_TH:
50 : 1259 - 89 - 1737(42.02% R-55.91)
70 : 1351 - 86 - 1832(42.44% R-52.91)
90 : 1390 - 87 - 1816(43.36% R-46.44) , step = 10に
110 : 1323 - 94 - 1837(41.87% R-57.02)
130 : 1322 - 99 - 1790(42.48% R-52.65)
PARAM_COUNTERMOVE_FAILLOW_MARGIN:
593 : 1263 - 100 - 1813(41.06% R-62.8)
623 : 1367 - 83 - 1796(43.22% R-47.42)
653 : 1327 - 84 - 1780(42.71% R-51.02) , step = 15に
683 : 1332 - 90 - 1796(42.58% R-51.92)
713 : 1356 - 98 - 1827(42.6% R-51.79)
V7.73a
-
現在のパラメーターで。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V773a_1024.exe , eval = Li T2,b1000,1063 - 66 - 801(57.03% R49.16[35.79,62.53]) winrate black , white = 50.0% , 50.0%
V7.72param4
total : 13903 - 1068 - 19330(41.83% R-57.25)
total : 13903 - 1068 - 19330(41.83% R-57.25)
PARAM_REDUCTIONS_PARAM1:
2032 : 2823 - 228 - 3868(42.19% R-54.71)
2036 : 2798 - 220 - 3839(42.16% R-54.95)
2040 : 2730 - 211 - 3889(41.24% R-61.47) わからん。元の値が2037なので2037,step 4からやりなおす。
2044 : 2775 - 198 - 3923(41.43% R-60.14)
2048 : 2777 - 211 - 3811(42.15% R-54.99)
PARAM_REDUCTION_ALPHA:
1432 : 2687 - 211 - 3885(40.89% R-64.05)
1496 : 2698 - 207 - 3945(40.61% R-66.0)
1560 : 2840 - 239 - 3798(42.78% R-50.49) ✔ 範囲狭める
1624 : 2873 - 216 - 3852(42.72% R-50.94)
1688 : 2805 - 195 - 3850(42.15% R-55.01)
PARAM_REDUCTION_BETA:
535 : 2765 - 228 - 3907(41.44% R-60.06)
663 : 2747 - 223 - 3892(41.38% R-60.53)
791 : 2738 - 198 - 3850(41.56% R-59.21)
919 : 2850 - 230 - 3844(42.58% R-51.98) ✔ 範囲狭める step 64に
1047 : 2803 - 189 - 3837(42.21% R-54.55)
PARAM_REDUCTION_GAMMA:
689 : 2713 - 213 - 3868(41.22% R-61.61)
817 : 2779 - 207 - 3887(41.69% R-58.29)
945 : 2794 - 224 - 3855(42.02% R-55.92) ✔元の値なのでここ。step 64に。
1073 : 2773 - 201 - 3776(42.34% R-53.63)
1201 : 2844 - 223 - 3944(41.9% R-56.8)
PARAM_FUTILITY_MARGIN_ALPHA1:
100 : 2770 - 237 - 3811(42.09% R-55.42)
106 : 2988 - 213 - 3998(42.77% R-50.58)
126 : 2745 - 206 - 3871(41.49% R-59.71) よくわからんなー。これはこのまま。
146 : 2682 - 208 - 3896(40.77% R-64.86)
166 : 2718 - 204 - 3754(42.0% R-56.1)
PARAM_FUTILITY_MARGIN_ALPHA2:
22 : 2793 - 200 - 3960(41.36% R-60.65)
32 : 2847 - 213 - 3878(42.33% R-53.69)
42 : 2665 - 225 - 3814(41.13% R-62.27) これもよくわからんなー。これもこのまま。
52 : 2821 - 233 - 3835(42.38% R-53.34)
62 : 2777 - 197 - 3843(41.95% R-56.44)
PARAM_FUTILITY_MARGIN_BETA:
100 : 2812 - 234 - 3859(42.15% R-54.98)
108 : 2770 - 222 - 3859(41.79% R-57.6)
138 : 2828 - 209 - 3913(41.95% R-56.41) これもよくわからんなー。
168 : 2712 - 197 - 3860(41.27% R-61.32)
198 : 2781 - 206 - 3839(42.01% R-56.01)
PARAM_FUTILITY_MARGIN_QUIET:
160 : 2866 - 194 - 3908(42.31% R-53.87)
180 : 2770 - 206 - 3850(41.84% R-57.19)
200 : 2713 - 233 - 3811(41.58% R-59.04) ちっともわからん。
220 : 2813 - 227 - 3868(42.1% R-55.33)
240 : 2741 - 208 - 3893(41.32% R-60.95)
PARAM_FUTILITY_AT_PARENT_NODE_MARGIN1:
60 : 2774 - 205 - 3896(41.59% R-59.0)
70 : 2861 - 223 - 4014(41.61% R-58.82)
80 : 2829 - 216 - 3816(42.57% R-51.99) わからんわからん。
90 : 2677 - 208 - 3791(41.39% R-60.44)
100 : 2762 - 216 - 3813(42.01% R-56.02)
PARAM_FUTILITY_AT_PARENT_NODE_ALPHA:
102 : 2753 - 203 - 3859(41.64% R-58.67)
112 : 2796 - 221 - 3921(41.63% R-58.74)
122 : 2767 - 198 - 3814(42.05% R-55.75) これも変えても意味なくね?
132 : 2860 - 221 - 3907(42.26% R-54.19)
142 : 2727 - 225 - 3829(41.6% R-58.96)
PARAM_FUTILITY_AT_PARENT_NODE_GAMMA1:
23 : 2809 - 209 - 3783(42.61% R-51.71)
25 : 2799 - 237 - 3891(41.84% R-57.22)
27 : 2866 - 231 - 3847(42.69% R-51.14) よくわからんなー。
29 : 2769 - 203 - 3954(41.19% R-61.89)
31 : 2660 - 188 - 3855(40.83% R-64.46)
PARAM_LMR_SEE_MARGIN1:
145 : 2597 - 205 - 4021(39.24% R-75.94)
165 : 2695 - 222 - 3796(41.52% R-59.51)
185 : 2830 - 198 - 3955(41.71% R-58.14)
205 : 2835 - 223 - 3792(42.78% R-50.53)
225 : 2946 - 220 - 3766(43.89% R-42.66) これは間違いなくここか..step = 10に。
PARAM_NULL_MOVE_DYNAMIC_GAMMA:
132 : 2735 - 228 - 3746(42.2% R-54.64)
142 : 2750 - 186 - 3897(41.37% R-60.56)
152 : 2736 - 228 - 3884(41.33% R-60.87)
162 : 2882 - 221 - 3833(42.92% R-49.54) ✔ step = 5に
172 : 2800 - 205 - 3970(41.36% R-60.65)
PARAM_NULL_MOVE_MARGIN1:
22 : 2703 - 253 - 3890(41.0% R-63.24)
23 : 2861 - 218 - 3881(42.44% R-52.97)
24 : 2833 - 205 - 3911(42.01% R-56.02) よくわからん..このままで
25 : 2714 - 185 - 3812(41.59% R-59.02)
26 : 2792 - 207 - 3836(42.12% R-55.19)
PARAM_NULL_MOVE_MARGIN4:
231 : 2753 - 183 - 3797(42.03% R-55.85)
256 : 2782 - 241 - 3915(41.54% R-59.35)
281 : 2751 - 188 - 3855(41.64% R-58.61) このままで..
306 : 2789 - 215 - 3851(42.0% R-56.05)
331 : 2828 - 241 - 3912(41.96% R-56.37)
PARAM_PROBCUT_MARGIN1:
128 : 2774 - 243 - 3854(41.85% R-57.12)
148 : 2821 - 206 - 3872(42.15% R-55.01)
168 : 2795 - 210 - 3830(42.19% R-54.73) よくわからん。範囲少し縮める。step = 15に。
188 : 2814 - 202 - 3848(42.24% R-54.36)
208 : 2699 - 207 - 3926(40.74% R-65.1)
PARAM_PROBCUT_MARGIN2:
60 : 2741 - 224 - 3783(42.01% R-55.97)
65 : 2801 - 234 - 3870(41.99% R-56.16)
70 : 2821 - 208 - 3843(42.33% R-53.71) 範囲少し縮める。
75 : 2769 - 197 - 3946(41.24% R-61.53)
80 : 2771 - 205 - 3888(41.61% R-58.84)
PARAM_PROBCUT_MARGIN3:
396 : 2821 - 221 - 3840(42.35% R-53.57)
406 : 2766 - 179 - 3915(41.4% R-60.35)
416 : 2739 - 203 - 3770(42.08% R-55.5) ✔ 範囲少し縮める
426 : 2831 - 225 - 3792(42.74% R-50.77)
436 : 2746 - 240 - 4013(40.63% R-65.91)
PARAM_SINGULAR_MARGIN1:
48 : 2785 - 208 - 3929(41.48% R-59.78)
56 : 2720 - 217 - 3793(41.76% R-57.77)
64 : 2795 - 221 - 3906(41.71% R-58.14) あんま変わらんなー
72 : 2799 - 223 - 3826(42.25% R-54.3)
80 : 2804 - 199 - 3876(41.98% R-56.24)
PARAM_SINGULAR_MARGIN2:
41 : 2811 - 213 - 3875(42.04% R-55.76)
49 : 2810 - 229 - 3779(42.65% R-51.47) ✔ 範囲少し縮める
57 : 2783 - 206 - 3862(41.88% R-56.92)
65 : 2747 - 213 - 3894(41.36% R-60.61)
73 : 2752 - 207 - 3920(41.25% R-61.46)
PARAM_LMR_MARGIN1:
43 : 2754 - 221 - 3924(41.24% R-61.51)
47 : 2680 - 189 - 3800(41.36% R-60.66)
51 : 2866 - 212 - 3888(42.43% R-52.98) ✔ 範囲縮める
55 : 2792 - 235 - 3842(42.09% R-55.46)
59 : 2811 - 211 - 3876(42.04% R-55.81)
PARAM_LMR_MARGIN2:
8 : 2743 - 222 - 3893(41.34% R-60.82)
9 : 2769 - 230 - 3896(41.55% R-59.32)
10 : 2830 - 236 - 3913(41.97% R-56.29)
11 : 2784 - 170 - 3841(42.02% R-55.91)
12 : 2777 - 210 - 3787(42.31% R-53.89) ✔
PARAM_LMR_MARGIN3:
500 : 2685 - 207 - 3887(40.86% R-64.27)
600 : 2856 - 213 - 3870(42.46% R-52.78)
700 : 2822 - 224 - 3853(42.28% R-54.1) ✔ 範囲少し縮める
800 : 2806 - 213 - 3895(41.87% R-56.97)
900 : 2734 - 211 - 3825(41.68% R-58.33)
PARAM_PRUNING_BY_HISTORY_DEPTH:
5 : 4668 - 363 - 6410(42.14% R-55.09)
6 : 4651 - 343 - 6407(42.06% R-55.64) ✔ depthはこれでいいや..
7 : 4584 - 362 - 6513(41.31% R-61.01)
PARAM_UPDATE_ALL_STATS_EVAL_TH:
40 : 2707 - 223 - 3845(41.32% R-60.96)
70 : 2806 - 221 - 3963(41.45% R-59.97)
100 : 2734 - 196 - 3772(42.02% R-55.91) 90 , step = 20に変更
130 : 2832 - 209 - 3936(41.84% R-57.18)
160 : 2824 - 219 - 3814(42.54% R-52.21)
PARAM_COUNTERMOVE_FAILLOW_MARGIN:
553 : 2770 - 203 - 3797(42.18% R-54.78)
603 : 2670 - 207 - 3835(41.05% R-62.9)
653 : 2776 - 214 - 3898(41.59% R-58.97) よくわからんなー。範囲少しだけ縮める。
703 : 2927 - 200 - 3927(42.7% R-51.06)
753 : 2760 - 244 - 3873(41.61% R-58.86)
→ 今度は、ちゃんと調整した効果が出たっぽい。 やはり、Reductionテーブルの初期化に失敗して、テーブルの値がおかしくなってる状態でパラメーター調整してたからうまくいかなかったのか…。
total : 3124 - 258 - 4787(39.49% R-74.14)
total : 3124 - 258 - 4787(39.49% R-74.14)
PARAM_REDUCTIONS_PARAM1:
2021 : 13 - 0 - 32(28.89% R-156.48)
2025 : 22 - 2 - 38(36.67% R-94.94)
2027 : 14 - 4 - 31(31.11% R-138.09)
2029 : 38 - 3 - 60(38.78% R-79.35)
2031 : 24 - 1 - 40(37.5% R-88.74)
2033 : 19 - 1 - 45(29.69% R-149.78)
2035 : 156 - 8 - 218(41.71% R-58.13)
2036 : 125 - 6 - 163(43.4% R-46.11)
2037 : 156 - 16 - 246(38.81% R-79.12)
2038 : 120 - 13 - 170(41.38% R-60.51)
2039 : 343 - 36 - 611(35.95% R-100.3)
2040 : 369 - 30 - 545(40.37% R-67.75)
2041 : 378 - 23 - 563(40.17% R-69.21) → 差があまりなくてわからない。2040 , step = 4 にしてみる
2042 : 375 - 22 - 556(40.28% R-68.42)
2043 : 377 - 43 - 589(39.03% R-77.51)
2044 : 106 - 13 - 173(37.99% R-85.1)
2045 : 191 - 13 - 241(44.21% R-40.39)
2046 : 121 - 9 - 182(39.93% R-70.91)
2047 : 135 - 11 - 226(37.4% R-89.51)
2049 : 25 - 3 - 36(40.98% R-63.34)
2053 : 17 - 1 - 22(43.59% R-44.79)
PARAM_REDUCTION_ALPHA:
1432 : 626 - 63 - 907(40.83% R-64.41)
1496 : 641 - 53 - 996(39.16% R-76.56)
1560 : 611 - 45 - 955(39.02% R-77.58)
1624 : 615 - 46 - 938(39.6% R-73.33)
1688 : 631 - 51 - 991(38.9% R-78.42)
PARAM_REDUCTION_BETA:
535 : 594 - 53 - 955(38.35% R-82.49)
663 : 641 - 47 - 957(40.11% R-69.62)
791 : 602 - 48 - 943(38.96% R-77.97)
919 : 642 - 55 - 963(40.0% R-70.44)
1047 : 645 - 55 - 969(39.96% R-70.71)
PARAM_REDUCTION_GAMMA:
689 : 626 - 41 - 942(39.92% R-70.99)
817 : 619 - 58 - 943(39.63% R-73.13)
945 : 620 - 64 - 936(39.85% R-71.55)
1073 : 639 - 55 - 972(39.66% R-72.87)
1201 : 620 - 40 - 994(38.41% R-82.0)
PARAM_FUTILITY_MARGIN_ALPHA1:
100 : 647 - 57 - 1007(39.12% R-76.85)
106 : 596 - 54 - 984(37.72% R-87.1)
126 : 658 - 54 - 959(40.69% R-65.44)
146 : 607 - 43 - 909(40.04% R-70.15)
166 : 616 - 50 - 928(39.9% R-71.19)
PARAM_FUTILITY_MARGIN_ALPHA2:
22 : 647 - 53 - 944(40.67% R-65.63)
32 : 626 - 46 - 954(39.62% R-73.19)
42 : 621 - 52 - 944(39.68% R-72.75)
52 : 606 - 54 - 983(38.14% R-84.03)
62 : 624 - 53 - 962(39.34% R-75.2)
PARAM_FUTILITY_MARGIN_BETA:
100 : 629 - 55 - 976(39.19% R-76.32)
118 : 589 - 55 - 931(38.75% R-79.53)
138 : 621 - 44 - 975(38.91% R-78.37) step = 30にしてみる
158 : 653 - 46 - 998(39.55% R-73.69)
178 : 632 - 58 - 907(41.07% R-62.76)
PARAM_FUTILITY_MARGIN_QUIET:
160 : 634 - 65 - 922(40.75% R-65.06)
180 : 622 - 41 - 962(39.27% R-75.75)
200 : 661 - 63 - 1001(39.77% R-72.09)
220 : 580 - 38 - 926(38.51% R-81.27)
240 : 627 - 51 - 976(39.11% R-76.87)
PARAM_FUTILITY_RETURN_DEPTH:
8 : 1041 - 74 - 1592(39.54% R-73.8)
9 : 1072 - 83 - 1549(40.9% R-63.94) ✔ depth変更するのよくなさそう
10 : 1011 - 101 - 1646(38.05% R-84.67)
PARAM_FUTILITY_AT_PARENT_NODE_DEPTH:
12 : 1010 - 77 - 1612(38.52% R-81.22)
13 : 1066 - 82 - 1599(40.0% R-70.44) ✔ depth変更するのあまり良くなさそう
14 : 1048 - 99 - 1576(39.94% R-70.88)
PARAM_FUTILITY_AT_PARENT_NODE_MARGIN1:
60 : 616 - 47 - 950(39.34% R-75.26)
70 : 641 - 50 - 947(40.37% R-67.8)
80 : 608 - 48 - 1008(37.62% R-87.82)
90 : 626 - 52 - 945(39.85% R-71.54)
100 : 633 - 61 - 937(40.32% R-68.13)
PARAM_FUTILITY_AT_PARENT_NODE_ALPHA:
112 : 615 - 44 - 963(38.97% R-77.9)
117 : 593 - 54 - 971(37.92% R-85.67)
122 : 607 - 54 - 964(38.64% R-80.36) 解像度不足。step = 10に
127 : 693 - 47 - 957(42.0% R-56.07)
132 : 616 - 59 - 932(39.79% R-71.93)
PARAM_FUTILITY_AT_PARENT_NODE_GAMMA1:
23 : 628 - 63 - 924(40.46% R-67.08)
25 : 597 - 55 - 951(38.57% R-80.88)
27 : 662 - 51 - 991(40.05% R-70.09)
29 : 612 - 38 - 963(38.86% R-78.75)
31 : 625 - 51 - 958(39.48% R-74.19)
PARAM_LMR_SEE_MARGIN1:
105 : 479 - 44 - 1137(29.64% R-150.17)
145 : 620 - 53 - 981(38.73% R-79.71)
185 : 643 - 56 - 849(43.1% R-48.28) ✔ step = 20に。
225 : 709 - 52 - 911(43.77% R-43.55)
265 : 673 - 53 - 909(42.54% R-52.22)
PARAM_NULL_MOVE_DYNAMIC_GAMMA:
132 : 642 - 44 - 1003(39.03% R-77.51)
142 : 599 - 56 - 916(39.54% R-73.79)
152 : 630 - 56 - 933(40.31% R-68.22)
162 : 622 - 48 - 1006(38.21% R-83.52)
172 : 631 - 54 - 929(40.45% R-67.19)
PARAM_NULL_MOVE_MARGIN1:
20 : 610 - 35 - 980(38.36% R-82.36)
22 : 646 - 52 - 950(40.48% R-67.0)
24 : 636 - 65 - 902(41.35% R-60.7) ✔ step = 1に
26 : 606 - 47 - 1005(37.62% R-87.88)
28 : 626 - 59 - 950(39.72% R-72.46)
PARAM_NULL_MOVE_MARGIN4:
181 : 613 - 51 - 896(40.62% R-65.94)
231 : 661 - 53 - 962(40.73% R-65.19)
281 : 636 - 54 - 931(40.59% R-66.2) ✔ step = 25に。
331 : 614 - 49 - 982(38.47% R-81.58)
381 : 600 - 51 - 1016(37.13% R-91.5)
PARAM_NULL_MOVE_RETURN_DEPTH:
13 : 1023 - 80 - 1618(38.74% R-79.64)
14 : 1042 - 98 - 1542(40.33% R-68.09) ✔ depth調整しても仕方がないか..
15 : 1059 - 80 - 1627(39.43% R-74.6)
PARAM_PROBCUT_MARGIN1:
128 : 637 - 59 - 949(40.16% R-69.25)
148 : 623 - 54 - 916(40.48% R-66.96)
168 : 562 - 54 - 968(36.73% R-94.46)
188 : 631 - 43 - 960(39.66% R-72.9)
208 : 671 - 48 - 994(40.3% R-68.27)
PARAM_PROBCUT_MARGIN2:
50 : 628 - 39 - 964(39.45% R-74.45)
60 : 611 - 49 - 941(39.37% R-75.02)
70 : 633 - 52 - 902(41.24% R-61.52) ✔ step = 5に変更
80 : 619 - 70 - 975(38.83% R-78.93)
90 : 633 - 48 - 1005(38.64% R-80.3)
PARAM_PROBCUT_MARGIN3:
396 : 586 - 51 - 935(38.53% R-81.17)
406 : 615 - 49 - 995(38.2% R-83.58)
416 : 649 - 56 - 960(40.34% R-68.01)
426 : 627 - 50 - 962(39.46% R-74.36)
436 : 647 - 52 - 935(40.9% R-63.96)
PARAM_SINGULAR_MARGIN1:
48 : 624 - 49 - 1018(38.0% R-85.03)
56 : 657 - 52 - 973(40.31% R-68.22)
64 : 615 - 53 - 929(39.83% R-71.66)
72 : 608 - 52 - 909(40.08% R-69.86)
80 : 620 - 52 - 958(39.29% R-75.59)
PARAM_SINGULAR_MARGIN2:
41 : 622 - 44 - 959(39.34% R-75.21)
49 : 600 - 57 - 933(39.14% R-76.69)
57 : 625 - 40 - 955(39.56% R-73.65)
65 : 658 - 69 - 982(40.12% R-69.55)
73 : 619 - 48 - 958(39.25% R-75.87)
PARAM_LMR_MARGIN1:
43 : 615 - 45 - 926(39.91% R-71.09)
47 : 618 - 51 - 994(38.34% R-82.56)
51 : 672 - 49 - 945(41.56% R-59.23)
55 : 645 - 62 - 963(40.11% R-69.63)
59 : 574 - 51 - 959(37.44% R-89.16)
PARAM_LMR_MARGIN2:
8 : 619 - 50 - 978(38.76% R-79.46)
9 : 598 - 56 - 984(37.8% R-86.52)
10 : 634 - 55 - 934(40.43% R-67.3)
11 : 650 - 54 - 924(41.3% R-61.1)
12 : 623 - 43 - 967(39.18% R-76.38)
PARAM_LMR_MARGIN3:
500 : 655 - 45 - 998(39.62% R-73.16)
600 : 616 - 53 - 968(38.89% R-78.52)
700 : 639 - 52 - 966(39.81% R-71.79)
800 : 590 - 53 - 925(38.94% R-78.12)
900 : 624 - 55 - 930(40.15% R-69.32)
PARAM_PRUNING_BY_HISTORY_DEPTH:
5 : 995 - 72 - 1593(38.45% R-81.76)
6 : 1038 - 88 - 1620(39.05% R-77.33)
7 : 1091 - 98 - 1574(40.94% R-63.67)
PARAM_UPDATE_ALL_STATS_EVAL_TH:
40 : 629 - 46 - 923(40.53% R-66.62)
70 : 614 - 57 - 989(38.3% R-82.81)
100 : 622 - 58 - 945(39.69% R-72.66)
130 : 601 - 43 - 921(39.49% R-74.15)
160 : 658 - 54 - 1009(39.47% R-74.27)
PARAM_COUNTERMOVE_FAILLOW_MARGIN:
553 : 590 - 52 - 948(38.36% R-82.38)
603 : 649 - 52 - 950(40.59% R-66.19)
653 : 626 - 55 - 985(38.86% R-78.74)
703 : 615 - 44 - 948(39.35% R-75.17)
753 : 644 - 55 - 956(40.25% R-68.63)
PARAM_ASPIRATION_SEARCH_DELTA:
9 : 1030 - 83 - 1595(39.24% R-75.97)
10 : 1042 - 79 - 1526(40.58% R-66.27) ✔
11 : 1052 - 96 - 1666(38.7% R-79.86)
V7.72z
- reductionパラメーター、設定するタイミングが早かったの修正。
- 探索パラメーター調整しなおし その0
- Threads.increaseDepthの条件式、変更。
- Null Moveの条件に
- && beta > VALUE_TB_LOSS_IN_MAX_PLY をつけ忘れていたの修正。 → これ R20ぐらいの価値あるのか?
V7.72y engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V772y_1024.exe , eval = Li T2,b1000,1933 - 100 - 1457(57.02% R49.11[39.2,59.02]) winrate black , white = 51.74% , 48.26% T2,b2000,929 - 60 - 701(56.99% R48.92[34.63,63.21]) winrate black , white = 52.15% , 47.85%
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503
engine2 = YaneuraOuNNUE_V772y_1024.exe , eval = Li
T2,b1000,1747 - 115 - 1508(53.67% R25.56[15.51,35.6]) winrate black , white = 52.41% , 47.59%
→ 良くなってない。 reductionパラメーター、設定するタイミングが早い。(バグ)
V7.72param3
total : 4976 - 476 - 6432(43.62% R-44.59)
total : 4976 - 476 - 6432(43.62% R-44.59)
PARAM_FUTILITY_MARGIN_ALPHA1:
126 : 1609 - 163 - 2150(42.8% R-50.35)
131 : 1702 - 162 - 2061(45.23% R-33.25) ✔ ±2に
136 : 1665 - 151 - 2221(42.85% R-50.05)
PARAM_FUTILITY_MARGIN_ALPHA2:
42 : 1683 - 178 - 2125(44.2% R-40.51) ✔ ±2に
44 : 1694 - 149 - 2148(44.09% R-41.25)
46 : 1599 - 149 - 2159(42.55% R-52.16)
PARAM_FUTILITY_MARGIN_BETA:
134 : 1708 - 155 - 2177(43.96% R-42.15)
136 : 1657 - 161 - 2102(44.08% R-41.32) ✔ 135±1に
138 : 1611 - 160 - 2153(42.8% R-50.38)
PARAM_FUTILITY_MARGIN_QUIET:
175 : 1625 - 166 - 2120(43.39% R-46.19)
180 : 1716 - 156 - 2139(44.51% R-38.28) ✔±2に
185 : 1635 - 154 - 2173(42.94% R-49.42)
PARAM_FUTILITY_AT_PARENT_NODE_MARGIN1:
80 : 0 - 0 - 1(0.0%) → Stockfish2023/10/26のcommitで 80に変更になった。
85 : 1 - 0 - 1(50.0% R-0.0)
110 : 1618 - 147 - 2102(43.49% R-45.46)
115 : 1694 - 167 - 2201(43.49% R-45.48)
120 : 1663 - 162 - 2127(43.88% R-42.75)
PARAM_FUTILITY_AT_PARENT_NODE_ALPHA:
116 : 1601 - 156 - 2125(42.97% R-49.19)
119 : 1679 - 156 - 2177(43.54% R-45.12)
122 : 1696 - 164 - 2130(44.33% R-39.58) ✔ ±2に
PARAM_REDUCTIONS_PARAM1:
2027 : 1633 - 150 - 2202(42.58% R-51.93)
2031 : 1705 - 178 - 2158(44.14% R-40.93)
2035 : 1638 - 148 - 2072(44.15% R-40.83) ✔±2に
PARAM_REDUCTION_ALPHA:
1432 : 1700 - 153 - 2208(43.5% R-45.42)
1560 : 1631 - 155 - 2116(43.53% R-45.22) ✔ ±64に
1688 : 1645 - 168 - 2108(43.83% R-43.08)
PARAM_REDUCTION_BETA:
759 : 1675 - 155 - 2095(44.43% R-38.87) ✔
791 : 1628 - 150 - 2136(43.25% R-47.18)
823 : 1673 - 171 - 2201(43.19% R-47.65)
PARAM_REDUCTION_GAMMA:
593 : 1652 - 149 - 2168(43.25% R-47.22)
625 : 1674 - 167 - 2102(44.33% R-39.55) ✔ ±16に
657 : 1650 - 160 - 2162(43.28% R-46.95)
PARAM_NULL_MOVE_DYNAMIC_GAMMA:
152 : 1676 - 172 - 2206(43.17% R-47.73)
157 : 1650 - 153 - 2072(44.33% R-39.56) ✔ ±2に
162 : 1650 - 151 - 2154(43.38% R-46.3)
PARAM_NULL_MOVE_MARGIN1:
22 : 1632 - 175 - 2123(43.46% R-45.69)
24 : 1669 - 147 - 2156(43.63% R-44.48) 変わらんからfixed
26 : 1675 - 154 - 2153(43.76% R-43.61)
PARAM_NULL_MOVE_MARGIN4:
271 : 1654 - 167 - 2202(42.89% R-49.71)
281 : 1663 - 155 - 2129(43.86% R-42.91) ✔ ±4に
291 : 1659 - 154 - 2101(44.12% R-41.03)
PARAM_NULL_MOVE_RETURN_DEPTH:
11 : 1698 - 150 - 2136(44.29% R-39.87)
12 : 1657 - 158 - 2113(43.95% R-42.23)
13 : 1621 - 168 - 2183(42.61% R-51.71)
PARAM_PROBCUT_MARGIN1:
158 : 1689 - 180 - 2176(43.7% R-44.01)
168 : 1605 - 146 - 2144(42.81% R-50.3)
178 : 1682 - 150 - 2112(44.33% R-39.55)
PARAM_PROBCUT_MARGIN2:
60 : 1677 - 178 - 2100(44.4% R-39.07)
70 : 1583 - 158 - 2169(42.19% R-54.71) ✔ わからん。元の値が70なので70±5にしてみる。
80 : 1716 - 140 - 2163(44.24% R-40.22)
PARAM_PROBCUT_MARGIN3:
396 : 1668 - 170 - 2226(42.84% R-50.13)
406 : 1637 - 134 - 2098(43.83% R-43.1)
416 : 1671 - 172 - 2108(44.22% R-40.36) ✔元の値が416なので416±5にしてみる。
PARAM_SINGULAR_MARGIN1:
60 : 1695 - 154 - 2107(44.58% R-37.8) ✔ ±4
64 : 1592 - 153 - 2185(42.15% R-55.0)
68 : 1689 - 169 - 2140(44.11% R-41.11)
PARAM_SINGULAR_MARGIN2:
53 : 1654 - 140 - 2180(43.14% R-47.97)
57 : 1637 - 180 - 2119(43.58% R-44.83)
61 : 1685 - 156 - 2133(44.13% R-40.96) ✔ ±4
PARAM_LMR_MARGIN1:
51 : 1676 - 154 - 2173(43.54% R-45.11) ✔計測できない差。元の値が51なのでこれにしておく。
53 : 1650 - 172 - 2133(43.62% R-44.6)
55 : 1650 - 150 - 2126(43.7% R-44.03)
PARAM_LMR_MARGIN3:
600 : 1687 - 154 - 2176(43.67% R-44.22)
700 : 1639 - 176 - 2185(42.86% R-49.95)
800 : 1650 - 146 - 2071(44.34% R-39.48)
PARAM_UPDATE_ALL_STATS_EVAL_TH:
80 : 1648 - 160 - 2160(43.28% R-47.0)
90 : 1649 - 146 - 2156(43.34% R-46.57)
100 : 1679 - 170 - 2116(44.24% R-40.19) ✔
PARAM_COUNTERMOVE_FAILLOW_MARGIN:
628 : 1587 - 169 - 2103(43.01% R-48.9)
653 : 1722 - 135 - 2106(44.98% R-34.97) ✔ ±16に
678 : 1667 - 172 - 2223(42.85% R-50.0)
-
Update 5 search params for pruning at shallow depth : https://github.com/official-stockfish/Stockfish/commit/0024133b08777b578c1036eb1e4a36343b7fa1bb
-
Fix overflow in add_dpbusd_epi32x2 #268
- tanuki-さんのプルリク
-
from_sq(Move)にASSERT追加。
-
UnitTestのランダムプレイヤーの対局、0番目のstack、潰していたの修正。
-
パラメーター調整スクリプト、Python 3系に対応。
V7.72param2
- 探索パラメーターの調整その2。 total : 5482 - 561 - 7302(42.88% R-49.8) total : 5482 - 561 - 7302(42.88% R-49.8) PARAM_FUTILITY_MARGIN_ALPHA1: 126 : 1746 - 176 - 2411(42.0% R-56.06) 136 : 1891 - 195 - 2464(43.42% R-45.98) ✔元の値が126なので131±5に。 146 : 1845 - 190 - 2427(43.19% R-47.63) PARAM_FUTILITY_MARGIN_ALPHA2: 37 : 1831 - 179 - 2420(43.07% R-48.45) 42 : 1812 - 195 - 2486(42.16% R-54.94) ✔元の値が42なので44±2に。 47 : 1839 - 187 - 2396(43.42% R-45.96) PARAM_FUTILITY_MARGIN_BETA: 133 : 1877 - 203 - 2418(43.7% R-44.0) ✔元の値が138なので136±2に。 138 : 1850 - 178 - 2459(42.93% R-49.43) 143 : 1755 - 180 - 2425(41.99% R-56.17) PARAM_FUTILITY_MARGIN_QUIET: 165 : 1108 - 115 - 1456(43.21% R-47.45) 170 : 1075 - 99 - 1495(41.83% R-57.29) 175 : 1129 - 102 - 1490(43.11% R-48.2) 180 : 1101 - 119 - 1423(43.62% R-44.57) ✔ ±5に。 185 : 1069 - 126 - 1438(42.64% R-51.51) PARAM_FUTILITY_AT_PARENT_NODE_MARGIN1: 105 : 1838 - 190 - 2487(42.5% R-52.53) 115 : 1815 - 156 - 2296(44.15% R-40.84) ✔ ±5に。 125 : 1829 - 215 - 2519(42.07% R-55.61) PARAM_FUTILITY_AT_PARENT_NODE_ALPHA: 112 : 1858 - 183 - 2432(43.31% R-46.77) 117 : 1851 - 179 - 2412(43.42% R-45.99) ✔元の値が122なので119±3に 122 : 1773 - 199 - 2458(41.9% R-56.75) PARAM_FUTILITY_AT_PARENT_NODE_GAMMA1: 25 : 1826 - 181 - 2441(42.79% R-50.43) 27 : 1794 - 177 - 2419(42.58% R-51.93) ✔ 元の値なので 29 : 1862 - 203 - 2442(43.26% R-47.11) PARAM_LMR_SEE_MARGIN1: 165 : 1775 - 171 - 2447(42.04% R-55.77) 175 : 1856 - 209 - 2470(42.9% R-49.65) 185 : 1851 - 181 - 2385(43.7% R-44.03) ✔ 元の値なので PARAM_REDUCTIONS_PARAM1: 2031 : 1134 - 97 - 1438(44.09% R-41.26) ✔ 2035 : 1139 - 110 - 1507(43.05% R-48.64) 2039 : 1040 - 124 - 1414(42.38% R-53.37) 2043 : 1060 - 119 - 1452(42.2% R-54.66) 2047 : 1109 - 111 - 1491(42.65% R-51.42) PARAM_REDUCTION_ALPHA: 1432 : 1835 - 180 - 2467(42.65% R-51.41) 1560 : 1823 - 187 - 2392(43.25% R-47.19) 1688 : 1824 - 194 - 2443(42.75% R-50.76) PARAM_REDUCTION_BETA: 663 : 1138 - 110 - 1489(43.32% R-46.7) 727 : 1089 - 105 - 1498(42.1% R-55.39) 791 : 1104 - 110 - 1401(44.07% R-41.39) ✔ 範囲を±32に。 855 : 1073 - 123 - 1425(42.95% R-49.29) 919 : 1078 - 113 - 1489(41.99% R-56.11) PARAM_REDUCTION_GAMMA: 561 : 1095 - 113 - 1457(42.91% R-49.62) 625 : 1177 - 123 - 1462(44.6% R-37.67) ✔ 範囲を±32に。 689 : 1058 - 89 - 1459(42.03% R-55.83) 753 : 1085 - 129 - 1441(42.95% R-49.29) 817 : 1067 - 107 - 1483(41.84% R-57.19) PARAM_NULL_MOVE_DYNAMIC_GAMMA: 142 : 1736 - 175 - 2406(41.91% R-56.7) 152 : 1860 - 194 - 2460(43.06% R-48.57) ✔ 元の値なので。157±5に。 162 : 1886 - 192 - 2436(43.64% R-44.45) PARAM_NULL_MOVE_MARGIN1: 22 : 1817 - 189 - 2468(42.4% R-53.2) 24 : 1830 - 176 - 2403(43.23% R-47.32) 26 : 1835 - 196 - 2431(43.01% R-48.86) PARAM_NULL_MOVE_MARGIN4: 251 : 1828 - 195 - 2462(42.61% R-51.72) 266 : 1808 - 191 - 2502(41.95% R-56.44) 281 : 1846 - 175 - 2338(44.12% R-41.05) ✔ 元の値なので。範囲を±10に。 PARAM_NULL_MOVE_RETURN_DEPTH: 12 : 1858 - 187 - 2348(44.17% R-40.66) ✔ 13 : 1804 - 207 - 2490(42.01% R-55.99) 14 : 1820 - 167 - 2464(42.48% R-52.63) PARAM_PROBCUT_MARGIN1: 158 : 1810 - 200 - 2411(42.88% R-49.81) 168 : 1797 - 178 - 2387(42.95% R-49.32) 178 : 1875 - 183 - 2504(42.82% R-50.25) PARAM_PROBCUT_MARGIN2: 60 : 1833 - 171 - 2442(42.88% R-49.83) 70 : 1777 - 199 - 2403(42.51% R-52.43) 80 : 1872 - 191 - 2457(43.24% R-47.24) PARAM_PROBCUT_MARGIN3: 406 : 1873 - 188 - 2373(44.11% R-41.1) ✔ 416 : 1805 - 167 - 2477(42.15% R-54.98) 426 : 1804 - 206 - 2452(42.39% R-53.31) PARAM_SINGULAR_MARGIN1: 64 : 1847 - 191 - 2441(43.07% R-48.44) ✔ 元の値なので。範囲を±4に。 72 : 1891 - 183 - 2456(43.5% R-45.41) 80 : 1744 - 187 - 2405(42.03% R-55.83) PARAM_SINGULAR_MARGIN2: 57 : 1886 - 193 - 2439(43.61% R-44.67) ✔ 元の値なので 範囲を±4に。 65 : 1806 - 195 - 2401(42.93% R-49.47) 73 : 1790 - 173 - 2462(42.1% R-55.37) PARAM_LMR_MARGIN1: 51 : 1813 - 177 - 2396(43.07% R-48.44) 55 : 1842 - 167 - 2335(44.1% R-41.2) ✔ 範囲を53±2に。元の値が51なので。 59 : 1827 - 217 - 2571(41.54% R-59.35) PARAM_LMR_MARGIN3: 500 : 1832 - 168 - 2436(42.92% R-49.5) 600 : 1798 - 189 - 2423(42.6% R-51.83) 700 : 1852 - 204 - 2443(43.12% R-48.11) ✔ 元の値が700なので PARAM_PRUNING_BY_HISTORY_DEPTH: 4 : 1767 - 188 - 2427(42.13% R-55.13) 5 : 1840 - 193 - 2424(43.15% R-47.89) 6 : 1875 - 180 - 2451(43.34% R-46.54) ✔ これ元の値なので.. PARAM_UPDATE_ALL_STATS_EVAL_TH: 75 : 1815 - 196 - 2431(42.75% R-50.76) 90 : 1833 - 187 - 2469(42.61% R-51.74) ✔ 範囲を±10に 105 : 1834 - 178 - 2402(43.3% R-46.87) PARAM_COUNTERMOVE_FAILLOW_MARGIN: 603 : 1804 - 189 - 2433(42.58% R-51.96) 653 : 1866 - 187 - 2443(43.3% R-46.8) ✔ 範囲を±25に 703 : 1812 - 185 - 2426(42.76% R-50.69) PARAM_ASPIRATION_SEARCH_DELTA: 8 : 1771 - 179 - 2495(41.51% R-59.54) 9 : 1902 - 203 - 2389(44.33% R-39.6) ✔ 10 : 1809 - 179 - 2418(42.8% R-50.41)
V7.72param1
- 探索パラメーターの調整その1。
- MOVE_PICKER_Q_PARAM1~4削除(掃除)
パラメーター調整の過程
- 1回目
total : 8472 - 598 - 11309(42.83% R-50.18)
total : 8472 - 598 - 11309(42.83% R-50.18)
PARAM_FUTILITY_MARGIN_ALPHA1:
116 : 2865 - 207 - 3748(43.32% R-46.67) ✔
126 : 2840 - 196 - 3810(42.71% R-51.04)
136 : 2767 - 195 - 3751(42.45% R-52.86)
PARAM_FUTILITY_MARGIN_ALPHA2:
32 : 2826 - 183 - 3825(42.49% R-52.58)
42 : 2858 - 191 - 3809(42.87% R-49.9) ✔ 動かすほどではない
52 : 2788 - 224 - 3675(43.14% R-47.99)
PARAM_FUTILITY_MARGIN_BETA:
133 : 2822 - 202 - 3801(42.61% R-51.74)
138 : 2889 - 204 - 3692(43.9% R-42.61) ✔ 動かすほどではない
143 : 2761 - 192 - 3816(41.98% R-56.22)
PARAM_FUTILITY_MARGIN_QUIET:
180 : 1698 - 110 - 2272(42.77% R-50.59)
190 : 1763 - 117 - 2275(43.66% R-44.29) ✔
200 : 1675 - 116 - 2304(42.1% R-55.39)
210 : 1646 - 125 - 2235(42.41% R-53.14)
220 : 1690 - 130 - 2223(43.19% R-47.62)
PARAM_FUTILITY_RETURN_DEPTH:
8 : 2841 - 190 - 3719(43.31% R-46.78)
9 : 2779 - 214 - 3802(42.23% R-54.45) ✔ どちらに動かしていいかわからない
10 : 2852 - 194 - 3788(42.95% R-49.3)
PARAM_FUTILITY_AT_PARENT_NODE_DEPTH:
12 : 2867 - 217 - 3758(43.28% R-47.01)
13 : 2793 - 194 - 3787(42.45% R-52.89) ✔ どちらに動かしていいかわからない
14 : 2812 - 187 - 3764(42.76% R-50.65)
PARAM_FUTILITY_AT_PARENT_NODE_MARGIN1:
105 : 2816 - 199 - 3766(42.78% R-50.5)
115 : 2851 - 200 - 3750(43.19% R-47.61) ✔ 動かすほどではない
125 : 2805 - 199 - 3793(42.51% R-52.42)
PARAM_FUTILITY_AT_PARENT_NODE_ALPHA:
117 : 2858 - 195 - 3809(42.87% R-49.9)
122 : 2767 - 221 - 3735(42.56% R-52.11) ✔ どちらに動かしていいかわからない
127 : 2847 - 182 - 3765(43.06% R-48.55)
PARAM_FUTILITY_AT_PARENT_NODE_GAMMA1:
25 : 2855 - 196 - 3706(43.51% R-45.32)
27 : 2757 - 194 - 3763(42.29% R-54.04) ✔ どちらに動かしていいかわからない
29 : 2860 - 208 - 3840(42.69% R-51.19)
PARAM_LMR_SEE_MARGIN1:
165 : 2816 - 204 - 3707(43.17% R-47.76)
185 : 2765 - 190 - 3752(42.43% R-53.03) ✔ どちらに動かしていいかわからない
205 : 2891 - 204 - 3850(42.89% R-49.77)
PARAM_REDUCTIONS_PARAM1:
2029 : 2750 - 197 - 3804(41.96% R-56.36)
2037 : 2856 - 220 - 3774(43.08% R-48.42)
2045 : 2866 - 181 - 3731(43.44% R-45.82) ✔
PARAM_REDUCTION_ALPHA:
1024 : 2724 - 194 - 3826(41.59% R-59.02)
1432 : 2840 - 203 - 3764(43.0% R-48.93)
1560 : 2908 - 201 - 3719(43.88% R-42.73) ✔
PARAM_REDUCTION_BETA:
663 : 2883 - 187 - 3720(43.66% R-44.28) ✔
791 : 2778 - 193 - 3802(42.22% R-54.51)
919 : 2811 - 218 - 3787(42.6% R-51.77)
PARAM_REDUCTION_GAMMA:
817 : 2855 - 200 - 3641(43.95% R-42.25) ✔
945 : 2802 - 203 - 3880(41.93% R-56.55)
1073 : 2815 - 195 - 3788(42.63% R-51.57)
PARAM_NULL_MOVE_DYNAMIC_GAMMA:
142 : 2951 - 200 - 3664(44.61% R-37.59) ✔
152 : 2825 - 195 - 3879(42.14% R-55.08)
162 : 2696 - 203 - 3766(41.72% R-58.06)
PARAM_NULL_MOVE_MARGIN1:
22 : 2808 - 214 - 3796(42.52% R-52.37)
24 : 2806 - 196 - 3739(42.87% R-49.87) ✔ 動かすほどではない
26 : 2858 - 188 - 3774(43.09% R-48.3)
PARAM_NULL_MOVE_MARGIN4:
251 : 2870 - 208 - 3718(43.56% R-44.97) ✔ 前バージョンがもっと低い値だったので
281 : 2834 - 196 - 3721(43.23% R-47.3)
311 : 2768 - 194 - 3870(41.7% R-58.22)
PARAM_NULL_MOVE_RETURN_DEPTH:
13 : 2825 - 214 - 3770(42.84% R-50.13)
14 : 2770 - 181 - 3708(42.76% R-50.66) ✔ 動かすほどではない
15 : 2877 - 203 - 3831(42.89% R-49.75)
PARAM_PROBCUT_MARGIN1:
158 : 2767 - 194 - 3767(42.35% R-53.59)
168 : 2847 - 216 - 3714(43.39% R-46.18) ✔
178 : 2858 - 188 - 3828(42.75% R-50.76)
PARAM_PROBCUT_MARGIN2:
60 : 2923 - 212 - 3658(44.42% R-38.97) ✔
70 : 2805 - 179 - 3906(41.8% R-57.52)
80 : 2744 - 207 - 3745(42.29% R-54.03)
PARAM_PROBCUT_MARGIN3:
80 : 15 - 1 - 55(21.43% R-225.71)
406 : 2816 - 202 - 3851(42.24% R-54.38)
416 : 2796 - 190 - 3715(42.94% R-49.37)
426 : 2845 - 205 - 3688(43.55% R-45.08) ✔ 前バージョンでもっと大きな値だったので
PARAM_SINGULAR_MARGIN1:
56 : 2827 - 214 - 3695(43.35% R-46.52)
64 : 2745 - 185 - 3738(42.34% R-53.64) ✔ singularはあとで調整する
72 : 2900 - 199 - 3876(42.8% R-50.39)
PARAM_SINGULAR_MARGIN2:
49 : 2823 - 219 - 3834(42.41% R-53.18)
57 : 2814 - 198 - 3809(42.49% R-52.59) ✔ singularはあとで調整する
65 : 2835 - 181 - 3666(43.61% R-44.66)
PARAM_LMR_MARGIN1:
47 : 2809 - 196 - 3775(42.66% R-51.35)
51 : 2783 - 170 - 3791(42.33% R-53.7) ✔ 動かすほどでもなさげ
55 : 2880 - 232 - 3743(43.48% R-45.53)
PARAM_LMR_MARGIN2:
9 : 2820 - 205 - 3765(42.82% R-50.21)
10 : 2805 - 191 - 3813(42.38% R-53.33) ✔ depth調整はあとで。
11 : 2847 - 202 - 3731(43.28% R-46.98)
PARAM_LMR_MARGIN3:
600 : 2847 - 189 - 3764(43.06% R-48.5)
700 : 2756 - 210 - 3827(41.87% R-57.03) ✔ どちらに動かしていいかわからない
800 : 2869 - 199 - 3718(43.56% R-45.03)
PARAM_PRUNING_BY_HISTORY_DEPTH:
5 : 2816 - 205 - 3747(42.91% R-49.62)
6 : 2816 - 199 - 3825(42.4% R-53.2) ✔ depthはあとで
7 : 2840 - 194 - 3737(43.18% R-47.68)
PARAM_UPDATE_ALL_STATS_EVAL_TH:
10 : 1671 - 91 - 2259(42.52% R-52.38)
40 : 1723 - 125 - 2300(42.83% R-50.18)
90 : 1715 - 122 - 2229(43.48% R-45.54) ✔ このへんが最適くさい。
140 : 1675 - 121 - 2263(42.53% R-52.27)
190 : 1688 - 139 - 2258(42.78% R-50.54)
PARAM_COUNTERMOVE_FAILLOW_MARGIN:
603 : 2864 - 192 - 3753(43.28% R-46.96)
653 : 2865 - 187 - 3770(43.18% R-47.69) ✔ 20ほど減らしてみる
703 : 2743 - 219 - 3786(42.01% R-55.98)
PARAM_ASPIRATION_SEARCH_DELTA:
9 : 2897 - 195 - 3723(43.76% R-43.58) ✔
10 : 2780 - 204 - 3772(42.43% R-53.01)
11 : 2795 - 199 - 3814(42.29% R-54.0)
V7.72x2
-
探索パラメーター、PARAM_REDUCTIONS_PARAM1追加。
-
探索パラメーター、PARAM_NULL_MOVE_MARGIN0削除
-
探索パラメーター、初期値をいったん調整。
-
持ち時間制御のパラメーター調整。
- Time management improvements : https://github.com/official-stockfish/Stockfish/commit/cf3dbcb5acd66efaaa84fa1e24ce7afb062fba08
engine1 = YaneuraOuNNUE_V772t_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V772x2_1024.exe , eval = Li T2,b1000,393 - 26 - 401(49.5% R-3.5[-23.77,16.77]) winrate black , white = 50.25% , 49.75% T2,b2000,186 - 18 - 176(51.38% R9.6[-20.41,39.61]) winrate black , white = 53.04% , 46.96%
V7.72w
-
MovePickerでGenerateAllLegalMovesがオンの時、ProbCutとqsearchの時にも歩の成らずを生成していたの修正。
-
PARAM_FUTILITY_MARGIN_QUIET、118→200に変更。
→ GenerateAllLegalMoves = trueでどれだけレーティングが下がるのかあとで計測する。
V7.72v
- UnitTestに通常プレイヤーでの対局オプションを追加した。 例) unittest auto_player_loop 100000 auto_player_depth 16
=== Start UnitTest === random_player_loop : 0 lnsg1g1nl/4k1sb1/p1pppp3/8p/9/PP5R1/BpPPPPP1P/9/LNSGKGSNL w 3Pr 228g8h:0:21261
デバッグ用コード。 static int c = 0; c++; if (c==21261) { std::cout << "21261" << std::endl; }
if (!pos.capture_or_pawn_promotion(move))
{
std::cout << pos.sfen() << move << ":" << pos.capture_or_pawn_promotion(move) << ":" << c << std::endl;
}
V7.72u
- UnitTestのランダムプレイヤーでの対局、0回が指定されてたらskipするようにした。 例) unittest random_player_loop 100000 unittestの一部として、ランダムプレイヤー同士の対局を10万回やる
- "unittest"コマンドでASSERT_LV5にしているとassertに引っかかるの修正。 pseudo_legal_check() 修正。
V7.72t
-
futilityBaseの計算式変更。式の単純化。
-
Simplify futilityBase formula : https://github.com/official-stockfish/Stockfish/commit/b7b7800e2b752c93131e03c31d7456f18b392a7c
engine1 = YaneuraOuNNUE_V772s_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V772t_1024.exe , eval = Li T2,b1000,1449 - 85 - 1466(49.71% R-2.03[-12.61,8.56]) winrate black , white = 52.8% , 47.2% T2,b2000,1439 - 106 - 1455(49.72% R-1.92[-12.54,8.7]) winrate black , white = 51.66% , 48.34% → 悪くはなさそう
PARAM_FUTILITY_MARGIN_QUIET = 118→200に。
V7.72s
-
best threadのvoteアルゴリズム変更。
engine1 = YaneuraOuNNUE_V772r_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V772s_1024.exe , eval = Li T2,b1000,1367 - 94 - 1539(47.04% R-20.59[-31.21,-9.97]) winrate black , white = 52.24% , 47.76% T2,b2000,1443 - 138 - 1419(50.42% R2.91[-7.77,13.59]) winrate black , white = 52.27% , 47.73%
→ 1秒では少しつよくなったが…?
V7.72r
-
MovePicker、GOOD_CAPTUREの式変更。 return pos.see_ge(*cur, Value(-69 * cur->value / 1024)) ? ↓ return pos.see_ge(*cur, Value(-cur->value)) ?
-
windows large pageの使用コード刷新。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V772r_1024.exe , eval = Li T2,b1000,1512 - 115 - 1373(52.41% R16.75[6.1,27.4]) winrate black , white = 51.2% , 48.8%
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V772r_1024.exe , eval = Li T2,b1000,1659 - 87 - 1254(56.95% R48.62[37.93,59.31]) winrate black , white = 51.29% , 48.71%
V7.72q
- singular extensionの説明追加。
- Stockfish 2023/10/21時点までcatch up。
- Fix greater than TB scores in null move pruning. : https://github.com/official-stockfish/Stockfish/commit/a4fedd8152e717a37ec8b8ddda0658364c1f5ee4
- Removing history condition : https://github.com/official-stockfish/Stockfish/commit/90c18b0b500a5226717353a37a82cd026d71b616
- Subtract the margin from the value returned by ProbCut : https://github.com/official-stockfish/Stockfish/commit/e18619d07802882136b583a01e56791b61abede6
- Scale down stat bonus : https://github.com/official-stockfish/Stockfish/commit/8366ec48ae6fc57dffad849b20844d5b07f963b4
V7.72p
-
MovePickerのType == CAPTURESの重み変更。
-
MovePickerのType == QUIETSに2手前のhistoryの値加算。
-
MovePicekrのType == EVASIONSの重み変更。
-
cf. Use more continuation histories. : https://github.com/official-stockfish/Stockfish/commit/38e830af4bfa6c9e9c11279a8e6a60b6ca4ec2cd
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V772p_1024.exe , eval = Li T2,b1000,1640 - 92 - 1268(56.4% R44.69[34.01,55.37]) winrate black , white = 52.37% , 47.63%
→ めっちゃ弱くなった。なんぞこれ…。suishoとの差だったのか…。 いずれにせよ、パラメーター調整しないと使い物にならないということがわかった。
→ あとでわかったことだが、MovePickerのcaptureの計算式間違っていた。
V7.72o2
-
rootより遡って優等局面の判定をしなくした。
-
自己対局でたまにtimeoutになる。アクセス違反の可能性があるか…。
bench 4096 4 900 // 15分×4 = 60分
Total time (ms) : 3600046 Nodes searched : 460349637 Nodes_searched/second : 127873 Nodes searched (main thread) : 115249189 Nodes searched/second(main thread) : 32013
The bench command has completed.
=========================== Total time (ms) : 3600005 Nodes searched : 10921071099 Nodes_searched/second : 3033626 Nodes searched (main thread) : 2735260403 Nodes searched/second(main thread) : 759793
The bench command has completed.
engine1 = YaneuraOuNNUE_V772n_1024.exe , eval = Li
engine2 = YaneuraOuNNUE_V772o2_1024.exe , eval = Li
T2,b1000,2945 - 163 - 2892(50.45% R3.15[-4.33,10.63]) winrate black , white = 51.89% , 48.11%
T2,b2000,2874 - 252 - 2874(50.0% R-0.0[-7.54,7.54]) winrate black , white = 52.78% , 47.22%
→ この改造によってほぼ弱くはなっていないことが確認できた。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503
engine2 = YaneuraOuNNUE_V772o2_1024.exe , eval = Li
T2,b1000,1478 - 130 - 1392(51.5% R10.41[-0.26,21.08]) winrate black , white = 51.85% , 48.15%
// 771a-suishoが弱いだけで..
Wrong evaluation #264の件。 https://github.com/yaneurao/YaneuraOu/issues/264
優等局面のテスト局面 position sfen l5snl/3k5/1pnsg1b2/p1ppp1g1p/5pp2/PPP1P4/2SP5/K1GB5/LNG4+r1 w 2Prsnl3p 78 moves 4e4f 6h4f P4e position sfen 6lll/6pnk/8p/7P1/7S1/9/9/7NP/6NGK b SP2r2b3g2snl13p 1 moves 2d2c+ 1b2c P2d position sfen kl7/1l7/Pn7/S8/9/9/9/7PP/6NLK b SP2r2b4g2s2nl14p 1 moves 9c9b+ 9a9b
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li
engine2 = YaneuraOuNNUE_V772o2_1024.exe , eval = Li
T2,b1000,1580 - 92 - 1328(54.33% R30.18[19.55,40.82]) winrate black , white = 52.34% , 47.66%
→ あれ?この時点で弱くないか?
V7.72o
-
優等局面の判定、やめてみた。
engine1 = YaneuraOuNNUE_V772n_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V772o_1024.exe , eval = Li T2,b1000,2973 - 201 - 2826(51.27% R8.81[1.3,16.32]) winrate black , white = 53.06% , 46.94% T2,b2000,2926 - 250 - 2824(50.89% R6.16[-1.37,13.7]) winrate black , white = 51.7% , 48.3% T2,b4000,2886 - 329 - 2785(50.89% R6.19[-1.4,13.78]) winrate black , white = 52.16% , 47.84%
R7ぐらい下がってるな…。
V7.72n
-
excludedMoveがある時のTT.probe()の処理、変更。
-
1手詰め、宣言勝ちの処理に関してexcludedMoveがあるケースを除外していなかったの修正。
-
置換表に宣言勝ちの指し手を書き出さなくしたので置換表から読みだした指し手が宣言勝ちであるかの判定コードなど掃除した。
-
cf. https://github.com/official-stockfish/Stockfish/commit/8d3457a9966f8c744ab7f8536be408196ccd8af9
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V772n_1024.exe , eval = suisho20230503 T2,b1000,1667 - 94 - 1239(57.36% R51.55[40.83,62.26]) winrate black , white = 51.1% , 48.9% T2,b2000,543 - 33 - 404(57.34% R51.37[32.6,70.13]) winrate black , white = 52.16% , 47.84% T4,b1000,1429 - 104 - 1177(54.83% R33.7[22.46,44.95]) winrate black , white = 52.0% , 48.0% T4,b4000,125 - 12 - 93(57.34% R51.37[12.32,90.42]) winrate black , white = 55.5% , 44.5%
→ めっさ弱いのだが…。 → 他の評価関数でもテストするか.. Liでテストする。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V772n_1024.exe , eval = Li T2,b1000,1455 - 105 - 1440(50.26% R1.8[-8.82,12.42]) winrate black , white = 52.12% , 47.88%
→ Liだと弱くならないな…。そうか…。
Liは学習時にLabel Smoothingしているから絶対値が小さいのか…。 水匠、FV_SCALE 32とかにすべきか?
水匠とLiとの比較。 engine1 = YaneuraOuNNUE_V772n_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V772n_1024.exe , eval = Li T2,b1000,1297 - 110 - 1593(44.88% R-35.71[-46.4,-25.03]) winrate black , white = 52.25% , 47.75%
FV32との比較。 engine1 = YaneuraOuNNUE_V772n_1024.exe , eval = suisho20230503FV32 engine2 = YaneuraOuNNUE_V772n_1024.exe , eval = Li T2,b1000,1042 - 98 - 1220(46.07% R-27.4[-39.45,-15.35]) winrate black , white = 51.02% , 48.98%
V7.72m
- history statsに関して添字をStockfishから入れ替えている件、search.cppにコメントをかなり追加した。
-
棋力に影響する変更はしてない。(つもり)
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V772m_1024.exe , eval = suisho20230503 T2,b1000,1463 - 99 - 1438(50.43% R2.99[-7.61,13.6]) winrate black , white = 50.43% , 49.57%
// Liとの比較 engine1 = YaneuraOuNNUE_V772m_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V772m_1024.exe , eval = Li T2,b1000,1297 - 134 - 1569(45.25% R-33.07[-43.79,-22.35]) winrate black , white = 51.99% , 48.01%
-
V7.72l
-
Position::update_slider_blockers()、逆手番側の香にしてしまっていた。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V772l_1024.exe , eval = suisho20230503 T2,b1000,1413 - 94 - 1493(48.62% R-9.57[-20.17,1.04]) winrate black , white = 53.3% , 46.7% T4,b1000,1482 - 105 - 1413(51.19% R8.28[-2.34,18.91]) winrate black , white = 52.78% , 47.22%
V7.72k
- mainHistory[m][c]の順なのに逆にしてる箇所があったの修正。
- Stockfishとやねうら王とでこれを逆順にしているのがこういう間違いをする原因。
- captureHistoryもそう。
- bench完走しない。原因調査中。
V7.72j
- Position::set_state()の引数StateInfo*を削除。
- Position::set_check_info()の引数StateInfo*を削除。
- Position::update_slider_blockers()追加。
V7.72i
-
Position::pieces()にvariadic template導入
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V772i_1024.exe , eval = suisho20230503 T2,b1000,828 - 63 - 799(50.89% R6.19[-7.97,20.36]) winrate black , white = 51.87% , 48.13%
// Liとの比較 engine1 = YaneuraOuNNUE_V772i_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V772i_1024.exe , eval = Li T2,b1000,1264 - 170 - 1566(44.66% R-37.22[-48.02,-26.42]) winrate black , white = 51.31% , 48.69%
V7.72h
-
didLMR削除
-
doFullDepthSearch追加
-
LMRの処理、刷新。
-
maxNextDepth移動。 // 次の最大探索深さ。 // これを超える深さでsearch()を再帰的に呼び出さない。 // 延長されすぎるのを回避する。 const Depth maxNextDepth = rootNode ? depth : depth + 1;
-
PARAM_FUTILITY_AT_PARENT_NODE_GAMMA2削除。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V772h_1024.exe , eval = suisho20230503 T2,b1000,1395 - 96 - 1509(48.04% R-13.65[-24.26,-3.03]) winrate black , white = 52.44% , 47.56% T2,b2000,1462 - 133 - 1405(50.99% R6.91[-3.77,17.58]) winrate black , white = 50.19% , 49.81% T4,b1000,1474 - 130 - 1396(51.36% R9.44[-1.22,20.11]) winrate black , white = 52.51% , 47.49% T4,b2000,1469 - 158 - 1373(51.69% R11.74[1.02,22.46]) winrate black , white = 54.05% , 45.95%
→ 以前のバージョンより強なった?😍
engine1 = YaneuraOuNNUE_V772h_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V772h_1024.exe , eval = Li T2,b1000,1065 - 119 - 1316(44.73% R-36.76[-48.54,-24.99]) winrate black , white = 50.9% , 49.1%
V7.72g
-
reductionの条件色々追加。
-
LMRの式、修正。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V772g_1024.exe , eval = suisho20230503 T2,b1000,1838 - 107 - 1055(63.53% R96.44[85.4,107.47]) winrate black , white = 51.88% , 48.12% → めっさ弱なった。
V7.72f
-
singularQuietLMR導入。
-
singular extensionの実装、更新。
-
singular extensionにかなりコメント追加。
-
singular negative extension追加。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V772f_1024.exe , eval = suisho20230503 T2,b1000,1721 - 91 - 1188(59.16% R64.39[53.61,75.16]) winrate black , white = 51.05% , 48.95% → 少しよわなった。
V7.72e
-
singular extensionの条件式、少し変更。
-
singular extensionのsingularBetaの式を変更。
-
PARAM_SINGULAR_EXTENSION_DEPTH削除。
-
PARAM_SINGULAR_MARGINのスケール変更。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V772e_1024.exe , eval = suisho20230503 T2,b1000,1697 - 94 - 1209(58.4% R58.9[48.15,69.65]) winrate black , white = 51.0% , 49.0%
V7.72d
-
Step 11.ProbCutの条件式、変更。
- ProbCutのTTへの保存条件、変更。
-
PARAM_PROBCUT_DEPTH削除。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V772d_1024.exe , eval = suisho20230503 T2,b1000,1696 - 85 - 1219(58.18% R57.37[46.64,68.1]) winrate black , white = 51.56% , 48.44% → だいぶ弱なった。
V7.72c
-
fallingEvalの算出式、変更。
- これ持ち時間制御が絡むから棋力計測が不可能。
-
aspiration searchのwindowの縮める式、 delta += delta / 4 + 2; ↓ delta += delta / 3; に変更。
-
aspiration searchの初期値の計算式、変更。 // Reset aspiration window starting size if (rootDepth >= 4) { Value prev = rootMoves[pvIdx].averageScore; delta = Value(16) + int(prev) * prev / 19178; alpha = std::max(prev - delta,-VALUE_INFINITE); beta = std::min(prev + delta, VALUE_INFINITE);
// Adjust trend and optimism based on root move's previousScore int tr = sigmoid(prev, 3, 8, 90, 125, 1); trend = (us == WHITE ? make_score(tr, tr / 2) : -make_score(tr, tr / 2)); int opt = sigmoid(prev, 8, 17, 144, 13966, 183); optimism[ us] = Value(opt); optimism[~us] = -optimism[us]; }
↓ Value prev = rootMoves[pvIdx].averageScore; delta = Value(10) + int(prev) * prev / 17470; alpha = std::max(prev - delta,-VALUE_INFINITE); beta = std::min(prev + delta, VALUE_INFINITE);
// Adjust optimism based on root move's previousScore (~4 Elo) int opt = 113 * prev / (std::abs(prev) + 109); optimism[ us] = Value(opt); optimism[~us] = -optimism[us];
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V772c_1024.exe , eval = suisho20230503 T2,b1000,1632 - 108 - 1260(56.43% R44.94[34.23,55.65]) winrate black , white = 51.76% , 48.24% → ちょっと弱なった?
V7.72b
-
fail lowを引き起こしたcounter moveに対するbonusの式、変更。
-
PARAM_NULL_MOVE_DYNAMIC_ALPHA,BETA削除
-
Null move dynamic reduction based on depth and evalの計算式、変更。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V772b_1024.exe , eval = suisho20230503 T2,b1000,1613 - 103 - 1284(55.68% R39.63[28.94,50.31]) winrate black , white = 52.09% , 47.91% → ちょっと強くなった。
V7.72a
-
Stack::cutoffCnt導入。
-
razaringにcutoffCnt使用
-
alpha値を更新した時に残りの指し手の探索深さを減らす
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V772a_1024.exe , eval = suisho20230503 T2,b1000,1655 - 88 - 1257(56.83% R47.79[37.1,58.47]) winrate black , white = 50.38% , 49.62%
→ ちょっとだけつよなった。
// Liとの比較 engine1 = YaneuraOuNNUE_V772a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V772a_1024.exe , eval = Li T2,b1000,1375 - 79 - 1546(47.07% R-20.36[-30.95,-9.77]) winrate black , white = 52.07% , 47.93%
V7.71z
-
MOVE_WINの指し手、置換表に書き出さないことにした。
-
Step 12. A small Probcut ideaの前提depth変更。
-
PARAM_PROBCUT_MARGIN3追加。
-
ProbCutの直後にあったttMoveがないときのreduction、ProbCutの前に移動。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V771z_1024.exe , eval = suisho20230503 T2,b1000,1679 - 87 - 1234(57.64% R53.49[42.78,64.21]) winrate black , white = 50.77% , 49.23%
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V771z_1024.exe , eval = Li T2,b1000,974 - 75 - 731(57.13% R49.86[35.88,63.84]) winrate black , white = 50.32% , 49.68% → この時点ですでにめっちゃ弱くなっている。
V7.71y
-
stat_bonusの変更。 return std::min((9 * d + 270) * d - 311 , 2145); ↓ return std::min(334 * d - 531, 1538);
-
コメントなど修正。(棋力には影響しないはず)
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V771y_1024.exe , eval = suisho20230503 T2,b1000,1673 - 93 - 1234(57.55% R52.87[42.15,63.59]) winrate black , white = 52.15% , 47.85%
V7.71x
-
Step 8. Futility pruningの条件調整。
-
PARAM_FUTILITY_RETURN_DEPTH 8→9に変更
-
futility_margin関数、更新。
// Futility margin Value futility_margin(Depth d, bool improving) { return Value(168 * (d - improving)); } ↓ Value futility_margin(Depth d, bool noTtCutNode, bool improving) { return Value((126 - 42 * noTtCutNode) * (d - improving)); }
-
PARAM_FUTILITY_MARGIN_ALPHA2追加。
→ futility、マージン値を調整しないとめっさ弱くなる。あとで調整する。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503
engine2 = YaneuraOuNNUE_V771x_1024.exe , eval = suisho20230503
T2,b1000,1669 - 98 - 1233(57.51% R52.6[41.87,63.33]) winrate black , white = 53.76% , 46.24%
V7.71w
-
CounterMovePruneThreshold削除
-
Stack::Depth削除
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V771w_1024.exe , eval = suisho20230503 T2,b1000,792 - 27 - 581(57.68% R53.82[38.22,69.42]) winrate black , white = 53.61% , 46.39% T4,b1000,634 - 48 - 488(56.51% R45.47[28.27,62.67]) winrate black , white = 51.87% , 48.13%
V7.71v
-
PARAM_QUIET_TT_EXTENSION追加。
-
指し手の合法性チェックをする箇所を移動。
-
置換表によるbeta cutに関してnull moveの条件を追加。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V771v_1024.exe , eval = suisho20230503 T2,b1000,1011 - 57 - 762(57.02% R49.12[35.41,62.82]) winrate black , white = 51.1% , 48.9% T4,b1000,581 - 52 - 457(55.97% R41.7[23.85,59.56]) winrate black , white = 52.89% , 47.11%
V7.71u
-
check extensionの条件、端折る。
-
SQ_NONE定義追加。
-
fail lowを引き起こした1手前のcountermoveに対するボーナスで1手前のMOVE_NULLを考慮するようにした。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V771u_1024.exe , eval = suisho20230503 T2,b1000,1629 - 106 - 1265(56.29% R43.93[33.23,54.64]) winrate black , white = 50.41% , 49.59% T4,b1000,1644 - 125 - 1231(57.18% R50.26[39.49,61.03]) winrate black , white = 52.1% , 47.9%
V7.71t
- ttPvまわりのコード、整理。 engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V771t_1024.exe , eval = suisho20230503 T2,b1000,1635 - 98 - 1267(56.34% R44.3[33.6,54.99]) winrate black , white = 51.93% , 48.07% T4,b1000,1635 - 126 - 1239(56.89% R48.18[37.42,58.94]) winrate black , white = 50.56% , 49.44%
V7.71s
-
quietsSearched[64]→[32]に。
-
benchコマンドの局面を無名namespaceに入れた。 → quiet減らしているので将棋ではちょっと悪化するのか…。 あとで調整しないとな…。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V771s_1024.exe , eval = suisho20230503 T2,b1000,1630 - 102 - 1258(56.44% R45.0[34.28,55.72]) winrate black , white = 52.15% , 47.85% T4,b1000,1643 - 129 - 1228(57.23% R50.58[39.8,61.35]) winrate black , white = 51.1% , 48.9%
V7.71r
- usi.hでNormalizeToPawnValueを使っているところでtanuki-mateなどのビルドがこけてたの修正。
V7.71q
-
変数improvementの削除。
-
PARAM_NULL_MOVE_MARGIN2使ってなかったので削除。
-
PARAM_NULL_MOVE_MARGIN3削除。
-
以下をroll back。(V7.71p2の実験より) else if (excludedMove) { // Providing the hint that this node's accumulator will be used often brings significant Elo gain (~13 Elo)
//Eval::NNUE::hint_common_parent_position(pos); // TODO : → 今回のNNUEの計算は端折れるのか? eval = ss->staticEval; }
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V771q_1024.exe , eval = suisho20230503 T2,b1000,1117 - 56 - 837(57.16% R50.13[37.07,63.19]) winrate black , white = 50.46% , 49.54% T4,b1000,491 - 40 - 399(55.17% R36.04[16.79,55.29]) winrate black , white = 50.45% , 49.55% T4,b1000,485 - 31 - 404(54.56% R31.74[12.51,50.98]) winrate black , white = 52.53% , 47.47%
V7.71p4
-
ThreadPoolを以下のようにroll back
//Thread* operator[](size_t n) { return threads[n];}
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V771p4_1024.exe , eval = suisho20230503 T2,b1000,1213 - 46 - 701(63.38% R95.26[81.7,108.81]) winrate black , white = 53.5% , 46.5% → 関係なかった。
V7.71p3
-
Reductionsを以下のようにroll back for (int i = 1; i < MAX_MOVES; ++i) Reductions[i] = int(20.81 * std::log(i));
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V771p3_1024.exe , eval = suisho20230503 T2,b1000,1244 - 64 - 642(65.96% R114.91[101.03,128.8]) winrate black , white = 51.96% , 48.04% → ちょっと悪化したな…。
V7.71p2
-
以下をroll back
else if (excludedMove) { // Providing the hint that this node's accumulator will be used often brings significant Elo gain (~13 Elo) //Eval::NNUE::hint_common_parent_position(pos); // TODO : → 今回のNNUEの計算は端折れるのか? eval = ss->staticEval; }
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V771p2_1024.exe , eval = suisho20230503 T2,b1000,1137 - 57 - 856(57.05% R49.31[36.39,62.24]) winrate black , white = 52.28% , 47.72% → これが原因っぽいのだが、なぜに…。
V7.71p
-
探索部のcomplexityという変数に関するコード掃除。
-
staticEvalに関する部分のコード、整理。
-
棋力に影響する部分はいじってないつもりだが、レーティング計測する。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V771p_1024.exe , eval = suisho20230503 T2,b1000,1860 - 92 - 1048(63.96% R99.66[88.63,110.7]) winrate black , white = 51.65% , 48.35% T2,b2000,756 - 52 - 412(64.73% R105.45[87.96,122.94]) winrate black , white = 53.25% , 46.75% → めっちゃ弱くなってた。何か変数の初期化を忘れているのか?
V7.71o
- ThreadPoolクラスがvector<Thread*>から派生しなくなって、Threads[n]という書き方がコンパイルエラーになっていたのを修正。
- EVAL_LEARN版のビルドでこけてたのはこれが原因。
- 棋力に影響する修正ではない。
V7.71n3
-
Reduction tableの初期化、以下のタイミングではThreads.size() == 0だったので、これをsearch::clear()に移動させた。 for (int i = 1; i < MAX_MOVES; ++i) Reductions[i] = int((20.37 + std::log(THREAD_SIZE) / 2) * std::log(i));
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V771n3_1024.exe , eval = suisho20230503 T2,b1000,1621 - 102 - 1277(55.94% R41.44[30.75,52.13]) winrate black , white = 51.73% , 48.27% T4,b1000,1344 - 106 - 1070(55.68% R39.61[27.9,51.31]) winrate black , white = 52.82% , 47.18% T8,b1000,618 - 68 - 514(54.59% R32.01[14.96,49.06]) winrate black , white = 52.21% , 47.79% → スレッド数が上がると差が縮むのは単に置換表サイズが相対的に小さくなるからか? それともReductionsにTHREAD_SIZEが影響するようにしたため、Lazy SMPの性能が上がったからか?
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V771n3_1024.exe , eval = Li T2,b1000,799 - 40 - 561(58.75% R61.43[45.7,77.17]) winrate black , white = 50.51% , 49.49% → この時点でめっさ弱いな…。reductionsテーブル書き換えたからか…。
V7.71n2
-
Reduction tableのパラメーター更新だけroll backする。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V771n2_1024.exe , eval = suisho20230503 T2,b1000,1168 - 81 - 911(56.18% R43.17[30.54,55.8]) winrate black , white = 52.0% , 48.0%
→ やはり、これが原因で壊していたことがわかった。
V7.71n
-
Reduction table、パラメーター更新。
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V771n_1024.exe , eval = suisho20230503 T2,b1000,2300 - 67 - 633(78.42% R224.13[211.31,236.95]) winrate black , white = 50.73% , 49.27%
→ これThreads.size()がまだ探索スレッド数になっていないタイミングで初期化してた。修正。 log(0) == - ∞ なので、テーブルおかしな値で初期化してた。
V7.71m
-
qsearch、step 5.~step 9.までコード修正した。qsearchの修正完了した。
-
CapturePieceValueEg → CapturePieceValuePlusPromoteと名前変更。
FV_SCALE = 24 engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V771m_1024.exe , eval = suisho20230503 T2,b1000,1624 - 96 - 1280(55.92% R41.35[30.67,52.03]) winrate black , white = 51.27% , 48.73%
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V771m_1024.exe , eval = Li T2,b1000,1666 - 111 - 1223(57.67% R53.7[42.94,64.46]) winrate black , white = 50.61% , 49.39% → クソ弱くなってる。
V7.71l
-
qsearch、step 1.~step 4.までコード修正した。
- prevSq、ここでもMOVE_NULL考慮するようにした。
-
update_all_stats()のパラメーターPAWN_VALUEを外だしした。→ PARAM_UPDATE_ALL_STATS_EVAL_TH
FV_SCALE = 24 engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V771h_1024.exe , eval = suisho20230503 T2,b1000,1601 - 105 - 1294(55.3% R36.98[26.3,47.66]) winrate black , white = 51.74% , 48.26%
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V771l_1024.exe , eval = suisho20230503 T2,b2000,1035 - 100 - 835(55.35% R37.3[24.01,50.59]) winrate black , white = 52.41% , 47.59%
V7.71k
-
update_all_stats()で直前の指し手がMOVE_NULLの時、continuation_historiesを更新しないことにした。
-
update_all_stats()のrefactoring
-
check_time、1024回に1回のチェックを512回に1回に変更。
FV_SCALE = 16 engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V771k_1024.exe , eval = suisho20230503 T2,b1000,1620 - 114 - 1266(56.13% R42.83[32.12,53.55]) winrate black , white = 51.11% , 48.89%
FV_SCALE = 24 engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V771k_1024.exe , eval = suisho20230503 T2,b1000,1627 - 114 - 1259(56.38% R44.54[33.82,55.27]) winrate black , white = 50.03% , 49.97%
V7.71j
-
定数VALUE_KNOWN_WIN削除
- ちょっと枝刈りの挙動が変わったかも。
-
null moveの適用depth、13未満→14未満に変更。
-
MSVCでwarning 4127,4146,4800の抑制。
-
typedefのところusingで書き直す。
FV_SCALE = 16 engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V771j_1024.exe , eval = suisho20230503 T2,b1000,1633 - 93 - 1274(56.17% R43.13[32.45,53.81]) winrate black , white = 52.53% , 47.47%
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V771j_1024.exe , eval = Li T2,b1000,1618 - 98 - 1284(55.75% R40.17[29.49,50.84]) winrate black , white = 51.83% , 48.17%
V7.71i
-
Thread::nmpColor削除。
- これでnull moveの挙動がちょっと変わる。
FV_SCALE = 16 engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V771i_1024.exe , eval = suisho20230503 T2,b1000,1592 - 111 - 1297(55.11% R35.6[24.91,46.29]) winrate black , white = 52.41% , 47.59%
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V771i_1024.exe , eval = Li T2,b1000,1643 - 99 - 1258(56.64% R46.38[35.68,57.09]) winrate black , white = 51.57% , 48.43%
→ このcommit周辺でさらにR20ぐらい弱くなっている。これ探索の挙動ほぼ変わらないはずなのに…。 → 間違えてnull move pruningの前提条件 && beta > VALUE_TB_LOSS_IN_MAX_PLY この条件消してた。これ、betaがかなり大きい時にしか適用されないはずの枝刈りなのに…。
V7.71h
-
movepick.hのButterflyHistoryのサイズ半分に…。 typedef Stats<int16_t, 14365, COLOR_NB, int(SQUARE_NB) * int(SQUARE_NB)> ButterflyHistory; ↓ using ButterflyHistory = Stats<int16_t, 7183, COLOR_NB, int(SQUARE_NB) * int(SQUARE_NB)>;
-
MovePickerのsearchのProbCutから呼び出されるコンストラクタ、Depthを引数に渡すのやめる。
FV_SCALE = 16 engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V771h_1024.exe , eval = suisho20230503 T2,b1000,1610 - 113 - 1277(55.77% R40.25[29.55,50.96]) winrate black , white = 52.58% , 47.42%
FV_SCALE = 24 engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V771h_1024.exe , eval = suisho20230503 T2,b1000,1672 - 92 - 1236(57.5% R52.49[41.77,63.2]) winrate black , white = 51.38% , 48.62%
engine1 = YaneuraOuNNUE_V771h_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V771h_1024.exe , eval = Li T2,b1000,1301 - 116 - 1583(45.11% R-34.08[-44.77,-23.39]) winrate black , white = 53.26% , 46.74%
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V771h_1024.exe , eval = Li T2,b1000,1578 - 111 - 1311(54.62% R32.2[21.53,42.88]) winrate black , white = 52.27% , 47.73%
V7.71g
-
RunningAverageクラス削除。
-
Position::capture_state()、ダミーコード追加。
-
misc.hのmul_hi64、typedefをusingに変更。
FV_SCALE = 16 engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V771g_1024.exe , eval = suisho20230503 T2,b1000,1536 - 107 - 1357(53.09% R21.52[10.88,32.17]) winrate black , white = 50.88% , 49.12%
FV_SCALE = 24 engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V771g_1024.exe , eval = suisho20230503 T2,b1000,1574 - 108 - 1318(54.43% R30.84[20.17,41.5]) winrate black , white = 51.69% , 48.31%
engine1 = YaneuraOuNNUE_V771g_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V771g_1024.exe , eval = Li T2,b1000,1322 - 135 - 1543(46.14% R-26.85[-37.56,-16.15]) winrate black , white = 50.86% , 49.14%
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V771g_1024.exe , eval = Li T2,b1000,1546 - 108 - 1346(53.46% R24.07[13.42,34.72]) winrate black , white = 52.63% , 47.37% → この時点で少し弱いな..
V7.71f
- move_pickerの静止探索の時に以下の条件を置換表の指し手を無視する条件に使っていたのをやめるようにした。
- (pos.checkers() || depth > DEPTH_QS_RECAPTURES || to_sq(ttm) == recaptureSquare)
- move_pickerの静止探索のpartial_insertion_sortのlimitが
depth * 3000だったのを以下のようint::minに変更。
-
partial_insertion_sort(cur, endMoves, std::numeric_limits::min());
- ほとんどがsortされるので、super sortのほうが有利か?
- captureの指し手がそんなに無数にある状況が珍しいので、あんまりか…。
FV_SCALE = 16 engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V771f_1024.exe , eval = suisho20230503 T2,b1000,1541 - 109 - 1350(53.3% R22.99[12.34,33.64]) winrate black , white = 52.89% , 47.11%
-
少し弱くなった…。他の枝刈り入れて調整してから考えよう…。
engine1 = YaneuraOuNNUE_V771f_1024.exe , eval = suisho20230503
engine2 = YaneuraOuNNUE_V771f_1024.exe , eval = Li
T2,b1000,1328 - 149 - 1523(46.58% R-23.8[-34.53,-13.07]) winrate black , white = 51.95% , 48.05%
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li
engine2 = YaneuraOuNNUE_V771f_1024.exe , eval = Li
T2,b1000,1562 - 109 - 1329(54.03% R28.06[17.4,38.72]) winrate black , white = 51.44% , 48.56%
→ これでR30近く弱くなってるな…。なんぞこれ…。
→ 間違えてcaptureではなくquietの指し手を全数sortするようにしてた。そら弱くなるわ…。
V7.71e
-
move_picker.h 整理
-
thread.h 整理
-
position.h 整理
engine1 = YaneuraOuNNUE_V771e_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V771e_1024.exe , eval = Li T2,b1000,1365 - 133 - 1502(47.61% R-16.61[-27.3,-5.93]) winrate black , white = 51.2% , 48.8%
FV_SCALE = 24? engine1 = YaneuraOuNNUE_V771e_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V771e_1024.exe , eval = Li T2,b1000,1323 - 133 - 1544(46.15% R-26.83[-37.54,-16.13]) winrate black , white = 53.4% , 46.6%
engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = Li engine2 = YaneuraOuNNUE_V771e_1024.exe , eval = Li T2,b1000,1439 - 103 - 1458(49.67% R-2.28[-12.89,8.34]) winrate black , white = 51.33% , 48.67% → この時点では棋力ダウンは生じていない
V7.71d
- thread_win32_osx.h、古い書き方になってたところ修正。
- ThreadPoolを vectorから派生させるのをやめる。
V7.71c
- エンジンオプションのThreads(探索スレッド数)の最大を1024に変更。
- Tools::memclearに__EMSCRIPTEN__のコード移動させた。
- tt.h / tt.cpp 、型castの書き方など修正。
- indent揃ってなかったところ微修正。
V7.71b
-
RootMoveにscoreLowerboundとscoreUpperboundを追加。RootMove::score→usiScoreに追加。
-
USI::pv()の引数のalpha,beta削除。
engine1 = YaneuraOuNNUE_V771b_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V771b_1024.exe , eval = Li T2,b1000,1325 - 114 - 1561(45.91% R-28.47[-39.15,-17.8]) winrate black , white = 51.07% , 48.93%
V7.71a
-
経過時間が短い時も置換表使用率を出力するようにした。
-
USI::NormalizeToPawnValue
Liとの比較 engine1 = YaneuraOuNNUE_V771a_1024.exe , eval = suisho20230503 engine2 = YaneuraOuNNUE_V771a_1024.exe , eval = Li T2,b1000,1318 - 127 - 1555(45.88% R-28.73[-39.42,-18.03]) winrate black , white = 53.57% , 46.43%
-
Fix wasm build #265 thanks to WandererXII
USE_PTHREADS is deprecated - https://github.com/emscripten-core/emscripten/blob/main/ChangeLog.md#3134---031423 TOTAL_STACK was renamed to STACK_SIZE - https://github.com/emscripten-core/emscripten/blob/main/ChangeLog.md#3125---110822 LLD_REPORT_UNDEFINED was removed, it's always default now - https://github.com/emscripten-core/emscripten/blob/main/ChangeLog.md#3125---110822 -march=wasm32 throws errors, so I just removed it I tested k-p version and it worked.
-
ふかうら王でResign_Thresholdが反映していなかったの修正。
- thanks to Qhapaqさん、たややんさん
・テストしたコマンド
resign_threshold 600 pv_interval 100 isready go
bestmove resign
- VSでふかうら王のデバッグビルドができなくなっていたの修正。
- ランタイムライブラリとして「マルチスレッド デバッグ (/MTd)」を選ばないとダメ。
- makebook peta_shock_nextで指定した局面数だけ書き出せない時にフリーズしていたのを修正。
- makebook peta_shock_nextでrootの指し手を書き出した時にその次の指し手が書き出せずにフリーズしていたのを修正。
- makebook peta_shock_nextでBOOK_VALUE_NONEは考慮しないことにした。
-
makebook peta_shockコマンドで、エンジンオプションのFlippedBookがtrueの時は、先手番の局面しか書き出さないようにした。
- 後手番の局面はそれをflipした局面が書き出されているので、実際に使う時にFlippedBookをtrueにしておけば、後手番は、反転された先手の局面にhitするはずだから。
-
FlippedBook エンジンオプション追加。
- 反転させた局面が定跡DBに登録されていたら、それにヒットするようになるオプション。デフォルトtrue。
-
BookOnTheFlyで定跡DBに局面が1つしか無い時にhitしないことがあったバグ修正。
-
BookOnTheFlyで最後に登録されている局面にhitした時に空の指し手が返っていたの修正。(illegal moveのチェックで弾かれていたので実害はなかったが)
-
やねうら王の定跡DBで指し手かponderの指し手に"None"("none"ではなく)が書かれているかの判定追加。
-
Position::flip()廃止
-
Position::flipped_sfen()追加
- makebook peta_shockで、千日手スコアを0以外に変更した時の手順の改善。
- 前回の // 3. 評価値とDrawStateも同じ場合、評価値が正ならdepthが小さいほうが優れている。 // 4. 評価値とDrawStateも同じ場合、評価値が負ならdepthが大きいほうが優れている。 この部分を 3. 「評価値が正なら」→「評価値がdraw_value(千日手スコア)より大きいなら」 4. 「評価値が負なら」→「評価値がdraw_value(千日手スコア)より小さいなら」 に変更。
- makebook peta_shockで、千日手手順の改善。
同じ評価値を持つ指し手が2つある時にどちらが優れているかについて、 以下の3.,4.のアルゴリズム的な改良をした。
// 優れているかの比較
// 1. 評価値が優れている。
// 2. 評価値が同じ場合、DrawStateが優れている
// 3. 評価値とDrawStateも同じ場合、評価値が正ならdepthが小さいほうが優れている。
// 4. 評価値とDrawStateも同じ場合、評価値が負ならdepthが大きいほうが優れている。
//
// 3., 4.の理屈としては、同じ評価値を持つ2つのノード(two nodes with the same value)問題があることを発見したからだ。
// いま
// A→B→C→D→A
// A→E→F→G
// B→X
// のような経路があるとする。
//
// X,Gは同じ評価値でAの手番側から見て100であり、Aの手番側はここを目指すとする。
// A→B→XはAからXに2手でvalue=100にいける。
// A→E→F→GはAからGに3手でvalue=100にいける。
// Aの手番を持たされた側は、depthが小さいからと言ってA→Bを選ぶとBの手番側がXに行く手を選択せずにCに行く手を選択してしまう。
// そうするとC→D→AとAに戻ってきて千日手になる。
// Bの手番側は、B→C→D→A→E→F→Gのコースを選んだほうが得なので、depthの大きい側を選ぶべきなのである。
// この理屈から、評価値が正のほうは、千日手を回避するためにdepthが小さいほうを目指すが(親にそれを伝播する)、
// 評価値が負のほうは、千日手にするためにdepthが大きいほうを目指す(親にそれを伝播する)べきなのである。
// ゆえに、評価値の正負によって、どちらのdepthの指し手を選ぶかが変わるのである。
-
やねうら王の定跡DBにhitした時のPV出力を修正。
- ponderが登録されていない定跡で定跡にhitした時に"none"と出力されていたの修正。
- 千日手に突入した時にその時のponderがさらに出力されていたの修正。
// テスト用 bookfile user_book1.db bookonthefly true bookmoves 999 bookpvmoves 4 ignorebookply true isready usinewgame position startpos moves 7g7f 8c8d 2g2f 8d8e 8h7g 3c3d 7i6h 2b7g+ 6h7g 3a2b 3g3f 7c7d 6i7h 4a3b 1g1f 7a7b 3i3h 2b3c 4g4f 1c1d 9g9f 5a4b 3h4g 9c9d 2i3g 6c6d 5i6h 7b6c 4i4h 8a7c 6g6f 6c5d 2h2i 6a6b 4g5f 8b8a 2f2e go
-
角歩の不成を含む詰みが読めない #257 問題を修正
- https://github.com/yaneurao/YaneuraOu/issues/257
- 以前のcommitで壊していた。rollbackした。
- GenerateAllLegalMovesオプションをオンにした時に「駒を取る手 + 歩の成り」と「駒を取らない手 + 歩の不成」を分けて生成したいのだが、これが現状の指し手生成ルーチンでは難しい。templateの特殊化を頑張ればできるのだが、ここをそんなに頑張っても仕方ないので(ふだん使う機能ではないし、バグらないように書くのむずいし、どうせ指し手オーダリングがきちんとしていればほとんど効率落ちないし)いまのままにしておく。
-
ふかうら王、UCT_NodeLimitの下限を100000→10に変更。
- issue : https://github.com/yaneurao/YaneuraOu/issues/263
- UCT_NodeLimitの最小値は1000に変更。(これくらいでもいまどきのモデルならわりと強いだろうし、省メモリで動かしたいことがないわけでもなさそうだし。)
issueでUCT_NodeLimitの値が反映していないのではないかと言われたがそんなことはなかった。 → NodesLimitオプションがあるのでノードを制限したい時はそちらを用いればいいと思う。
-
makebook2023.cpp、gccでコンパイルエラーになっていたの修正。
-
makebook peta_shockコマンド、盤面反転のことをreverse positionではなくflipped positionと書くようにしたる
- makebook peta_shockコマンド、peta_shock_nextコマンド、flipさせた(180°回転させた)局面も定跡として書き出すようにした。
- flip_move(Move16)追加
- Position::flip()追加
- Position::sfen(gamePly)でgamePlyが負なら手数を書き出さないようにした。
- MemoryBook::merge()追加
-
makebook peta_shock_nextコマンド、同じsfenを複数書き出すことがあったのを改善。
-
makebook peta_shock_nextコマンド、PVじゃないところ選んでいたの修正。
-
makebook peta_shock_nextコマンド、手数bonusを指定できるようにした。
-
makebook peta_shockコマンド、DrawState導入。
ペタショック化した定跡のdepthの説明
9999 : 抜け出せないループ
+10000 : 先手は千日手を打開する権利を持っていない。
+20000 : 後手は千日手を打開する権利を持っていない。
例
39999 : 先手も後手も千日手を打開する権利を持っていない千日手ループ
10010 : 先手は千日手を打開できず、後手は千日手を打開して10手後に末端の局面に到達することができる。
- makebook peta_shockコマンド、draw valueが反映されていなかったの修正。
- makebook peta_shock_nextコマンド、MAX_PLYの判定忘れていた。修正。
-
makebook peta_shock_nextコマンドが循環を削除する時に循環のすべてが削除対象となると永久に終了しないバグ修正。
-
makebook peta_shock_nextコマンド、千日手がPVになった時にそれを回避するようにした。
- これにより千日手を以外のPV leafが選ばれてそこを掘っていくようになる。
- min-maxした時のPV leafを掘っていくと、いずれPVが千日手循環になってしまいPV leafが得られなくなる。これを回避するためにPVが千日手循環になった時に、その循環にいたる指し手を削除するようにして千日手以外の周辺PVを探索するようにした。
-
makebook peta_shock_nextコマンド追加。
- 定跡で次に掘るべき局面のsfenを書き出す。
- min-maxのPV leaf node、そして、そのleaf nodeが消滅した時のPV leaf nodeと、そしてそのleaf nodeが(以下繰り返し) を書き出す。
-
SystemIO::WriteAllLines()追加。
- ペタショック定跡の後退解析II、すべてのnodeのbest valueの変化がなくなった時点で終了するように改善。(nodchipさんのアイデア)
-
ペタショック定跡の後退解析、3つのフェーズに分けた。
-
ペタショック化コマンド、循環があるほうの評価値を-1しておく処理が間違っていたの修正。
-
定跡のペタショック化コマンドの追加。
例:
makebook peta_shock book.db peta_shock.db
book/book.db が book/peta_shock.db に変換される。
ふかうら王をUbuntu上でビルドするためにMakefile修正。
vector::resize()を呼び出すべきところをreserve()を呼び出していた。
halfkp_1024x2-8-32 halfkp_512x2-16-32 を追加した #261
Fix compile error #253
- https://github.com/yaneurao/YaneuraOu/pull/253
- Clang14でコンパイル時に警告が出ていたのを修正。