After the comments from Michael and Ron I've managed to spend some time with Hamsters. As a result, my wife won't talk to me. As a side effect though, I think I've found something.
There are huge score drops in some plies that suggest a serious bug somewhere. I've spent a few hours poking around to no avail, and yet I think this time asking for suggestions on the bug would be too much even for the collective wisdom of the CCC!
So my question is... how do I debug something like this that happens million nodes away from the root?!?
Isn't it more a deterministic odd-even effect rather than a randomizer? You have to analyze the end-positions in the pvs, causing the oscillating scores - your eval might be very sensitive by side to move. For instance, you may try to favour same color to move at the leaves in pv-nodes by doing/not doing pv-extensions near the tips.
To be honest, I don't have a clue what's happening. However, I've selectively enabled/disabled/changed most eval and search terms and it seems the problem is always there, although at different ply, score, etc.
In the first example it seems a 3-rep draw is found at ply 29... but then why it wasn't found at ply 28?
The weaker side standing pat at the leaves might be crucial here and probably worth an extra ply if in zugzwang, where only losing king moves or losing pawn moves are possible.
I suspect a hashtable bug. I suggest testing Hamsters while only using the hashtables for move ordering to see if the bug is still there.
If you are on a sidewalk and the covid goes beep beep
Just step aside or you might have a bit of heat
Covid covid runs through the town all day
Can the people ever change their ways
Sherwin the covid's after you
Sherwin if it catches you you're through
Alessandro Scotti wrote:After the comments from Michael and Ron I've managed to spend some time with Hamsters. As a result, my wife won't talk to me. As a side effect though, I think I've found something.
Hi! Your search/eval is quite good here as Hamsters seems to take way less nodes than Buzz here to reach the same ply:
Alessandro Scotti wrote:After the comments from Michael and Ron I've managed to spend some time with Hamsters. As a result, my wife won't talk to me. As a side effect though, I think I've found something.
In this position (best move is Kb1):
[D]6k1/3p4/3p4/3P4/4P1p1/6P1/8/K7 w - - 0 1
I get the following PV:
....
There are huge score drops in some plies that suggest a serious bug somewhere. I've spent a few hours poking around to no avail, and yet I think this time asking for suggestions on the bug would be too much even for the collective wisdom of the CCC!
So my question is... how do I debug something like this that happens million nodes away from the root?!?
My guess,
if you have some kingInsideTheSquareOfThePawn code, check it
else add it.
A no presence of this code can give this kind of beheavior.
Tony wrote:if you have some kingInsideTheSquareOfThePawn code...
A no presence of this code can give this kind of beheavior.
Tony
Actually it doesn't. Buzz doesn't have this kind of code but scores seem stable. Buzz's eval is very simple here too, pretty much basic pawn eval (doubled, isolated...) + passers. There's no king proximity to the pawn or any bonus for the king being closer to the center squares. Only a difference in pawn structure can change the score here for Buzz...although might be another reason for Buzz's sluglishness to get good ply in this position.
Tony wrote:if you have some kingInsideTheSquareOfThePawn code...
A no presence of this code can give this kind of beheavior.
Tony
Actually it doesn't. Buzz doesn't have this kind of code but scores seem stable. Buzz's eval is very simple here too, pretty much basic pawn eval (doubled, isolated...) + passers. There's no king proximity to the pawn or any bonus for the king being closer to the center squares. Only a difference in pawn structure can change the score here for Buzz...although might be another reason for Buzz's sluglishness to get good ply in this position.
Well.., yes.
Not having this code means that search will find out that the pawn promotes, meaning most of the time it becomes very inefficient.
Having it implemented wrong (fe an off by 1 wrt stm) would give more of a "I'm winning", "No I'm not" beheavior every other iteration, while the former can hide it with horizon moves (and will) and give less score jumps.
Not having this code means that search will find out that the pawn promotes, meaning most of the time it becomes very inefficient.
Having it implemented wrong (fe an off by 1 wrt stm) would give more of a "I'm winning", "No I'm not" beheavior every other iteration, while the former can hide it with horizon moves (and will) and give less score jumps.
Tony
I have this zugzwang in mind:
[D] 8/3p4/3p4/3P3k/4PKp1/6P1/8/8 b - -
If your eval recognizes this as drawish, your search will almost try to reach this position as a leaf with black to move. It interacts with path-dependencies from hash. Avoidrep-pruning becomes quite efficient.
Beside possible passer and square of king issues, co-ordinating squares might be even more important in this kind of endings.
Alessandro may have some bugs in eval or search (hashing) - therefor it is important to get the wrong evaluated positions from the primary variations.
