Ray becomes weaker

[GD-fix]

Source

[kobanium]

Thank you for information.

I tried to test current Ray in my PC, I can confirm current Ray is getting weaker.

options	ver 10.0.1 (commit hash #a914a70)	ver 9.0.1 (commit hash#13dbae8)	Elo rating diff
--komi 7.5 --playout 1000	143	257	-101.8
--komi 7.5 --playout 2000	90	310	-214.8
--komi 7.5 --playout 4000	61	339	-297.9
--komi 7.5 --const-time 5 --thread 2 --pondering --tree-size 262144	2	48	-552.1

It is definitely getting weaker, I'm trying to find out bugs.

[GD-fix]

Perhaps an analysis of the sparring played will help you?

[kobanium]

I already found training program's bug. But this issue is not solved yet. I think bugs are in move evaluations. Please wait for a while.

[GD-fix]

Thanks for advance! I just want to draw your attention to the fact that the engine began to weaken from the previous version...

[GD-fix]

Meanwhile Pachi (--nodcnn) became stronger than Ray (of strongest version)...

[kobanium]

I'm sorry to keep you waiting. I finally fixed bugs and released v10.1.0.

I tested v10.1.0, results as follow;

options	v10.1.0 (commit hash #fe615d6)	ver 9.0.1 (commit hash#13dbae8)	Elo rating diff
--komi 7.5 --playout 1000	485	515	-10.4
--komi 7.5 --playout 2000	450	550	-34.9
--komi 7.5 --playout 4000	427	573	-51.1
--komi 7.5 --playout 8000	419	581	-56.8

The newest version of Ray is little weaker than the strongest version of Ray, there are many parameters that has oppotunities to tune. I continue to improve Ray. So please wait for next version.

[kobanium]

Now I released v10.3.0. This is little stronger than v10.2.0.

options	v10.3.0	v9.0.1	Elo rating diff
--komi 7.5 --playout 1000	601	399	+71.2
--komi 7.5 --playout 2000	577	423	+53.9
--komi 7.5 --playout 3000	566	434	+46.1
--komi 7.5 --playout 4000	524	476	+16.7

I will close this issue 1 week after.

[GD-fix]

OK. I just downloaded master zip archive (must I download anything additional?) and I'll test it a few weeks later (now I'm testing KataGo last year final neuronets)...

[kobanium]

OK I keep opening this issue. If you want to use Ray, you should download 3 zip files (source, sim_params, uct_params).

[GD-fix]

OK. I had download Ray-11.0.0.zip, sim_params.zip, uct_params.zip. Please specify: after their extraction I must replace with sim_params and uct_params folders from corresponding archives the same name subfolders in Ray-11.0.0 folder? In README there is only:

About Ray

Ray is a Go (Weiqi, Baduk) game engine based on Monte-Carlo tree search without Deep Learning.

日本語は[こちら](https://github.com/kobanium/Ray/blob/master/doc/ja/README.md).
Installation

    'cd' to the directory which includes 'Makefile'
    Type 'make' to compile

How to run

By default settings, Ray will consume 10 seconds each move on a single CPU and require 800MB of memory.

./ray
...

Thanks in advance.

[kobanium]

README.md in Ray-11.0.0.zip is here I confirmed;

# About Ray
Ray is a Go (Weiqi, Baduk) game engine based on Monte-Carlo tree search without Deep Learning.

日本語は[こちら](doc/ja/README.md).

# Installation
1. 'cd' to the directory which includes 'Makefile'
2. Type 'make' to compile
3. Place parameter files to ```sim_params``` and ```uct_params``` directries (You can download parameter files from [here](https://github.com/kobanium/Ray/releases))

# How to run
When using a GUI that supports GTP (Go Text Protocol), the following command can be used Ray as a engine.

./ray

Ray's command line options are as follows,

I added 3rd installation step on v10.1.0. https://github.com/kobanium/Ray/commit/ba886bb1a04837651ceb35d0f78271ad8dae349a#diff-0ebeceb020d6a1e80230852523b1d2db2ee4ca3f551e5e7e0e6d50828cb4b46c Please check your README.md and PROGRAM_VERSION definition in Gtp.hpp.

[GD-fix]

OK. Only "directories", not "directries"...

[kobanium]

Thanks, that's typo.

[kobanium]

I have updated README.md, thanks.

[GD-fix]

It doesn't compile at all... On old OS:

Ray-11.0.0> make -j 4
g++ -Wall -W -O3 -std=c++11 -I./include -o obj/common/Message.o -c src/common/Message.cpp
g++ -Wall -W -O3 -std=c++11 -I./include -o obj/RayMain.o -c src/RayMain.cpp
g++ -Wall -W -O3 -std=c++11 -I./include -o obj/util/Command.o -c src/util/Command.cpp
g++ -Wall -W -O3 -std=c++11 -I./include -o obj/util/Utility.o -c src/util/Utility.cpp
In file included from /usr/include/c++/4.7/algorithm:63:0,
                 from src/common/Message.cpp:8:
/usr/include/c++/4.7/bits/stl_algo.h: In instantiation of ‘_RandomAccessIterator std::__unguarded_partition(_RandomAccessIterator, _RandomAccessIterator, const _Tp&, _Compare) [with _RandomAccessIterator = __gnu_cxx::__normal_iterator<PrintLeelaZeroAnalyze(const uct_node_t*)::verbose_t*, std::vector<PrintLeelaZeroAnalyze(const uct_node_t*)::verbose_t> >; _Tp = PrintLeelaZeroAnalyze(const uct_node_t*)::verbose_t; _Compare = PrintLeelaZeroAnalyze(const uct_node_t*)::<lambda(PrintLeelaZeroAnalyze(const uct_node_t*)::verbose_t&, PrintLeelaZeroAnalyze(const uct_node_t*)::verbose_t&)>]’:
/usr/include/c++/4.7/bits/stl_algo.h:2321:78:   required from ‘_RandomAccessIterator std::__unguarded_partition_pivot(_RandomAccessIterator, _RandomAccessIterator, _Compare) [with _RandomAccessIterator = __gnu_cxx::__normal_iterator<PrintLeelaZeroAnalyze(const uct_node_t*)::verbose_t*, std::vector<PrintLeelaZeroAnalyze(const uct_node_t*)::verbose_t> >; _Compare = PrintLeelaZeroAnalyze(const uct_node_t*)::<lambda(PrintLeelaZeroAnalyze(const uct_node_t*)::verbose_t&, PrintLeelaZeroAnalyze(const uct_node_t*)::verbose_t&)>]’
/usr/include/c++/4.7/bits/stl_algo.h:2362:62:   required from ‘void std::__introsort_loop(_RandomAccessIterator, _RandomAccessIterator, _Size, _Compare) [with _RandomAccessIterator = __gnu_cxx::__normal_iterator<PrintLeelaZeroAnalyze(const uct_node_t*)::verbose_t*, std::vector<PrintLeelaZeroAnalyze(const uct_node_t*)::verbose_t> >; _Size = long int; _Compare = PrintLeelaZeroAnalyze(const uct_node_t*)::<lambda(PrintLeelaZeroAnalyze(const uct_node_t*)::verbose_t&, PrintLeelaZeroAnalyze(const uct_node_t*)::verbose_t&)>]’
/usr/include/c++/4.7/bits/stl_algo.h:5514:4:   required from ‘void std::sort(_RAIter, _RAIter, _Compare) [with _RAIter = __gnu_cxx::__normal_iterator<PrintLeelaZeroAnalyze(const uct_node_t*)::verbose_t*, std::vector<PrintLeelaZeroAnalyze(const uct_node_t*)::verbose_t> >; _Compare = PrintLeelaZeroAnalyze(const uct_node_t*)::<lambda(PrintLeelaZeroAnalyze(const uct_node_t*)::verbose_t&, PrintLeelaZeroAnalyze(const uct_node_t*)::verbose_t&)>]’
src/common/Message.cpp:491:12:   required from here
/usr/include/c++/4.7/bits/stl_algo.h:2289:4: error: no match for call to ‘(PrintLeelaZeroAnalyze(const uct_node_t*)::<lambda(PrintLeelaZeroAnalyze(const uct_node_t*)::verbose_t&, PrintLeelaZeroAnalyze(const uct_node_t*)::verbose_t&)>) (PrintLeelaZeroAnalyze(const uct_node_t*)::verbose_t&, const PrintLeelaZeroAnalyze(const uct_node_t*)::verbose_t&)’
src/common/Message.cpp:488:16: note: candidates are:
In file included from /usr/include/c++/4.7/algorithm:63:0,
                 from src/common/Message.cpp:8:
/usr/include/c++/4.7/bits/stl_algo.h:2289:4: note: bool (*)(PrintLeelaZeroAnalyze(const uct_node_t*)::verbose_t&, PrintLeelaZeroAnalyze(const uct_node_t*)::verbose_t&) <conversion>
/usr/include/c++/4.7/bits/stl_algo.h:2289:4: note:   candidate expects 3 arguments, 3 provided
src/common/Message.cpp:488:46: note: PrintLeelaZeroAnalyze(const uct_node_t*)::<lambda(PrintLeelaZeroAnalyze(const uct_node_t*)::verbose_t&, PrintLeelaZeroAnalyze(const uct_node_t*)::verbose_t&)>
src/common/Message.cpp:488:46: note:   no known conversion for argument 2 from ‘const PrintLeelaZeroAnalyze(const uct_node_t*)::verbose_t’ to ‘PrintLeelaZeroAnalyze(const uct_node_t*)::verbose_t&’
In file included from /usr/include/c++/4.7/algorithm:63:0,
                 from src/common/Message.cpp:8:
/usr/include/c++/4.7/bits/stl_algo.h:2292:4: error: no match for call to ‘(PrintLeelaZeroAnalyze(const uct_node_t*)::<lambda(PrintLeelaZeroAnalyze(const uct_node_t*)::verbose_t&, PrintLeelaZeroAnalyze(const uct_node_t*)::verbose_t&)>) (const PrintLeelaZeroAnalyze(const uct_node_t*)::verbose_t&, PrintLeelaZeroAnalyze(const uct_node_t*)::verbose_t&)’
src/common/Message.cpp:488:16: note: candidates are:
In file included from /usr/include/c++/4.7/algorithm:63:0,
                 from src/common/Message.cpp:8:
/usr/include/c++/4.7/bits/stl_algo.h:2292:4: note: bool (*)(PrintLeelaZeroAnalyze(const uct_node_t*)::verbose_t&, PrintLeelaZeroAnalyze(const uct_node_t*)::verbose_t&) <conversion>
/usr/include/c++/4.7/bits/stl_algo.h:2292:4: note:   candidate expects 3 arguments, 3 provided
src/common/Message.cpp:488:46: note: PrintLeelaZeroAnalyze(const uct_node_t*)::<lambda(PrintLeelaZeroAnalyze(const uct_node_t*)::verbose_t&, PrintLeelaZeroAnalyze(const uct_node_t*)::verbose_t&)>
src/common/Message.cpp:488:46: note:   no known conversion for argument 1 from ‘const PrintLeelaZeroAnalyze(const uct_node_t*)::verbose_t’ to ‘PrintLeelaZeroAnalyze(const uct_node_t*)::verbose_t&’
g++ -Wall -W -O3 -std=c++11 -I./include -o obj/feature/Semeai.o -c src/feature/Semeai.cpp
g++ -Wall -W -O3 -std=c++11 -I./include -o obj/sgf/SgfExtractor.o -c src/sgf/SgfExtractor.cpp
g++ -Wall -W -O3 -std=c++11 -I./include -o obj/feature/Territory.o -c src/feature/Territory.cpp
make: *** [obj/common/Message.o] Ошибка 1
make: *** Ожидание завершения заданий...                                                                                                                                                                                                                                       

On newer OS:

Ray-11.0.0> make clean && make -j 4
rm -f *~ ray   ./obj/common/Message.o  ./obj/RayMain.o  ./obj/util/Command.o  ./obj/util/Utility.o  ./obj/sgf/SgfExtractor.o  ./obj/feature/Semeai.o  ./obj/feature/Territory.o  ./obj/feature/UctFeature.o  ./obj/feature/SimulationFeature.o  ./obj/feature/Seki.o  ./obj/feature/Nakade.o  ./obj/feature/Ladder.o  ./obj/pattern/PatternHash.o  ./obj/pattern/Pattern.o  ./obj/board/DynamicKomi.o  ./obj/board/ZobristHash.o  ./obj/board/GoBoard.o  ./obj/board/String.o  ./obj/board/Point.o  ./obj/board/SearchBoard.o  ./obj/learn/MovePredictionTest.o  ./obj/learn/FactorizationMachines.o  ./obj/learn/MinorizationMaximization.o  ./obj/learn/PatternAnalyzer.o  ./obj/learn/LearningUtility.o  ./obj/learn/LearningLog.o  ./obj/mcts/ucb/UCBEvaluation.o  ./obj/mcts/Rating.o  ./obj/mcts/MCTSEvaluation.o  ./obj/mcts/Simulation.o  ./obj/mcts/UctRating.o  ./obj/mcts/MoveSelection.o  ./obj/mcts/SearchManager.o  ./obj/mcts/UctSearch.o  ./obj/mcts/MCTSNode.o  ./obj/gtp/Gtp.o ./src/*~ ./src/*/*~ ./src/*/*/*~ ./src/*/*/*/*~ ./include/*~ ./include/*/*~ ./include/*/*/*~ ./include/*/*/*/*~
g++ -Wall -W -O3 -std=c++11 -I./include -o obj/common/Message.o -c src/common/Message.cpp
g++ -Wall -W -O3 -std=c++11 -I./include -o obj/RayMain.o -c src/RayMain.cpp
g++ -Wall -W -O3 -std=c++11 -I./include -o obj/util/Command.o -c src/util/Command.cpp
g++ -Wall -W -O3 -std=c++11 -I./include -o obj/util/Utility.o -c src/util/Utility.cpp
g++ -Wall -W -O3 -std=c++11 -I./include -o obj/sgf/SgfExtractor.o -c src/sgf/SgfExtractor.cpp
g++ -Wall -W -O3 -std=c++11 -I./include -o obj/feature/Territory.o -c src/feature/Territory.cpp
g++ -Wall -W -O3 -std=c++11 -I./include -o obj/feature/Semeai.o -c src/feature/Semeai.cpp
g++ -Wall -W -O3 -std=c++11 -I./include -o obj/feature/UctFeature.o -c src/feature/UctFeature.cpp
In function «int GetSize(SGF_record_t*, const char*, int)»,
    inlined from «int ExtractKifu(const char*, SGF_record_t*)» at src/sgf/SgfExtractor.cpp:139:23:
src/sgf/SgfExtractor.cpp:195:15: предупреждение: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
  195 |       size[i] = sgf_text[cursor + i + 3];
      |       ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
src/sgf/SgfExtractor.cpp: In function «int ExtractKifu(const char*, SGF_record_t*)»:
src/sgf/SgfExtractor.cpp:187:8: замечание: at offset 10 into destination object «size» of size 10
  187 |   char size[10];
      |        ^~~~
In function «int GetKomi(SGF_record_t*, const char*, int)»,
    inlined from «int ExtractKifu(const char*, SGF_record_t*)» at src/sgf/SgfExtractor.cpp:149:23:
src/sgf/SgfExtractor.cpp:348:15: предупреждение: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
  348 |       komi[i] = sgf_text[cursor + i + 3];
      |       ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
src/sgf/SgfExtractor.cpp: In function «int ExtractKifu(const char*, SGF_record_t*)»:
src/sgf/SgfExtractor.cpp:342:8: замечание: at offset 10 into destination object «komi» of size 10
  342 |   char komi[10] = {0};
      |        ^~~~
In function «int GetHandicaps(SGF_record_t*, const char*, int)»,
    inlined from «int ExtractKifu(const char*, SGF_record_t*)» at src/sgf/SgfExtractor.cpp:143:28:
src/sgf/SgfExtractor.cpp:283:20: предупреждение: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
  283 |       handicaps[i] = sgf_text[cursor + i + 3];
      |       ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
src/sgf/SgfExtractor.cpp: In function «int ExtractKifu(const char*, SGF_record_t*)»:
src/sgf/SgfExtractor.cpp:277:8: замечание: at offset 10 into destination object «handicaps» of size 10
  277 |   char handicaps[10] = {0};
      |        ^~~~~~~~~
g++ -Wall -W -O3 -std=c++11 -I./include -o obj/feature/SimulationFeature.o -c src/feature/SimulationFeature.cpp
g++ -Wall -W -O3 -std=c++11 -I./include -o obj/feature/Seki.o -c src/feature/Seki.cpp
g++ -Wall -W -O3 -std=c++11 -I./include -o obj/feature/Nakade.o -c src/feature/Nakade.cpp
g++ -Wall -W -O3 -std=c++11 -I./include -o obj/feature/Ladder.o -c src/feature/Ladder.cpp
g++ -Wall -W -O3 -std=c++11 -I./include -o obj/pattern/PatternHash.o -c src/pattern/PatternHash.cpp
g++ -Wall -W -O3 -std=c++11 -I./include -o obj/pattern/Pattern.o -c src/pattern/Pattern.cpp
g++ -Wall -W -O3 -std=c++11 -I./include -o obj/board/DynamicKomi.o -c src/board/DynamicKomi.cpp
g++ -Wall -W -O3 -std=c++11 -I./include -o obj/board/ZobristHash.o -c src/board/ZobristHash.cpp
In file included from /usr/include/c++/13/algorithm:61,
                 from src/feature/Nakade.cpp:1:
In function «void std::__final_insertion_sort(_RandomAccessIterator, _RandomAccessIterator, _Compare) [с _RandomAccessIterator = int*; _Compare = __gnu_cxx::__ops::_Iter_less_iter]»,
    inlined from «void std::__final_insertion_sort(_RandomAccessIterator, _RandomAccessIterator, _Compare) [с _RandomAccessIterator = int*; _Compare = __gnu_cxx::__ops::_Iter_less_iter]» at /usr/include/c++/13/bits/stl_algo.h:1854:5,
    inlined from «void std::__sort(_RandomAccessIterator, _RandomAccessIterator, _Compare) [с _RandomAccessIterator = int*; _Compare = __gnu_cxx::__ops::_Iter_less_iter]» at /usr/include/c++/13/bits/stl_algo.h:1950:31,
    inlined from «void std::__sort(_RandomAccessIterator, _RandomAccessIterator, _Compare) [с _RandomAccessIterator = int*; _Compare = __gnu_cxx::__ops::_Iter_less_iter]» at /usr/include/c++/13/bits/stl_algo.h:1942:5,
    inlined from «void std::sort(_RAIter, _RAIter) [с _RAIter = int*]» at /usr/include/c++/13/bits/stl_algo.h:4861:18,
    inlined from «bool IsUctNakadeSelfAtari(const game_info_t*, int, int)» at src/feature/Nakade.cpp:433:12:
/usr/include/c++/13/bits/stl_algo.h:1859:32: предупреждение: array subscript 16 is outside array bounds of «int [10]» [-Warray-bounds=]
 1859 |           std::__insertion_sort(__first, __first + int(_S_threshold), __comp);
      |           ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/feature/Nakade.cpp: In function «bool IsUctNakadeSelfAtari(const game_info_t*, int, int)»:
src/feature/Nakade.cpp:404:7: замечание: at offset 64 into object «stones» of size 40
  404 |   int stones[10], checked[4] = { 0 };
      |       ^~~~~~
g++ -Wall -W -O3 -std=c++11 -I./include -o obj/board/GoBoard.o -c src/board/GoBoard.cpp
g++ -Wall -W -O3 -std=c++11 -I./include -o obj/board/String.o -c src/board/String.cpp
src/board/String.cpp:577:1: предупреждение: «int AddCapture(int*, int, int)» определена, но не используется [-Wunused-function]
  577 | AddCapture( int capture[], const int pos, const int head )
      | ^~~~~~~~~~
g++ -Wall -W -O3 -std=c++11 -I./include -o obj/board/Point.o -c src/board/Point.cpp
g++ -Wall -W -O3 -std=c++11 -I./include -o obj/board/SearchBoard.o -c src/board/SearchBoard.cpp
g++ -Wall -W -O3 -std=c++11 -I./include -o obj/learn/MovePredictionTest.o -c src/learn/MovePredictionTest.cpp
g++ -Wall -W -O3 -std=c++11 -I./include -o obj/learn/FactorizationMachines.o -c src/learn/FactorizationMachines.cpp
g++ -Wall -W -O3 -std=c++11 -I./include -o obj/learn/MinorizationMaximization.o -c src/learn/MinorizationMaximization.cpp
g++ -Wall -W -O3 -std=c++11 -I./include -o obj/learn/PatternAnalyzer.o -c src/learn/PatternAnalyzer.cpp
g++ -Wall -W -O3 -std=c++11 -I./include -o obj/learn/LearningUtility.o -c src/learn/LearningUtility.cpp
g++ -Wall -W -O3 -std=c++11 -I./include -o obj/learn/LearningLog.o -c src/learn/LearningLog.cpp
g++ -Wall -W -O3 -std=c++11 -I./include -o obj/mcts/ucb/UCBEvaluation.o -c src/mcts/ucb/UCBEvaluation.cpp
g++ -Wall -W -O3 -std=c++11 -I./include -o obj/mcts/Rating.o -c src/mcts/Rating.cpp
g++ -Wall -W -O3 -std=c++11 -I./include -o obj/mcts/MCTSEvaluation.o -c src/mcts/MCTSEvaluation.cpp
src/mcts/MCTSEvaluation.cpp: In function «int SelectMaxUcbChild(uct_node_t&, int, int, std::mt19937_64&)»:
src/mcts/MCTSEvaluation.cpp:9:48: предупреждение: неиспользуемый параметр «moves» [-Wunused-parameter]
    9 | SelectMaxUcbChild( uct_node_t &node, const int moves, const int color, std::mt19937_64 &mt )
      |                                      ~~~~~~~~~~^~~~~
src/mcts/MCTSEvaluation.cpp:9:65: предупреждение: неиспользуемый параметр «color» [-Wunused-parameter]
    9 | SelectMaxUcbChild( uct_node_t &node, const int moves, const int color, std::mt19937_64 &mt )
      |                                                       ~~~~~~~~~~^~~~~
g++ -Wall -W -O3 -std=c++11 -I./include -o obj/mcts/Simulation.o -c src/mcts/Simulation.cpp
g++ -Wall -W -O3 -std=c++11 -I./include -o obj/mcts/UctRating.o -c src/mcts/UctRating.cpp
g++ -Wall -W -O3 -std=c++11 -I./include -o obj/mcts/MoveSelection.o -c src/mcts/MoveSelection.cpp
g++ -Wall -W -O3 -std=c++11 -I./include -o obj/mcts/SearchManager.o -c src/mcts/SearchManager.cpp
g++ -Wall -W -O3 -std=c++11 -I./include -o obj/mcts/UctSearch.o -c src/mcts/UctSearch.cpp
g++ -Wall -W -O3 -std=c++11 -I./include -o obj/mcts/MCTSNode.o -c src/mcts/MCTSNode.cpp
src/mcts/MCTSNode.cpp: In function «void InitializeNode(uct_node_t&, int, int)»:
src/mcts/MCTSNode.cpp:14:8: ошибка: «fill_n» не является элементом «std»
   14 |   std::fill_n(node.seki, BOARD_MAX, false);
      |        ^~~~~~
src/mcts/MCTSNode.cpp:15:8: ошибка: «fill_n» не является элементом «std»
   15 |   std::fill_n(node.ownership, BOARD_MAX, 0.0);
      |        ^~~~~~
make: *** [Makefile:44: obj/mcts/MCTSNode.o] Ошибка 1
make: *** Ожидание завершения заданий…

Perhaps it's time to do what others have long done: binaries with statically linked libraries (not so progressive like this, but simple like this)?

Thanks in advance.

[kobanium]

Please tell me what operating system you are using. Warning messages are quite different from my computer.

[GD-fix]

That's why the other developers have the binary releases...

OS: OpenSUSE (old - ver.13.0, newer - Tumbleweed snapshot < 1 year old).

[kobanium]

Thanks for information. I prepare the statically linked binary to try it out. Please download here. Ray-11.0.0-linux-x64.tar.gz I'm working for compiling Ray on Windows OS. After I finish to prepare binary release for Windows and Linux, I will attach binary releases for v11.0.0 release.

[GD-fix]

Thanks. I had downloaded and try on this PC (with up to date OpenSUSE Tumbleweed):

.../Ray-11.0.0-linux-x64>./ray
can not open -./sim_params/PreviousDistance.txt-

I think, it will be more logically to append sim_params & uct_params folders in single archive with binary file. After manual appending the folders:

.../Ray-11.0.0-linux-x64> ./ray
Require 254 Mbytes for Uct Node

16288
8688
genmove b
Time Limit    : 10 Sec
Playout Limit : 10000000 PO
Ошибка сегментирования (образ памяти сброшен на диск)

gbd logging: gdb.txt I can try it on the PC with mentioned earlier OS's too and report on results next week here, but if You have any idea and will make changes with following uploading it in few hours here, I will try today...

[kobanium]

Thanks for your help. I'm sorry I did not include parameter files in the archive file. I cannot upload the archive file with parameter files on this issue commend by file size limitation. When I release v11.0.0 archive file, I will include parameter files in it.

I found wrong compile option setting. Please try here archive file (only ray binary in it). Ray-11.0.0-linux-x64.tar.gz

[GD-fix]

Thanks. It works. I'll try on mentioned other PC next week. If all will be OK (otherwise I'll post here), I'll test its strength a few weeks later (now I'm testing KataGo new version after I had tested its last year final neuronets)...

Sorry, I meant exactly adding folders to the next releases archives, not now here in issue uploading.

P. S. I know it's none of my business, but I think, it's no any reason to make binaries for Windows OS, because there is the only one its "distributor", and if the source compiles on Your "distro", it will compile on others...

[GD-fix]

Unfortunately Ray didn't become significantly stronger: it hasn't any chance even against MoGo, a fortiori against strongest Ray version (details)...

[kobanium]

Thanks for testing. I found a bug #167 . And Ray does not response a move on rare occasions. Virtual loss is important factor multi-threading search. So I will release Ray v11.1.0 after fixing #167.

[GD-fix]

OK. Good luck!

[kobanium]

I finally released v11.1.0. Please download here. https://github.com/kobanium/Ray/releases/tag/v11.1.0

I checked the strength of Ray v11.1.0 using statistically linked binary file, the results are followed,

options	v11.1.0	v9.0.1
--komi 7.5 --playout 1000	256	144
--komi 7.5 --playout 2000	224	176
--komi 7.5 --playout 4000	210	190
--komi 7.5 --playout 8000	241	159
--komi 7.5 --const-time 120 --thread 2 --pondering --tree-size 262144	6	2

I think v11.1.0 is not weaker than v9.0.1 at least.

[GD-fix]

Thanks! I'll test it after ending of KataGo new version testing...

[GD-fix]

I am going to start of v11.1.0 testing, but I didn't understand, why there are in Assets the sim_params and uct_params archives: they are different from ones in archive with Ray?

[kobanium]

Running binary file of Ray needs both of sim_params and uct_params. So I prepared archive files with binary file and parameter files. There are no different between sim_params in binary archive files and sim_params archive file. uct_params is also same situation.

[GD-fix]

I finally released v11.1.0. Please download here. https://github.com/kobanium/Ray/releases/tag/v11.1.0

I checked the strength of Ray v11.1.0 using statistically linked binary file, the results are followed, options v11.1.0 v9.0.1 --komi 7.5 --playout 1000 256 144 --komi 7.5 --playout 2000 224 176 --komi 7.5 --playout 4000 210 190 --komi 7.5 --playout 8000 241 159 --komi 7.5 --const-time 120 --thread 2 --pondering --tree-size 262144 6 2

I think v11.1.0 is not weaker than v9.0.1 at least.

With "--resign 0.25" not "at least", but "almost": with v.11.1.0 white it was a draw, black v.11.1.0 had lost 2 - 8. Ray v. 11.1.0 is not weaker "at least" than the not developed during a tenth years Go engine MoGo... details games strongest version of Ray engine

[kobanium]

Thanks for testing. There does not semm to be a statistically significant difference between the strongest version and v11.1.0. When comparing strength, it is often necessary to play at least 1000 games to get a significant difference, so I think it is just a coincidence that the strongest version of Ray won all the games against MoGo. I will close this issue.

[GD-fix]

I think, it's a very little probability, that engines with equal strength play 5:5 on one sides and 2:8 on other sides...

[kobanium]

That result can happen more than you think. If you are concerned about it, please increase the number of games up to 1000 for each side, and the probabilities will converge to about the same.