uci vs winboard

[jasper.sinclair]

I played several kaissa games with uci version vs winboard version
and was surprised to see that the uci version output was more accurate info than winboard.

for ex: here's an extract form the Arena log file (the position is a dead draw)

Code: Select all

2026-05-20 18:48:21.772-->2:time 12153
2026-05-20 18:48:21.772-->2:otim 9371
2026-05-20 18:48:21.772-->2:usermove a4a3
2026-05-20 18:48:21.772<--2:TIME: my=93.71 sec, opp=121.53 sec, inc=3.00, move=BLACK
2026-05-20 18:48:21.772<--2:Allocating 3677 ms for this move
2026-05-20 18:48:21.772<--2:1 -90 0 246 b6c6
2026-05-20 18:48:21.772<--2:2 -91 0 364 b6a6 f6f7
2026-05-20 18:48:21.775<--2:3 -106 0 502 b6c6 f6f7 a6c6
2026-05-20 18:48:21.775<--2:4 -106 0 862 b6c6 f6f7 c7d6 a3b4
2026-05-20 18:48:21.775<--2:5 -90 0 1177 b6c6 f6c6 c7c6 a3b3 c6c5
2026-05-20 18:48:21.775<--2:6 -90 0 1381 b6c6 f6c6 c7c6
2026-05-20 18:48:21.781<--2:7 -90 0 1649 b6c6 f6c6 c7c6
2026-05-20 18:48:21.781<--2:8 -90 0 1846 b6c6 f6c6 c7c6
2026-05-20 18:48:21.784<--2:9 -90 0 2362 b6c6 f6c6 c7c6
2026-05-20 18:48:21.786<--2:10 -90 0 2953 b6c6 f6c6 c7c6
2026-05-20 18:48:21.788<--2:11 -90 0 4249 b6c6 f6c6 c7c6
2026-05-20 18:48:21.790<--2:12 -90 0 5731 b6c6 f6c6 c7c6
2026-05-20 18:48:21.792<--2:13 -90 1 11021 b6c6 f6c6 c7c6
2026-05-20 18:48:21.795<--2:14 -90 1 17617 b6c6 f6c6 c7c6
2026-05-20 18:48:21.813<--2:15 -90 4 38353 b6c6 f6c6 c7c6
2026-05-20 18:48:21.829<--2:16 -90 7 64390 b6c6 f6c6 c7c6
2026-05-20 18:48:21.923<--2:17 -90 16 156831 b6c6 f6c6 c7c6
2026-05-20 18:48:22.082<--2:18 -90 31 298853 b6c6 f6c6 c7c6
2026-05-20 18:48:22.092<--2:Search complete: depth=18, time=317 ms, nodes=298853
2026-05-20 18:48:22.092<--2:move b6c6

2026-05-20 18:48:22.319-->1:position startpos moves e2e4 e7e5 g1f3 g8f6 d2d4 d7d5 d4e5 f6e4 f1b5 c7c6 b5d3 f8e7 e1g1 e8g8 b1d2 e4c5 d2b3 c5d3 d1d3 c8g4 h2h3 g4h5 f1d1 b8d7 c1f4 d8b6 d3e2 a8e8 d1e1 e7d6 e2d3 d6c5 d3e2 e8e7 a2a4 f8e8 a4a5 h5f3 a5b6 f3e2 b6a7 e8a8 e1e2 c5a7 e5e6 d7f8 e6f7 e7f7 f4e3 f7e7 g1f1 b7b6 e3b6 e7e2 f1e2 a8e8 b6e3 a7e3 f2e3 f8g6 g2g3 g6e5 b3d2 e5d7 b2b4 d7f6 e2d3 f6e4 d2e4 e8e4 a1a6 e4b4 a6c6 g8f7 c6d6 b4b5 d6d7 f7f6 d3d4 b5b2 d7c7 b2b5 c2c3 h7h5 c7d7 f6e6 d7g7 b5b2 e3e4 b2d2 d4e3 d2c2 e3d3 c2f2 e4d5 e6d5 c3c4 d5d6 g7g5 d6c6 c4c5 f2f3 d3c4 h5h4 g5g6 c6c7 g3h4 f3f4 c4b5 f4h4 g6g7 c7d8 c5c6 h4h3 b5b6 h3b3 b6c5 b3h3 g7d7 d8c8 d7e7 h3h2 e7g7 h2c2 c5d6 c2d2 d6e6 d2c2 e6d5 c2d2 d5c4 d2c2 c4b5 c2b2 b5a6 b2a2 a6b6 a2b2 b6a5 b2c2 g7g6 c2b2 g6h6 c8c7 h6f6 b2b3 a5a4 b3b6 a4a3 b6c6
2026-05-20 18:48:22.319-->1:go wtime 93709 btime 124220 winc 3000 binc 3000
2026-05-20 18:48:22.321<--1:info depth 1 score cp 0 time 1 nodes 177 nps 177000 pv f6c6
2026-05-20 18:48:22.321<--1:info depth 2 score cp 0 time 1 nodes 197 nps 197000 pv f6c6
2026-05-20 18:48:22.321<--1:info depth 3 score cp 0 time 1 nodes 221 nps 221000 pv f6c6 c7c6
2026-05-20 18:48:22.325<--1:info depth 4 score cp 0 time 1 nodes 265 nps 265000 pv f6c6 c7c6
2026-05-20 18:48:22.325<--1:info depth 5 score cp 0 time 1 nodes 311 nps 311000 pv f6c6 c7c6
2026-05-20 18:48:22.327<--1:info depth 6 score cp 0 time 1 nodes 363 nps 363000 pv f6c6 c7c6
2026-05-20 18:48:22.327<--1:info depth 7 score cp 0 time 1 nodes 399 nps 399000 pv f6c6 c7c6
2026-05-20 18:48:22.330<--1:info depth 8 score cp 0 time 1 nodes 477 nps 477000 pv f6c6 c7c6
2026-05-20 18:48:22.333<--1:info depth 9 score cp 0 time 1 nodes 562 nps 562000 pv f6c6 c7c6
2026-05-20 18:48:22.336<--1:info depth 10 score cp 0 time 1 nodes 602 nps 602000 pv f6c6 c7c6
2026-05-20 18:48:22.337<--1:info depth 11 score cp 0 time 1 nodes 700 nps 700000 pv f6c6 c7c6
2026-05-20 18:48:22.339<--1:info depth 12 score cp 0 time 1 nodes 836 nps 836000 pv f6c6 c7c6
2026-05-20 18:48:22.341<--1:info depth 13 score cp 0 time 1 nodes 1008 nps 1008000 pv f6c6 c7c6
2026-05-20 18:48:22.343<--1:info depth 14 score cp 0 time 1 nodes 1165 nps 1165000 pv f6c6 c7c6
2026-05-20 18:48:22.346<--1:info depth 15 score cp 0 time 2 nodes 1503 nps 751500 pv f6c6 c7c6
2026-05-20 18:48:22.348<--1:info depth 16 score cp 0 time 2 nodes 1916 nps 958000 pv f6c6 c7c6
2026-05-20 18:48:22.348<--1:info depth 17 score cp 0 time 14 nodes 12404 nps 886000 pv f6c6 c7c6
2026-05-20 18:48:22.352<--1:info depth 18 score cp 0 time 28 nodes 25648 nps 916000 pv f6c6 c7c6
2026-05-20 18:48:22.353<--1:bestmove f6c6

After 75.a4a3 b6c6
8/2k5/2r2R2/8/8/K7/8/8 w - - 0 76
https://github.com/jasper-sinclair/Kais ... kaissa.png
https://github.com/jasper-sinclair/Kais ... ssa_wb.pgn

UCI side instantly recognizes:
score cp 0
all the way to depth 18,
while WinBoard side still thinks:
-90

?
IMO This is likely because WinBoard is relying on:
incremental state
repeated make/unmake
accumulated historical state
incremental history arrays
stack state
irreversible counters
repetition tables

IMO This exposes a real weakness:
repetition/draw-state handling inaccuracy/drift.
They change slightly over
150+ plies
and many make/unmake cycles
Winboard sees a slight losing eval...
i.e. it has no true/accurate repetition recognition

On the other side:
UCI is replaying the FULL game state every move, achieving correct repetition detection
draw adjudication is working
with a stable transposition behavior

So why is UCI is more accurate here?
Because every UCI command does
position startpos moves ...
which completely reconstructs:
exact board
exact move history
exact repetition state
from scratch.

In a nutshell:
UCI implementation is probably more correct than the original WinBoard.
UCI rebuilds the entire position from the full move list every move:
so repetition/draw state stays perfectly synchronized.

Old WinBoard code relies more on incremental internal history/state over hundreds of plies.
Over very long games, that historical state can drift slightly, especially for:
repetition detection
fifty-move handling
draw recognition

So in this example, the UCI side correctly recognized:
0.00 dead draw
while the WinBoard side still thought there were winning chances.

It appears that UCI (and it's verbose position loading mechanics) accidentally(!?) improved correctness.

What do you think?

[hgm]

Sounds like complete nonsense. In a correct implementation there should not be any difference in search results for different protocols. WB protocol does not use undo or remove commands during game play, so unmake should only be used during search, just like in UCI. Even if there is an incremental component in eval (as is usual for material / PST), unmake in search would treat that through copy-make, without touching the value at game level. Eval scores are treated as integers, so there should be no rounding errors anyway, no matter how often you make and unmake.

It is more likely that the implementations differ in what tables they erase (TT, history, killer) after each move.

[jasper.sinclair]

The perft results show show that Kaissa's movegen, make/unmake, and move legality are correct

The UCI implementation did not change search, TT, history, or killers, in any way...and it calls search in the exact same way as Winboard does.

So the discrepancy really seems to point toward repetition history, draw-state maintenance, abd/or incremental state maintenance.

It's certainly possible that what I observed with Kaissa is not that UCI itself is inherently superior to WinBoard, but that rebuilding
the full position from the complete move list every move (like UCI 'position startpos moves' does) can be better than relying on incremental
internal state maintenance, especially in old outdated engines.

It's also possible that Kaissa does indeed have a small innacuarcy somewhere in it's movegen/search/history architecture,
but I would expect that to be evident in the UCI output as well?

[hgm]

The point is that search is not supposed to change incremental eval components or game history. So in WB mode the position is also set up by loading all moves from the initial position, during the game, if you ignore all the searches that came between moves. The only difference is that it just does that once, instead of before every search.

Of course search would change the TT, history table and killer array. But in UCI the loading of the position is supposed to not change those; the new search you start would normally inherit these tables as the previous search left those. At least if the list of moves that was loaded is equal to that of the previous search plus one more move.

Takebacks (WB 'undo' or UCI loading a position with the last move clipped off) could be tricky; the TT would probably stay usable, killers and history of the previous search might not apply very well. That gets even worse if you take back multiple moves. But this would affect UCI and WB alike. And it should not happen in ponder-off games.

In ponder games a ponder miss might lead to taking back of the ponder move.

Also note that if there is a difference between the UCI and WB version, a more accurate result in a single position would not decide which is better. It is the average over many thousands of positions that would decide that. It will always be possible to find positions in which a weaker engine produces a more accurate result than a stronger one.