Hi,
I also noticed that bug in the probing code from your other email. It
was linked on CCC, for example here:
https://talkchess.com/viewtopic.php?t=68435
archive.org shows the code originates from 2009 at the latest.
On 10/26/25 05:26, h.g.muller" via XBoard and WinBoard bugs wrote:
I can reproduce this puzzling behavior. As you aready show in the hex-
dumps, the book is OK. Which means that the features Save Games to Book
and Commit to Book do work properly.
I'm not 100% sure about that. I read the hexdumps differently.
612d49983aa49672 0105 0001 00010001 ## Rf1
612d49983aa49672 0106 0001 00010001 ## Rg1
612d49983aa49672 0107 0001 00010001 ## Rh1
...
25.0% 1 Rf1 {1/1}
25.0% 1 Rg1 {1/1}
25.0% 1 Rg1 {1/1}
25.0% 1 Rg1 ## what happened ??
...
612d49983aa49672 0105 0001 00010001 ## Rf1
612d49983aa49672 0106 0001 00010001 ## Rg1
612d49983aa49672 0106 0001 00010001 ## Rg1
612d49983aa49672 0107 0001 00000000 ## Rh1 spooky
The reason I wrote "spooky" is because TWO Rh1 moves were displayed as
Rg1 in the dialog. "commit changes" changed the old one with the learn
value to Rg1, and kept the new one without the learn value as Rh1. If
it's a display-only bug we would expect 0105,0106,0107,0107. If the
display bug propagates to the save it might be 0105,0106,0107,0106 (new
Rh1 value affected) or even 0105,0106,0106,0106 (both Rh1 values
affected). What we actually see is difficult to explain by just one bug.
Something to do with how the code relates the text in the dialog to the
records in the book. The book "primary-key" should be the (zobrist,move)
pair. Join it with the (assumed-zobrist,move) from the dialog. Case (in
both) update. Case (not in the book) insert. Case (not in the dialog)
delete. At no time should the (move) in the book be updated.
--
Alan
