terjekir / weiss Goto Github PK

Hi Terje,

this goes into the category "consultation". :-)

I am working on Online Syzygy probing code in Bagatur chess engine and have some issues / questions.
Here is the issue, originally reported by tissatussa, on this topic: bagaturchess/Bagatur#9
The problems, which I face are described in the issue as well.
Your comments and hints will be very helpful and highly appreciated!

Best regards,
Krasimir

hi, for a rather long time i follow your PR's and versions .. the master version is still being called v2.1-dev but i see many changes lately .. will your new code result in a v2.2 soon ?

Attempting to compile Weiss on Ubuntu 23.10 fails with the following error message:

ubuntu@9796d368b132:~/OpenBench/Scripts/Repositories/weiss/src$ gcc --version
gcc (Ubuntu 13.2.0-3ubuntu1) 13.2.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

ubuntu@9796d368b132:~/OpenBench/Scripts/Repositories/weiss/src$ make
gcc -std=gnu11 -Wall -Wextra -Wshadow -Werror -Wmissing-declarations -O3 -flto -march=native -DUSE_PEXT -DNDEBUG *.c pyrrhic/tbprobe.c tuner/*.c query/*.c noobprobe/*.c onlinesyzygy/*.c -pthread -lm -o weiss -fprofile-generate="pgo"
In file included from pyrrhic/tbprobe.c:259:
pyrrhic/tbchess.c: In function 'pyrrhic_char_to_piece_type':
pyrrhic/tbchess.c:109:34: error: comparison of integer expressions of different signedness: 'int' and 'enum <anonymous>' [-Werror=sign-compare]
  109 |     for (int i = PYRRHIC_PAWN; i <= PYRRHIC_KING; i++)
      |                                  ^~
pyrrhic/tbprobe.c: In function 'prt_str':
pyrrhic/tbprobe.c:448:36: error: comparison of integer expressions of different signedness: 'int' and 'enum <anonymous>' [-Werror=sign-compare]
  448 |     for (int pt = PYRRHIC_KING; pt >= PYRRHIC_PAWN; pt--)
      |                                    ^~
pyrrhic/tbprobe.c:454:36: error: comparison of integer expressions of different signedness: 'int' and 'enum <anonymous>' [-Werror=sign-compare]
  454 |     for (int pt = PYRRHIC_KING; pt >= PYRRHIC_PAWN; pt--)
      |                                    ^~
cc1: all warnings being treated as errors
make: *** [Makefile:80: pgo] Error 1

After a closer inspection, it seems that the anonymous enum that encapsulates the constants such as PYRRHIC_PAWN becomes unsigned, because it includes enumeration values such as PYRRHIC_PROMOSQS = 0XFF000000000000FFULL. Experimenting with godbolt, it seems that GCC 13.1 has added this check with -Wextra. Reference: https://godbolt.org/z/eW4fnKMrY

while testing NoobBook in Weiss v1.5-dev, i'm exploring https://www.chessdb.cn/queryc_en/ for the first time .. for me, the following game (see attached ZIP) is a great example : it gave me some questions for improvement ..

i set no NoobBookLimit (=0) .. this position arose :

shashchess-vs-weiss.zip

[Event "engine-vs-engine"]
[Site " [https://lichess.org/jdvW1yDS](https://lichess.org/jdvW1yDS) "]
[Date "2021.07.15"]
[White "ShashChess v17.1 no NN"]
[Black "Weiss v1.5 dev 210715a"]
[Result "1-0"]
[FEN "rnbqkbnr/pppppppp/8/8/8/4P3/PPPP1PPP/RNBQKBNR b KQkq - 0 1"]
[GameDuration "00:30:13"]
[PlyCount "133"]
[SetUp "1"]
[Termination "adjudication"]
[TimeControl "720+5"]

 1.   e3 {Forced move.}      c5 {0.77s}
 2.  Nf3 {+0.07/30 19s}      d5 {0.52s}
 3.   d4 {+0.14/29 10s}      e6 {0.52s}
 4.   c4 {+0.14/29 19s}      cxd4 {0.52s}
 5. exd4 {+0.30/28 11s}      Bb4+ {0.52s}
 6.  Nc3 {+0.22/28 14s}      Nf6 {0.52s}
 7. cxd5 {+0.14/28 11s}      Nxd5 {0.52s}
 8.  Bd2 {+0.23/29 22s}      Nf6 {0.54s}
 9.   a3 {+0.29/32 54s}      Be7 {0.52s}
10.  Be2 {+0.30/30 22s}      O-O {0.52s}
11.  O-O {+0.30/31 45s}      b6 {0.51s}
12.  Ne5 {+0.61/30 16s}      Qxd4 {-0.51/31 31s}
13.  Bf3 {+0.76/30 11s}      Qxe5 {-1.07/30 26s}
14.  Re1 {+0.92/30 0.001s}   Qf5 {-0.96/29 42s}
15. Bxa8 {+0.84/29 17s} ...

position after 11.O-O : Black to move.

it's a game SF ShashChess v17.1 (without NNUE) vs. Weiss v1.5-dev. -- 12 min each side + 5 sec bonus.

here are the first few moves .. after 11.O-O it's Blacks turn : Weiss plays 11...b6 and gets a stunning reply : 12.Ne5 !
Weiss took pawn d4, which seems poison .. this position is just after the last existing NoobBook position : now, Weiss calculates on its own (you can see the CuteChess eval duration times in the PGN, 0.51 or so must be that connection speed with CDB) .. i checked the position online at https://www.chessdb.cn/queryc_en/ and move 11...b6 seems the only "known" move in this NoobBook, but maybe the pawn IS poison ..

i did some further tests with this position in SCID, with MPV 20, testing NN engines and non-NN : almost all NN engines drop the move b6 rather quickly, at depth 11 or so, but most non-NN engines favor b6 for a long time as one of the top moves !? We could consider this position a benchmark :-) You should study this one ..

All this brings me to this question : should we treat NoobBook like an Advisor ? : a source with its own move-evaluation-ranking-list of any position, but this list should only be "consulted" by Weiss, next to its own calculations / evaluations, then decide which "best move" is concluded.

i'm thinking of those (GitHub) projects which play chess according to 2 or more engines, often called master and slave(s).
but i don't know how these programmers write their decision functions ..

what do you think about all this ?

NOTE: it's a pitty Weiss has no MPV - that way, we can not see the b6 ranking, and how it changes by rising depth ..

Weiss crashes once every few thousand games in testing. My current hypothesis is that it's caused by a king getting captured, and a call to __builtin_ctzll() with argument 0 returns an arbitrary large number causing indexing of attack tables to segfault. This due to Weiss playing a lot of games without a single crash before the removal of the piecelists in #175 which changed the way the king square is determined to current.

Discovered by @Disservin, not sure if there's a problem or not, but seems odd.

position fen k4q2/5r2/Pp1p1r2/1PpPp1b1/4P1P1/2R2PB1/6Rp/5Q1K b - - 65 179
go
info depth 1 seldepth 6 multipv 1 score cp 37 time 0 nodes 44 nps 44000 tbhits 0 hashfull 0 pv f6f3
info depth 2 seldepth 6 multipv 1 score cp 37 time 3 nodes 87 nps 21750 tbhits 0 hashfull 0 pv f6f3 c3f3
info depth 3 seldepth 6 multipv 1 score cp 37 time 7 nodes 137 nps 17125 tbhits 0 hashfull 0 pv f6f3 c3f3 f7f3
info depth 4 seldepth 6 multipv 1 score cp 1595 time 10 nodes 201 nps 18272 tbhits 0 hashfull 0 pv f6f3 c3f3 f7f3 h1h2
info depth 5 seldepth 8 multipv 1 score cp 1595 time 14 nodes 287 nps 19133 tbhits 0 hashfull 0 pv f6f3 c3f3 f7f3 h1h2 f3f1
info depth 6 seldepth 9 multipv 1 score cp 1663 time 18 nodes 545 nps 28684 tbhits 0 hashfull 0 pv f6f3 c3c2 f3f1 h1h2 f1b1 c2b2
info depth 7 seldepth 11 multipv 1 score cp -111 time 22 nodes 1497 nps 65086 tbhits 0 hashfull 0 pv f6f3 c3f3 f7f3 g2f2 f3f2 g3f2 c5c4
info depth 8 seldepth 10 multipv 1 score cp -117 time 27 nodes 1799 nps 64250 tbhits 0 hashfull 0 pv f6f3 c3f3 f7f3 g2f2 f3f2 g3f2 g5f4 f2h4
info depth 9 seldepth 14 multipv 1 score cp -228 time 32 nodes 4254 nps 128909 tbhits 0 hashfull 0 pv f6f3 c3f3 f7f3 g2f2 f3f2 f1f2 f8f2 g3f2 c5c4```

I remember you started implementing MultiPV in Weiss .. for me, using MultiPV has several advantages esp. when analysing a certain position .. it's being said, and also stated in your README, to set MultiPV 1 for best performance, but i wonder if that's true .. as an example i give this position from the game Polgar vs. Berkes, Budapest Hunguest Hotels 2003 :

r1bq1r1k/p1pnbpp1/1p2p3/6p1/3PB3/5N2/PPPQ1PPP/2KR3R w - - 0 14

White to move. Here White can take the Rook on a8, but the move g2-g4 !? is best .. Judith Polgar found this move and won that game! When i let engines think about this position (i use SCID on Linux) most of them do not find g4, esp. with MultiPV 1, which is the setting when at tournaments or even regular games in eg. CuteChess (i also learned CuteChess misbehaves when using MultiPV > 1) .. most engines don't even consider the move at any moment - but modern SF finds it instantly .. surely :-)

Also the newest compiled Weiss v2.1-dev does not find g4 being best move at MultiPV 1 : when i let it think for 1 minute it reaches depth 35 but only considers Bxa8. This "behaviour" differs at higher MultiPV, my screencast (edit, under 5 minutes) can illustrate this : we see Weiss v2.1-dev evaluating the position at several MultiPV, starting at 1, then 8, 6, 4, 3 and 2 .. you may be surprised :

To me it seems a higher MultiPV forces an engine to consider other moves, which method then may soon (!) give a far superior best move : at first g4 had eval about -2, but finally it has about +2 !? This way of evaluating will not be perfect in all positions, but when using (some) MultiPV pruning seems better, although less high depth is reached because the engine needs CPU time to calculate all MultiPV moves ..

What are your thoughts about this ?

Hi,

I’m compiling your engine on a Raspberry Pi and until recently all has been good.

Today I compiled your latest code, and get these errors:
transposition.c:59:12: warning: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘size_t {aka unsigned int}’ [-Wformat=]
printf("HashTable init complete with %" PRIu64 " entries, using %" PRIu64 "MB.\n", TT.count, MB);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from types.h:5:0,
from makemove.h:5,
from transposition.c:7:
/usr/include/inttypes.h:105:34: note: format string is defined here
# define PRIu64 __PRI64_PREFIX "u"

I still get a binary, but I no longer get your ‘HashTable init’ on manual start-up via ./weiss

Before transposition.c changes:

Al@PicoChess:~ $ ./weiss98
HashTable init complete with 2097152 entries, using 32MB.
uci
id name weiss 0.8-dev
id author Terje Kirstihagen
option name Hash type spin default 32 min 4 max 16384
option name SyzygyPath type string default
option name Ponder type check default false
uciok

After transposition.c changes:

Al@PicoChess:~/weiss/src $ ./weiss
uci
id name weiss 0.8-dev
id author Terje Kirstihagen
option name Hash type spin default 32 min 4 max 16384
option name SyzygyPath type string default
option name Ponder type check default false
uciok

Thanks

Alan Cooper

hi,

while testing your Weiss v1.5-dev i discover it's thinking 41 (!?) seconds to "find" the only legal move in this position :

i think you should be able to fix this issue ..

NOTE: Weiss is not the only engine which does this.

This error might be related to another new check in GCC, as referred in:
#677

Guenther Simon@CAPPUCCINO MINGW64 ~/weiss/src
$ make pgo
gcc -std=gnu11 -Wall -Wextra -Wshadow -Werror -Wmissing-declarations -O3 -flto -march=native -static -DNDEBUG *.c pyrrhic/tbprobe.c tuner/*.c query/*.c noobprobe/*.c onlinesyzygy/*.c -pthread -lm -lwsock32 -o weiss -fprofile-generate="pgo"
lto-wrapper.exe: warning: using serial compilation of 2 LTRANS jobs
lto-wrapper.exe: note: see the '-flto' option documentation for more information
search.c: In function 'IterativeDeepening':
search.c:664:13: error: '<anonymous>' is used uninitialized [-Werror=uninitialized]
  664 |         if (setjmp(thread->jumpBuffer)) break;
      |             ^
search.c:664:13: error: '<anonymous>' is used uninitialized [-Werror=uninitialized]
lto1.exe: all warnings being treated as errors
lto-wrapper.exe: fatal error: C:\msys64\mingw64\bin\gcc.exe returned 1 exit status
compilation terminated.
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: error: lto-wrapper failed
collect2.exe: error: ld returned 1 exit status
make: *** [Makefile:80: pgo] Error 1

The error disappears when removing the -flto flag.

output from cmd (old quadcore Q8200)

uci
id name Weiss 2.1-dev r686
id author Terje Kirstihagen
option name Hash type spin default 32 min 2 max 33554432
option name Threads type spin default 1 min 1 max 2048
option name SyzygyPath type string default <empty>
option name MultiPV type spin default 1 min 1 max 64
option name UCI_Chess960 type check default false
option name NoobBook type check default false
option name NoobBookLimit type spin default 0 min 0 max 1000
option name OnlineSyzygy type check default false
uciok
isready
readyok
position startpos
go infinite
info depth 1 seldepth 1 multipv 1 score cp 68 time 1 nodes 49 nps 24500 tbhits 0 hashfull 0 pv b1c3
info depth 2 seldepth 2 multipv 1 score cp 49 time 18 nodes 133 nps 7000 tbhits 0 hashfull 0 pv b1c3 b8c6
info depth 3 seldepth 3 multipv 1 score cp 68 time 35 nodes 221 nps 6138 tbhits 0 hashfull 0 pv b1c3
info depth 4 seldepth 6 multipv 1 score cp 40 time 51 nodes 2227 nps 42826 tbhits 0 hashfull 1 pv b1c3 e7e6 e2e3 d7d5
info depth 5 seldepth 8 multipv 1 score cp 53 time 73 nodes 3326 nps 44945 tbhits 0 hashfull 1 pv b1c3 e7e6 e2e3 d7d5
info depth 6 seldepth 11 multipv 1 score cp 41 time 131 nodes 54075 nps 409659 tbhits 0 hashfull 8 pv b1c3 b8c6 e2e3 d7d5 d2d4 e7e6
info depth 7 seldepth 13 multipv 1 score cp 59 time 170 nodes 78542 nps 459309 tbhits 0 hashfull 14 pv b1c3 d7d5 e2e3 d8d7 d2d4 g8f6
info depth 8 seldepth 17 multipv 1 score cp 53 time 733 nodes 800978 nps 1091250 tbhits 0 hashfull 140 pv b1c3 d7d5 g1f3 g8f6 d2d4 e7e6 e2e3 f6e4
info depth 9 seldepth 20 multipv 1 score cp 63 time 2793 nodes 3579149 nps 1281012 tbhits 0 hashfull 450 pv e2e3 g8f6 d2d4 e7e6 g1f3 b8c6 c2c4 f8e7 b1c3
info depth 10 seldepth 17 multipv 1 score cp 71 time 2830 nodes 3589461 nps 1267912 tbhits 0 hashfull 451 pv d2d4 g8f6 e2e3 e7e6 g1f3 f8e7 f1e2 e8g8 e1g1 f6e4 b1c3
info depth 11 seldepth 19 multipv 1 score cp 68 time 2868 nodes 3603454 nps 1255996 tbhits 0 hashfull 453 pv d2d4 g8f6 e2e3 e7e6 g1f3 f8e7 f1e2 d7d5 e1g1 b8c6 f3e5 c6e5 d4e5 f6e4 c2c3
info depth 12 seldepth 21 multipv 1 score cp 82 time 2909 nodes 3618253 nps 1243385 tbhits 0 hashfull 454 pv d2d4 d7d5 e2e3 b8c6 g1f3 e7e6 b1d2 f8e7 c2c4 g8f6 c4d5
info depth 13 seldepth 25 multipv 1 score cp 85 lowerbound time 3011 nodes 3691091 nps 1225461 tbhits 0 hashfull 463 pv e2e4
info depth 13 seldepth 25 multipv 1 score cp 88 time 3043 nodes 3703641 nps 1216702 tbhits 0 hashfull 466 pv e2e4 d7d5 e4d5 g8f6 f1b5 c8d7 b5d7 d8d7 g1f3 f6d5 e1g1 b8c6 b1c3 e7e6 d2d3
info depth 14 seldepth 26 multipv 1 score cp 76 upperbound time 3132 nodes 3760083 nps 1200154 tbhits 0 hashfull 474 pv e2e4 e7e6
info depth 14 seldepth 29 multipv 1 score cp 85 time 3166 nodes 3772053 nps 1191049 tbhits 0 hashfull 477 pv e2e4 e7e6 g1f3 d7d5 e4d5 e6d5 d2d4 g8f6 f1d3 f8e7 e1g1 e8g8 c1g5 d8d7 f1e1 b8c6
info depth 15 seldepth 28 multipv 1 score cp 75 time 3264 nodes 3838830 nps 1175751 tbhits 0 hashfull 487 pv e2e4 e7e6 g1f3 d7d5 e4d5 e6d5 d2d4 g8f6 f1d3 f8d6 e1g1 e8g8 f1e1 b8c6 b1c3 c8g4
info depth 16 seldepth 29 multipv 1 score cp 75 time 3373 nodes 3912305 nps 1159545 tbhits 0 hashfull 499 pv e2e4 e7e6 g1f3 d7d5 e4d5 e6d5 d2d4 g8f6 f1d3 f8d6 e1g1 e8g8 c2c3 b8c6 c1g5 d6e7 f1e1 f6e4 g5e7
info depth 17 seldepth 30 multipv 1 score cp 63 upperbound time 3659 nodes 4155130 nps 1135281 tbhits 0 hashfull 539 pv e2e4 e7e6
info depth 17 seldepth 30 multipv 1 score cp 78 lowerbound time 3997 nodes 4444708 nps 1111732 tbhits 0 hashfull 586 pv e2e4
info depth 17 seldepth 30 multipv 1 score cp 70 time 4098 nodes 4507072 nps 1099554 tbhits 0 hashfull 595 pv e2e4 e7e6 d2d4 d7d5 e4d5 e6d5 f1d3 f8d6 d1e2 g8e7 g1f3 e8g8 e1g1 c8f5 f1e1 b8c6
info depth 18 seldepth 29 multipv 1 score cp 82 lowerbound time 4622 nodes 4966906 nps 1074390 tbhits 0 hashfull 658 pv d2d4
info depth 18 seldepth 29 multipv 1 score cp 79 time 4680 nodes 5008799 nps 1070027 tbhits 0 hashfull 665 pv d2d4 e7e6 g1f3 g8f6 c2c4 b8c6 b1c3 d7d5 e2e3 f8b4 d1c2 e8g8 c4d5 e6d5 f1d3 f6e4 e1g1 b4c3
info depth 19 seldepth 31 multipv 1 score cp 67 upperbound time 5041 nodes 5315522 nps 1054248 tbhits 0 hashfull 695 pv d2d4 e7e6
info depth 19 seldepth 31 multipv 1 score cp 55 upperbound time 5705 nodes 5918391 nps 1037222 tbhits 0 hashfull 751 pv d2d4 e7e6
info depth 19 seldepth 31 multipv 1 score cp 71 lowerbound time 5985 nodes 6160567 nps 1029162 tbhits 0 hashfull 771 pv d2d4
info depth 19 seldepth 31 multipv 1 score cp 81 time 6064 nodes 6219333 nps 1025446 tbhits 0 hashfull 777 pv d2d4 e7e6 e2e4 d7d5 e4d5 e6d5 g1f3 g8f6 f1d3 d8e7 d3e2 c8e6 e1g1 b8c6 b1c3 e8c8 c1f4 a7a6 f3g5 c8b8 g5e6
info depth 20 seldepth 34 multipv 1 score cp 72 time 6480 nodes 6563792 nps 1012774 tbhits 0 hashfull 799 pv d2d4 e7e6 e2e4 d7d5 e4d5 e6d5 g1f3 g8f6 f1d3 f8e7 e1g1 e8g8 c2c3 c7c5 c1f4 d8b6 b1d2 b6b2 d1b3 b2b3 a2b3 b8c6
info depth 21 seldepth 35 multipv 1 score cp 74 time 7658 nodes 7609924 nps 993592 tbhits 0 hashfull 866 pv d2d4 e7e6 e2e4 d7d5 e4d5 e6d5 g1f3 g8f6 f1d3 f8e7 e1g1 e8g8 c2c3 c7c5 h2h3 c5c4 d3c2 b8c6 f1e1 e7d6 c1g5 c8e6 b1d2
info depth 22 seldepth 36 multipv 1 score cp 62 upperbound time 9324 nodes 9077740 nps 973484 tbhits 0 hashfull 920 pv d2d4 e7e6
info depth 22 seldepth 36 multipv 1 score cp 77 lowerbound time 10378 nodes 10007425 nps 964199 tbhits 0 hashfull 946 pv d2d4
info depth 22 seldepth 36 multipv 1 score cp 73 time 10558 nodes 10151833 nps 961438 tbhits 0 hashfull 950 pv d2d4 e7e6 e2e4 d7d5 e4d5 e6d5 g1f3 g8f6 f1d3 f8e7 e1g1 e8g8 h2h3 c7c5 d4c5 e7c5 c2c3 f6e4 d1c2 f8e8 b1d2 c5f2 f1f2 e4f2
info depth 23 seldepth 37 multipv 1 score cp 61 upperbound time 15608 nodes 14635752 nps 937648 tbhits 0 hashfull 991 pv d2d4 g8f6
info depth 23 seldepth 37 multipv 1 score cp 76 lowerbound time 16432 nodes 15352589 nps 934253 tbhits 0 hashfull 993 pv d2d4
info depth 23 seldepth 37 multipv 1 score cp 85 time 18391 nodes 17118364 nps 930750 tbhits 0 hashfull 995 pv d2d4 g8f6 c2c4 d7d6 b1c3 b8d7 g2g3 e7e5 e2e3 g7g6 f1g2 f8g7 g1e2 e8g8 b2b3 e5d4 e3d4 d8e7 e1g1 c7c6 f1e1 f8e8 h2h3

I've tried to compile Weiss with clang but the build crashed. I've found the cause of the crash. The function LandingSquareBB called by InitBitMasks relies on the fact that InitDistance is called. But as __attribute__((constructor)) doesn't guarantee any order of call, it's possible that LandingSquareBB is called before the distance array is even initialized.

After fixing that, the benches are different because of this. When either depth or moves is zero, the result will be +-inf which converted to int is undefined behavior thus causing the bench differences. I've found a way to fix this while being non-functional for gcc.

Additionally, there are some other undefined behaviors as tested by -fsanitize=undefined and gcc refuses to compile Weiss with no optimization.

edit 1: I've created a branch for this

Hey Terje! I'm planning on including Weiss in my FRC "Top 20" list. I use ponder ON with 1 thread per engine and a somewhat time control (30m + 5s).
Is ponder support in your plans? Weiss is currently at a disadvantage against every other engine in the list (all of them support ponder).

BTW I have tested 2.0 with BanksiaGUI in FRC and it's working like a charm. No timeouts, no illegal moves, no crashes (so far...).

In Weiss we trust.

Can you build a Korean chess engine?

how does time management work ?
all engines seem to know when to give a best move (which will stop their clock).
but how / when does it decide to stop the search and output a "best move" ?

i'm testing several UCI engines with the CuteChess GUI (on Linux), mostly setting a time-per-game of 10 or 12 minutes (plus some bonus sec). Within an amount of seconds, all engines reach a different depth, according to their processing speed : maybe the engine calculates / decides that a next depth would take too long, regarding the time-per-game .. i don't know how your engine decides that - and does it differ from the way other engines do it ?

maybe an engine can also take a certain position type in consideration, eg. one with possible tactics by sacrifices and/or a "closed centre" (by stucked pawns) .. maybe it uses several search types depending on the position(type) and play time - i'm not refering to "personalities" like Rodent has, i only wonder about time management.

It's sad that it's not possible to compile the newest version on Android and Linux devices.

Very rarely the engine plays an illegal move, searching and moving for the wrong side, despite at least seemingly having read in the correct position (and side) to search.

The bug was discovered during #16 , but was introduced before that as it was confirmed to also happen after #15 . It is assumed to have been introduced after #10 and testing so far seems to confirm this.

Congratulations with your strong Weiss engine ! I did several tests and it performs very well ! And it's only 108 Kb !!?

It also has the option to use NoobBook (when connected to internet), which is unique .. few engines have this feature !

One test game was against the very strong SF Crystal v3.2 NNUE, some StockFish clone (see https://github.com/jhellis3/Stockfish/tree/crystal ) : Weiss v1.5-dev almost managed to draw that game : in the very end it made some weak moves (65...Nc5??) and lost .. i attached that game PGN .. the concerning position -see screenshots- ( 8/8/n7/P3Pk2/8/6Bp/5K2/8 b - - 0 1 ) has 7 pieces, so i checked the tablebase at https://www.chessabc.com/en/tablebase and indeed it should be a draw ..

can you create a connection to a tablebase website, just as you connect to NoobBook for openings ?

Crystal-vs-Weiss_PGN.zip

i'm not a chess engine programmer myself, but i'm a chess fanatic and a web developer / programmer .. i do no C / C++ but mostly PHP and Python (and only Linux) .. i also gather chess engines and test them with CuteChess by letting them play against eachother and watch the game :-) In the meantime i learned many things about chess engine programming (in general) and i gave extended feedback to some engine creators, like Wasp, Halogen, RofChade, DON and more ..

i think your Weiss engine is rather special : it's strong, it has no NN(UE), it reaches high depth rather quickly and is only 108 Kb !

one of the main "ingredients" of a chess engine are the "piece square tables" .. i found in general those appear in 2 types : for the middle game and for the end game .. in your file psqt.c i see only 1 table (am i right?) .. i wonder : could it be possible & good to have different piece square tables, even dynamically ? I mean, according to the position some "rules" might be applied to determine a unique piece square table !? Those rules may act as some kind of pre-processor for the position ..

NOTE: you might take a look at the PeSTo engine : http://rofchade.nl/?p=307