SSE無しの時に領域外アクセスで異常終了していたので調べてみると、
Bitboardのシフト演算が逆になっているようです。

Pullリクエストは使い方がよくわからないのでIssueで失礼します。

diff --git a/source/bitboard.h b/source/bitboard.h
index 6429786..648a238 100644
--- a/source/bitboard.h
+++ b/source/bitboard.h
@@ -121,7 +121,7 @@ struct alignas(16) Bitboard
Bitboard& operator -= (const Bitboard& b1) { this->p[0] -= b1.p[0]; this->p[1] -= b1.p[1]; return *this; }

Bitboard& operator <<= (int shift) { ASSERT_LV3(shift == 1); this->p[0] <<= shift; this->p[1] <<= shift; return *this; }

• Bitboard& operator >>= (int shift) { ASSERT_LV3(shift == 1); this->p[0] <<= shift; this->p[1] <<= shift; return *this; }
• Bitboard& operator >>= (int shift) { ASSERT_LV3(shift == 1); this->p[0] >>= shift; this->p[1] >>= shift; return *this; }
  #endif

tanuki_MATE-tournament-clang++-zen2.exe and YaneuraOu_MATE-tournament-clang++-zen2.exe say this tsume is 13 moves long when it is actually 3 moves long.
sfen 5pk2/7P1/4+R1+P1+b/8b/6R2/9/9/9/9 b 4g4s4n4l15p 1

最新のバイナリlearn_avx2＋Kristallweizen評価関数でのことです。
いくつかの局面で定跡を掘った際に「none none 0 0 1」などの行が出ることがあります。
multipv 3の4行目に出たりするので余計なものと思います。

局面依存があるかどうか分かりませんが例えば以下の局面depth28で出ました。
sfen sn1gk3l/4s4/p2pp1+P1p/1p3+b1r1/9/2P+BLp3/PG1PP3P/3K1PS2/LNS1GG1NL w Prn4p 74

現在のソースコードは、インデントだけでも tab、2space、4space が混在しており、pull requestを送ったりする際に何に合わせたら良いのか分からなくなる状況です。

そういや、やねうら王は基本4 tabです。スペースに変換されているところがいくつかあるかもですが、基本4 tabで、NNUEとかプルリクもらったままマージしたので2 tabになっている箇所がありますが、何か手を入れたときに 4 tab化してます。
// 2 tabのままになっているのは私がまだ未踏の地だということですね。

という話ですが、そういう所を手伝うにしても、ソースコードの整形部分ばかりでdiffが膨れ上がってしまうので支障が大きそうです。

clang-format などの整形ツールで使えるようなルールの作成を進められないものでしょうか。

参考:

• Google C++ スタイルガイド 日本語全訳
• ClangFormatスタイルオプション
• source/eval/nnue/ 以下に clang-format を適用した例:
  • Google C++ スタイルガイドに近い形 ( + Includeのソート無し、1行の文字数制限無し)
    clang-format -style="{BasedOnStyle: Google, SortIncludes: false, ColumnLimit: 0}"
  • インデント幅4
    clang-format -style="{BasedOnStyle: Google, SortIncludes: false, ColumnLimit: 0, IndentWidth: 4}"
  • インデント幅4, タブ幅4, インデントにタブ使用
    clang-format -style="{BasedOnStyle: Google, SortIncludes: false, ColumnLimit: 0, IndentWidth: 4, TabWidth: 4, UseTab: ForIndentation }"
  • インデント幅4, タブ幅4, インデントと継続行の字下げにタブ使用
    clang-format -style="{BasedOnStyle: Google, SortIncludes: false, ColumnLimit: 0, IndentWidth: 4, TabWidth: 4, UseTab: ForContinuationAndIndentation }"

nodestimeを使おうとすると1手目はちゃんと指定した時間考えてくれますが2手目からノータイムで指すようになってしまいます。
その手を指すために思考したノード数ではなく通算のノード数をカウントしてしまっているのでは？

Does YaneuraOu support the modern CPU architecture? These are the parameters: https://github.com/official-stockfish/Stockfish/blob/754fc8a8b5ca7466926d54465eeb1df4d4a481ac/src/Makefile#L172-L177 . If I’m right YaneuraOu doesn’t support popcnt Architecture.

現状の問題

• 詰むはずなのに不詰と返す局面がある
• df-pnの最適化では攻め側が手数を最短にするように最善を尽くさないことに起因して、本来早詰めの変化が想定解よりも長い詰み手数になってしまってる可能性がある

詰まない局面の例

barcodehair様より

解けない詰将棋はいろいろありそうです。少し試しただけですが、以下の２つは解けませんでした。
（本当は詰むのに短時間で不詰を返す）
馬鋸の例題
sfen 7k1/5+Bp2/7Ss/9/9/9/1n7/9/9 b 2rb4g2s3n4l17p 1
使用駒9枚長手数 (https://www.ne.jp/asahi/tetsu/toybox/challenge/c1056.htm)
sfen 1+P2l4/2P6/9/p5+R2/2k6/B3+P3B/9/9/9 b r4g4s4n3l14p 1

また、以下の問題は明らかにおかしな手順を解答します。玉方がループを避けているように見えます。
以前のバージョンでは正しく解答するようなので、デグレかもしれません。
sfen 4+P+P+P+P1/+P1+P5+P/7kP/PP5pp/1+P2+P1pP1/6+P1+P/9/9/9 b 2r2b4g4s4n4l 1

今後作りたいもの（上にあるものほど先に作る？）

詰み局面、不詰局面の検証エンジン

• go mateコマンドやgoコマンドに対してbestmoveを返すようにする。詰む局面では詰ませるための手を、詰まない局面では逃れるための手を返すようにする

局面合流に強いというWPNS

https://www.researchgate.net/publication/220962458_Weak_Proof-Number_Search

劣等局面を使った高速化

https://tadaoyamaoka.hatenablog.com/entry/2018/05/20/150355

Hello yaneurao!

Someone said: "YaneuraOu also cannot run without evaluation parameters, which have to be downloaded from another Google Drive. Unfortunately the zip file is 5.7GB. This might take me several hours. I dread to see how large it will get when I unzip it. As the evaluation parameters probably have to be in memory, it is likely that YaneuraOu cannot run on a machine with less than 16GB RAM. My biggest machine has 8GB."

Well I own a desktop computer with Windows 7 SP1 64 bit and the following components:

Intel Core i5 3470 @ 3.20GHz Ivy Bridge 22nm Technology> .bmi2.executables are not supported
4,00GB RAM Dual-Channel DDR3 @ 798MHz (11-11-11-28)
Motherboard ASRock H61M-DGS R2.0 (CPUSocket)

Where can be found the exact download link of the evaluation parameters on Google Drive? Has this connection a torrent-file for the download procedure? I cannot find these necessary informations.
Are 5,7 GB data volume indeed required to run YaneuraOu with a GUI respectively it is possible for you to develop Yaneura Ou program without evaluation parameters like other USI engines?

WinBoard 4.8.0 graphical interface is able to use USI compatible engines cf. http://home.hccnet.nl/h.g.muller/shokidoki.html and
http://www.open-aurec.com/wbforum/viewtopic.php?f=19&t=51528 plays normal chess , Japanese / Chinese and many other variants.

終盤だけに特化したソフトは作れますか。
従来のソフトで序盤や中盤は十分強いので。

On the most recent version (5.33), and since v5.30 or v5.21, there seem to be a problem when evaluating some positions with a time limit.

Position: sfen l6nl/6k2/+P3p2p1/1B1p1Pp1p/1p7/7nP/3P1SP1L/2+p3GK1/L6+r1 b B2G2S5Prgs2np 0

Expected evaluation: mate -8

v4.91-v5.20 evaluation (byoyomi 20000): mate -8
v.5.30-v5.33 evaluation (byoyomi 20000): cp 1953 (info depth 2 seldepth 3 score cp 1953 nodes 616 nps 205333 time 3)
v.5.30-v5.33 evaluation (go infinite): mate -8 (info depth 17 seldepth 9 score mate -8 nodes 26057 nps 2368818 time 11)

This is problematic for game analysis, as it shows a very high score (winning) when it should be very low (losing).

Example session:
Built with "make tournament", eval function elmo_wcsc29
Reproduced on two different computers

Bad session (v5.30)

usi
id name YaneuraOu NNUE 5.30 64AVX2BMI2 TOURNAMENT
(...)
usiok
isready
info string Hash table allocation: Linux Large Pages used.
info string eHash Clear begin , Hash size =  1024[MB]
info string USI_Hash Clear begin , Hash size =  16[MB]
(...)
readyok
position sfen l6nl/6k2/+P3p2p1/1B1p1Pp1p/1p7/7nP/3P1SP1L/2+p3GK1/L6+r1 b B2G2S5Prgs2np 0
go btime 0 wtime 0 byoyomi 20000
info depth 1 seldepth 1 score cp 345 nodes 178 nps 89000 time 2 pv 2h2i
info depth 2 seldepth 3 score cp 1953 nodes 616 nps 205333 time 3 pv 2h2i 2f3h+ 4g3h
bestmove 2h2i ponder R*1i

Good session (v5.20)

usi
id name YaneuraOu NNUE 5.20 64AVX2BMI2 TOURNAMENT
(...)
usiok
isready
info string Hash table allocation: Linux Large Pages used.
info string eHash Clear begin , Hash size =  1024[MB]
info string Hash Clear begin , Hash size =  16[MB]
(...)
readyok
position sfen l6nl/6k2/+P3p2p1/1B1p1Pp1p/1p7/7nP/3P1SP1L/2+p3GK1/L6+r1 b B2G2S5Prgs2np 0
go btime 0 wtime 0 byoyomi 20000
info depth 1 seldepth 1 score cp 345 nodes 176 nps 88000 time 2 pv 2h2i
info depth 2 seldepth 3 score cp 1953 nodes 395 nps 197500 time 2 pv 2h2i 2f3h+ 4g3h
info depth 16 seldepth 9 score mate -8 nodes 23394 nps 2126727 time 11 pv 2h2i R*1i 2i2h S*3i 2h2g 1i1h+ 2g2f G*3e
bestmove 2h2i ponder R*1i

learn shuffleコマンドで、シャッフルする局面数が10Mの倍数でない場合にシャッフル結果に偏りが出るようです。例えば10M+1局面シャッフルした場合、10M局面のふぁいると1局面のファイルが生成されます。これらのファイルからランダムにファイルを選択し、局面を書き出していった場合、1局面しか無いファイルの局面がかなりの確率でファイルの先頭に来てしまいます。お手すきの際に確認をお願いできませんでしょうか？よろしくお願いいたします。

本バグはynasu87さんより教えて頂きました。

定跡hit時info出力でのpvの位置が最後になっていません。
USIプロトコルでは、pvは他のサブコマンド（depth, score cpなど）よりも後に書くようにしなければならない認識なのですが、これは意図したものでしょうか。
cf. http://shogidokoro.starfree.jp/usi.html

• 現在の定跡hit時におけるinfo出力例

  info pv 2g2f 3c3d 7g7f 8c8d 2f2e 8d8e 2e2d 2c2d (4.17%) score cp 59 depth 33 multipv 1
  info pv 7g7f 4a3b 2g2f 8c8d 2f2e 8d8e 8h7g 3c3d (4.17%) score cp 51 depth 25 multipv 2
  info pv 6i7h 8c8d 2g2f 3c3d 7g7f (4.17%) score cp 46 depth 3 multipv 3
  info pv 3i4h 3c3d 6i7h 8c8d (4.17%) score cp 34 depth 2 multipv 4
  info pv 4i5h 4a3b (4.17%) score cp 30 depth 0 multipv 5
  

gensfenコマンドを実行し、数万局面生成した段階で落ちます。(スレッド数を変えても同様)
VS2019でデバック実行したところ、affine_transform.h 105行目でアクセス違反が発生しました。
また、このときproduct m256i_i8 と m256i_u8の要素に全角文字が含まれおり、文字列中に無効な文字があると警告が出ています。

実行環境
OS : Windows 10 1903
CPU : Ryzen7 3700X
RAM : 32 GB

学習時、「Error! : evaluate memory is corrupted」と表示されます。
5c8a039 からのコミットで発生します。

また、benchやgensfenでは起こりません。

実行環境

• OS
  CentOS 7.3
• メモリ
  64GB
• 使用コンパイラ
  gcc 6.2.1

すみません質問なのですが・・・

Android版をビルドして動作確認したのですがよく使われているShogiDroidというアプリだと一部の設定が正常に動かないことが分かりました。
調べてみるとShogiDroidの作者の方はOwnBookを追加してSkillLevelをUSI_SKillLevelに変更してビルドしているということが分かりました。
やねうら王の側のオプション名を変更するのはまずいのでしょうか？

http://siganus.php.xdomain.jp/phpBB3/viewtopic.php?t=347

投稿記事by 管理人 » 2019年1月03日(木) 15:54

オプションのネーミングは一応USIは規約があって、定跡のON/OFFはUSI_OwnBookという名前になってます。
ShogiDroidではこれに元になったチェスのOwnBookにも対応してます。

SkillLevelはUSI側にないので（USI_Strengthという似たようなものはある）、
StockfishのSKill LevelとそれをUSI風のUSI_SKillLevelに対応しています。

基本的にGUI側に共通設定を持っておくオプションは規約にそったほうがよいかと、
なのでこれらはGUI側ではなく、エンジン側でオプション名を合わせたほうがよいと思います。

KOMA型のやねうら王を見ていて思ったのですが、駒の価値は本当にこれでいいのでしょうか。
元々は、駒の価値がおかしくても(SEEなどを除けば)KKPによって学習した値が加算されるので気にする必要がないということで、Aperyの平岡さんが雰囲気で決めた値だったはず。

他のソフトを調べてみると、技巧ではparams.binに学習した駒の価値が入っています。

#include "evaluation.h"
int main(void) {
std::unique_ptr g_eval_params(new EvalParameters);
std::FILE* fp = std::fopen("params.bin", "rb");
std::fread(g_eval_params.get(), sizeof(EvalParameters), 1, fp);
std::fclose(fp);
for (PieceType pt : Piece::all_piece_types())
std::printf("%s %d\n", Piece(kBlack, pt).ToSfen().c_str(), g_eval_params->material[pt]);
}

として技巧2のparams.binから取り出した値とやねうら王(Apery)の値を大雑把にスケールを合わせて比較してみます。

駒　技巧　やねうら王
歩兵　99　83
香車　265　289
桂馬　286　372
銀将　441　455
金将　521　496
角行　668　786
飛車　729　910
と金　615　496
成香　540　496
成桂　569　496
成銀　573　496
龍馬　957　868
龍王　1096　1282

こうしてみると、やねうら王は歩や金を過小評価し、大駒を過大評価していることが分かります。
実際の例でいうと例えば飛と金桂の2枚替えをしたときなどに逆転現象が起きています。

KPPTなどの既存の評価関数はこれまでの駒の価値を前提に学習しているので変更するとまずいようにも思いますが、KOMA型は技巧の値にしたほうが強くなるのではないでしょうか。
人間が見た場合に分かりやすい100刻みの数値とした場合でも、金を上げて大駒を下げて歩100　香300　桂400　銀500　金600　角800　飛900　と600　杏600　圭600　全600　馬1100　龍1200くらいにしたほうが適切な値に近くなります。

Hi Yaneurao,

just wanted to quickly ask if there are any plans for supporting tsume shogi with this engine? Right now if you set a tsume position the app just crashes.

for example this:
position sfen 7nl/9/5S1kp/6R1s/9/7p1/9/9/9 b Gr2b3g2s3n3l16p

Regards,
Stefan

いつもお世話になっております。
LONG_EFFECT_LIBRARYを有効にしてソースコードをビルドしようとすると、mate1ply_with_effect.cppにおいてコンパイルエラーが起きます。
8ffbaa0
上記のコミットでHandKindを削除したのが原因だと思います。お手すきの際に修正をお願いできませんでしょうか？
よろしくお願いいたします。

gensfen does not compile at https://github.com/ddugovic/YaneuraOu/runs/1298212578?check_suite_focus=true#step:7:60

cd script && ./build.sh -a SSE41 -c g++ -e YANEURAOU_ENGINE_KPP_KKPT -t gensfen
...
usi.cpp:(.text+0x7e8b): undefined reference to `Learner::gen_sfen2019(Position&, std::__cxx11::basic_istringstream<char, std::char_traits<char>, std::allocator<char> >&)'

Do you have plans that your engine will support Mini-Shogi (via USI-protocol) on a 5x5 board, too?
http://hgm.nubati.net/rules/Mini.html
https://sites.google.com/view/minishogi/tournaments/1st-msca-championships

いつもお世話になっております。
王手のかかっている局面をPosition::set_from_packed_sfen()で読むと、Position::pos_is_ok()がfalseを返します。内部でst->checkersBBが0となっているためのようです。
Position::set_from_packed_sfen()内で、 set_state(st) 後に pdate_bitboards() していますが、pdate_bitboards() 後に set_state(st) を呼ぶのが正しいのでしょうか…？

お手すきの際に確認・修正いただければ幸いです。よろしくお願いいたします。

Learner::qsearch() および Learner::search() で ss->pv = pv; でPV格納用のバッファのアドレスを格納したあと、init_for_search()内でmemset()で0クリアしています。このためYaneuraOu2017Early::qsearch()内でnullポインタアクセスを起こし、プログラムがクラッシュします。

お手すきの際に確認・修正頂けませんでしょうか？よろしくお願いいたします。

バグと思われる内容

カンマ演算子の左右の評価順序は環境依存のはず。
そのため、pop_backが先に評価されて、メモリリークが発生する。

問題の場所

https://github.com/yaneurao/YaneuraOu/blob/master/source/thread.cpp#L97

void ThreadPool::set(size_t requested)
{
	if (size() > 0) { // いったんすべてのスレッドを解体(NUMA対策)
		main()->wait_for_search_finished();

		while (size() > 0)
			delete back(), pop_back();   <-これ
	}

解決方法

カンマ演算子で連結せずに独立した文にする。

入玉ルールでトライルールを選択している場合、一手でトライが可能な局面になってもやねうら王はトライをしません。
また、対戦相手がトライをしても対局終了になりません。
検討モードでもトライの指し手だけ表示されません。

以下の詰将棋がメモリ１６GBの設定で解けません。
sfen 3+R1gknl/4+B1s2/6pp1/5p3/8p/9/9/9/9 b RSNPb3g2s2n3l13p 1

合駒なども出てこないので、このメモリ量で解けないのはさすがに変だと思います。
ちなみに、tanuki詰や脊尾詰なら一瞬で解けます。

I was looking at the learning code ported to stockfish, and I was wondering what the purpose of https://github.com/yaneurao/YaneuraOu/blob/master/source/learn/learner.cpp#L644-L648 is and whether it could be replaced by simply clamping search_depth to always be positive?

test.sfen:

lnsgkgsnl/1r5b1/ppppppppp/9/9/9/PPPPPPPPP/1R5R1/LNSGKGSNL b - 1

#!/bin/bash
../script/build.sh -a AVX2 -c clang++ -e MATE_ENGINE -t normal && \
../build/linux/MATE/tanuki_MATE-linux-clang++-normal-AVX2 bench 16 1 5 test.sfen depth

We at Lishogi.org are requesting a YaneuraOu version that is runnable in the browser. Theoretically, this would be possible with WASM and Emscripten. Emscripten is a toolkit that compiles, with a few modifications, C or C++ code to WASM, and thus allows running those programs in the browser, inside a webpage. WASM is already supported by new versions of Firefox, Chrome, Safari, and Edge. Something similar has already been done with an NNUE chess engine by Hiroshi Ogawa (Github repo), who compiled the Stockfish NNUE to WASM. And so Lichess.org implemented it on their website and made a blog post about it. Please do try it out in this example game (works best with Chrome/Chromium).

We would like to request this YaneuraOu client-side version for the purposes of our Shogi site. A very strong engine like YaneuraOu running in the browser would be highly beneficial towards Lishogi players, who will be able to use it to analyse their own games right after playing it. Currently our browser analysis is running Fairy-Stockfish which is good in the endgame but does not do well in the opening and middlegame. Of course, we will also give proper credit, following the GPLv3 license.

Hello, when I use ShogiGUI to run 6.0.3 nnue's avx2 or any other exe, initialization failure is displayed in the software window. When I change to Shogidokoro to run the software, the operation failure message displayed at the bottom is: Hash table allocation: Windows Large Pages not used. Excuse me, where did the settings go wrong? My CPU is 8750h supports avx2, and everything goes well when running stockfish 14. Thank you for your answer.

https://github.com/yaneurao/YaneuraOu/actions/workflows/make.yml

For example https://github.com/yaneurao/YaneuraOu/runs/2496128375?check_suite_focus=true

/usr/bin/ld: cannot find -lomp
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [Makefile:465: YaneuraOu-by-gcc] Error 1
make: *** [Makefile:482: evallearn] Error 2
make[1]: Leaving directory '/home/runner/work/YaneuraOu/YaneuraOu/main/source'
Error: Process completed with exit code 2.

再現性が高いわけではないのですが、
YaneuraOu_6.03_NNUE-tournament-clang++-avx2において、
sfen l5snl/1r1gk1gb1/p1nspp1pp/2pp5/1pP3R2/6P2/PPSPPP2P/1BG1K1S2/LN3G1NL w 2P 28
や
sfen l6nl/1r1gksgb1/2ns1p1p1/p1p1p1P2/3p4p/PPR6/2SPPPNSP/1BG1KG3/LN6L w 4P 46
のような局面等で、後手番の読み筋に8三飛車成や8一飛車成といった非合法手が読み筋に入ってしまうといった不具合があるようです。不具合は後手番の読み筋でしか起こらず、かつ、飛車成に関する不具合である確率が高いようです（私自身は再現できておりませんが、7六歩、3四歩、2六歩と初期局面から3手進めただけの局面でも後手番に5二飛車成という読み筋が入ってしまう場合があるとの報告も受けております。）

私だけですかもですが

CI(Action)がリポジトリに入っての時にうまくいかなく

具体的には、本リポジトリからプルして自前のにプッシュ時にエラーでて；
自前にはプッシュできてないと思ってリベースもしてしまって
結果はプッシュはできていて自前でのリベース等は;^^

ごめんなさい
issuesへ書く内容では無いですね

自前は消して再Folkでし直しました

告知あたらと思います

N手詰めについて、もしまだ作成途中でしたらすいません。
weak_mate_n_ply()の
if ((around8 & to) && effected_to(us, to) && !effected_to(them, to) )
について、近接王手なのでtoには必ず相手方の玉の利きがあるためeffected_to(them, to)がtrueになり
if文全体としては必ずfalseになってしまうように思うのですが、いかがでしょうか？

電王トーナメントの関係で10月までこのGitHubの更新をしないのでここに現在わかっているissueを書いておきます。

■　evaluate_kppt_learn.cpp

eta2を定義してあるところ、defineで書かないとetaを参照しているのでゼロのままになってしまう。(学習ルーチンを使っている人向け)

     正)       #define eta2 (eta / 4)

■　王手生成時の歩成りで上位bitに格納する駒が間違っている。

movegen.cppのL122

    if (canPromote(Us, to))
    {
    削除)          mlist++->move = make_move_promote(from, to) + OurPt(Us,Pt);
    追加)          mlist++->move = make_move_promote(from, to) + OurProPt(Us,Pt);

■　その他

その他、気づいたことがあれば、ここに追記していきます。

定跡データベースの指し手の採用回数に0が代入されているものについて、ConsiderBookMoveCountをtrueにした場合でも、その指し手が採用される場合があります。これによりまふ定跡の一部で、意図しない指し手が指される場合があります。

原因は以下のコードで採用回数を1以上に強制しているためです。
https://github.com/yaneurao/YaneuraOu/blob/master/source/extra/book/book.cpp#L1365
このコードを削除し、採用回数が0の指し手を無視することでバグを修正できると思います。

ただし、ある局面における定跡データベースにおける全ての指し手の採用回数が0の場合、0割により意図しない動作をします。この場合にのみ全ての指し手を等確率で選択すると良いと思います。

・x86用のコンパイルは通ったけど、thread作るときに落ちる。(アライメントを要求するSSE命令で) thread.cppにaligned_new()というアロケーター書いたが、これを使っても落ちる。(ランタイムチェックで)　原因、よくわからんので誰か助けて欲しい。

・1手詰め判定ルーチン、もう少し作業が残っている。長い利きをPositionクラスに持たせて差分更新しないといけなくてそちらのコードがBitboardと相性が悪くてちょっと難しい。いま考え中。

・評価関数の差分計算まだ。探索部書いてから書く。

・探索部手付かず。Bonanza6に勝てるだけでいいならすぐ書けると思うけど、自己対戦を自動化するためのサーバーを作らないと勝率の計測が面倒なのでそれを先に作るかも。

・GitHubにアップロードしようと思ってフォルダ整理したときに、新しい形式に変換した評価関数バイナリの入ったフォルダを誤って消してしまった。お、、おい…。また変換部を書いてもってくる。泣きそう。

For all positions I tried, if there is Gote's rook on the 1st file, the engine answers "nomate".

make -j8 tournament TARGET_CPU=AVX2 COMPILER=g++ YANEURAOU_EDITION=MATE_ENGINE ENGINE_NAME="tanuki- mate engine"^C

jean@jean-desktop:~/shogi/engines/yengine2/YaneuraOu/source$ ./YaneuraOu-by-gcc
usi
id name tanuki-mate-engine Material 4.91 64AVX2BMI2 TOURNAMENT
id author by yaneurao
option name Threads type spin default 4 min 1 max 512
option name USI_Hash type spin default 4096 min 1 max 1048576
option name WriteDebugLog type check default false
option name NetworkDelay type spin default 120 min 0 max 10000
option name NetworkDelay2 type spin default 1120 min 0 max 10000
option name MinimumThinkingTime type spin default 2000 min 1000 max 100000
option name SlowMover type spin default 100 min 1 max 1000
option name MaxMovesToDraw type spin default 0 min 0 max 100000
option name DepthLimit type spin default 0 min 0 max 2147483647
option name NodesLimit type spin default 0 min 0 max 9223372036854775807
option name Contempt type spin default 2 min -30000 max 30000
option name ContemptFromBlack type check default false
option name EvalDir type string default eval
option name MorePreciseMatePv type check default true
usiok
isready
info string USI_Hash Clear begin , Hash size = 4096[MB]
info string USI_Hash Clear done.
readyok
position sfen 4k4/9/4P4/8r/9/9/9/9/9 b Gr2b3g4s4n4l17p 1
go mate infinite
info string pn 100000000 dn 0 nodes_searched 0
checkmate nomate
go matedebug G*5b
口 口 口 口^玉 口 口 口 口
口 口 口 口 口 口 口 口 口
口 口 口 口 歩 口 口 口 口
口 口 口 口 口 口 口 口^飛
口 口 口 口 口 口 口 口 口
口 口 口 口 口 口 口 口 口
口 口 口 口 口 口 口 口 口
口 口 口 口 口 口 口 口 口
口 口 口 口 口 口 口 口 口
先手 手駒 : 金 , 後手 手駒 : 歩17 香4 桂4 銀4 角2 飛 金3
手番 = 先手
sfen 4k4/9/4P4/8r/9/9/9/9/9 b Gr2b3g4s4n4l17p 1

pn-dn100000000,0
key-gen2086237944,1
口 口 口 口^玉 口 口 口 口
口 口 口 口 金 口 口 口 口
口 口 口 口 歩 口 口 口 口
口 口 口 口 口 口 口 口^飛
口 口 口 口 口 口 口 口 口
口 口 口 口 口 口 口 口 口
口 口 口 口 口 口 口 口 口
口 口 口 口 口 口 口 口 口
口 口 口 口 口 口 口 口 口
先手 手駒 : , 後手 手駒 : 歩17 香4 桂4 銀4 角2 飛 金3
手番 = 後手
sfen 4k4/4G4/4P4/8r/9/9/9/9/9 w r2b3g4s4n4l17p 2

pn,dn = 1,1
key-gen = 4029583722

Hello author, I am a shogi fan from China. Can the software be used in China? Do I need to connect to the Internet every time I use it? Because when I use shogigui to run the software, it shows that the initialization failed

Learner::search()を呼び出すと、低い確率でevaluateBody()内でnullポインタアクセスによりクラッシュします。

調査をお願いいできませんでしょうか？
よろしくお願いいたします。

ubuntu 16.04
gcc 5.4.0

make tournament でエラーが出ます

https://github.com/yaneurao/YaneuraOu/blob/master/source/eval/nnue/evaluate_nnue_learner.cpp#L22
HalfKPE9のfactorizerのみが有効化されており、それ以外の入力特徴量のfactorizerが機能していません。ネットワーク定義マクロに応じて、適切なfactorizerをincludeし、有効化するのが本来あるべき姿だと思います。

将棋AIを知るきっかけにしようと思いYaneuraOuをgitからcloneしてVisual Studio 2015 Community Editionで使っています。問題といいますか、同じことで悩んでいる方もきっといるのではないかと想像しますのでコメントを書かせて頂きます。

YaneuraOu nano KPP 2.86 64 SSE4.2で使っていますが、将棋所にエンジン登録するときに「USIエンジンではありません」とのエラーが発生します。

原因を調べていたのですが、YaneuraOu.exeを実行すると、直後にbook/standard_book.dbを読み込むための処理が発生します。これに私の環境では、40秒くらいかかっています。この処理は将棋所へのエンジン登録のタイミングでも発生しているため、usiokを返すのが遅れ「USIエンジンでは無い」と診断されてしまうようです。

対局開始時にも同じ処理が発生し40秒ほど待たされますが、しかしこちらはエラーにはならず、動作しています（Bonanza6.0と連続対局中。負けているようです……）

ユーザ側として可能な回避策としては、エンジン登録時にはbook/standard_book.dbを別の名前に変えておくこと（これで短時間でusiokが返るようになる）、エンジン登録が済んだら、もとのファイル名に戻すことが考えられます。

通常版（非tournament版）で、評価関数識別用チェックサムがevaluate.cpp内の値と異なる場合があります。
tournament版では発生しません。

SSE4.2版でbenchコマンドを実行して確認しました。

左側はevaluate.cppの値（tournament版での値）、右側が通常版での値

• ShinYane(20161010)
  7171a5469027ebf→7171a4e69027eb3
• Ukamuse(sdt4)
  同じ（71fc7fd40c668cc）
• elmo
  同じ（65cd7c55a9d4cd9）
• Yomita(WCSC27)
  3aa68b055a020a8→3aa687c55a02303
• Qhapaq(WCSC27)
  同じ（702fb2ee5672156）
• tanuki(WCSC27)
  6c54a1bcb5a6338→6c549f3cb5a63b2

evaluate.cppにはありませんが、以下の評価関数でも確認しました。

• リゼロepoch8
  58e206e66c06a58→58e204466c068b2
• 野生の読み太(20170703)
  5445b1088b16588→5445add88b17343

また、tanuki(WCSC27)ですがtournament版でもチェックサムが異なるようです。
tanuki-(WCSC27)のcheck_sumの値を修正による修正前と同じ6c54a1bcb654e37になっています。

実行環境

• OS
  Windows Server 2012 R2
• メモリ
  32GB
• 使用コンパイラ
  MSYS2(clang)

こんにちは。

position.cpp の １９９行目付近について、
すいません、コードの意味合いを理解できてないのですが、

		PieceNumber piece_no =
			(idx == B_KING) ? PIECE_NUMBER_BKING : // 先手玉
			(idx == W_KING) ? PIECE_NUMBER_WKING : // 後手玉
			piece_no_count[raw_type_of(Piece(idx))]++; // それ以外
			PIECE_NUMBER_ZERO; // とりあえず駒番号は使わないので全部ゼロにしておけばいい。

って、ひょっとして、
piece_no_count から始まる行と PIECE_NUMBER_ZERO から始まる行のどっちかが不要では？
あるいは、piece_no_count から始まる行の最後が ; じゃなくて、, っすかね？

ConsiderationMode他いくつかの項が抜けているようですが･･･
多分ミスだと思いますが、仕様だったりしますか

BookOnTheFly有効の場合にソート済みの定跡を使っても一部の局面がヒットしないことがあります。
例えば、以下のような小さな定跡ファイルを作ってBookOnTheFly有効で平手初期局面を読むと存在するはずなのにヒットしません。
BookOnTheFlyの実装に何らかの問題があるのではないでしょうか。

#YANEURAOU-DB2016 1.00
sfen lnsgkgsnl/1r5b1/ppppppppp/9/9/7P1/PPPPPPP1P/1B5R1/LNSGKGSNL w - 2
3c3d 7g7f -59 32 1
8c8d 2f2e -64 20 1
4a3b 2f2e -64 20 1
6a5b 2f2e -95 0 1
7a6b 2f2e -97 8 1
3a4b 2f2e -100 0 1
7a7b 2f2e -119 0 1
1c1d 2f2e -124 0 1
9c9d 2f2e -124 0 1
sfen lnsgkgsnl/1r5b1/ppppppppp/9/9/8P/PPPPPPPP1/1B5R1/LNSGKGSNL w - 2
3c3d 6i7h -14 1 1
sfen lnsgkgsnl/1r5b1/ppppppppp/9/9/9/PPPPPPPPP/1B5R1/LNSGKGSNL b - 1
2g2f 3c3d 59 33 1
sfen lnsgkgsnl/1r5b1/ppppppppp/9/9/9/PPPPPPPPP/1BG4R1/LNS1KGSNL w - 2
8c8d 7g7f -53 21 1

また、この件とは無関係で些細なものなのですが、ファイルに空行が入っている場合（テラショック定跡700だとファイル末尾に空行がある）のBookOnTheFlyの挙動もおかしい気がします。
その局面を出すと定跡にヒットして定跡の指し手を候補手として出力しているのに、別に通常の探索を開始してしまいます。

あと、公開されているテラショック定跡700はソート済みのはずですが、やねうら王4.88でテラショック定跡700に対してsortのコマンドを打つとファイルサイズが変わるのですが、これって重複局面があるからでしょうか？？

いつもお世話になっております。
ちょっと躓いたので、手順を共有いたします。
Makefileの編集がミソです。

1. YaneuraOu NNUE-K-P-256-32-32用評価関数バイナリ nn.binから
   20190115_k-p-256-32-32.zipとSource code (zip)をダウンロードする。
2. Source code (zip) を unzipし、sourceフォルダーに入る
3. nnue/nnue_architecture.hの
   #include "architectures/halfkp_256x2-32-32.h"
   をコメントアウト。代わりに
   #include "architectures/k-p_256x2-32-32.h"
   とする。
4. Makefile で YANEURAOU_EDITION = YANEURAOU_2018_TNK_ENGINEを有効にする
5. make 実行し、実行バイナリ YaneuraOu-by-gcc を作成
6. mkdir -p eval の上、 20190115_k-p-256-32-32.zipに含まれる nn.bin を取り出して、 eval フォルダーに置く

https://dev.to/vochicong/yaneuraou-nnue-k-p-256-32-32-47k5

MSYS2 のビルドでエラーが出ていますが、msys2/MINGW-packages#8658 っぽいです。上流では修正に入ったようです。
迂回策を調査しています。

一点要望を挙げさせていただきます。
現在のやねうら王の実装では、ponderおよびbookの両方にヒットした場合、bookに登録されている指し手が指されます。これを、

1. bookの指し手を優先する
2. 探索深さが深いほうを優先する
   の2通りから選べるようにできませんでしょうか？

2.については、bookに深さ24で探索した指し手が登録されており、ponderが深さ27まで進んでいる場合は、後者を採用するといった感じです。ご一考いただければ幸いです。

think時(clusterで分配)に表示される思考局面数とmerge時に表示される思考局面数が異なる