Fail-hard search but Fail-soft transposition table look up?

[kubpica]

Hi, I noticed you are using the Fail-hard version of Alpha-beta algorithm but you are returning values from transposition table as if it was Fail-soft. So when you fail-high in search (beta-cutoff) you return beta, but in transposition table look up you return the stored value instead of beta. And when all moves fail-low you return alpha from search but in tt look up you return stored value (old-alpha instead of new-alpha). I think this is inconsistency. For more details look here: https://stackoverflow.com/questions/72252975/transposition-table-look-up-for-fail-hard-vs-fail-soft-alpha-beta-how-do-they-d

I am new to this stuff so I may be wrong, but it's very interesting, what you think?

[SebLague]

Hello! I've definitely done something wrong with the transposition table because I remember I was forced to clear it after each game move (which is obviously not ideal) because otherwise it was giving nonsensical results. Perhaps this is the issue. I will try looking into it when I have some time, but if it's something you're interested in trying to fix then feel free to submit a pull request.

[kubpica]

I did some research on clearing TT between moves and apparently you need to do it when you use more advanced replacing strategy than Always Replace (or better, implement "Aging"). But as you use Always Replace you don't need Aging and you shoudn't need to clear TT between moves. But I think the problem is with storing scores influenced by repetition draw. We shoudn't store in TT scores that were influenced by repetiton draws, because scores stored in TT should only depend on deeper positions and not previous ones (as sometimes we can reach the same position by different path). Draws by repetition can depend on positions prior to current one so we shoudn't store scores based on them in TT. Clearing TT between moves reduces the impact of this bug, but it's not the best solution. The easiest way would be to just not store positions that returned draw score, but it's not perfect as sometimes there can be cutoffs based on draw scores deeper (and these may not return draw scores but will be infuenced by them). The way I solved this in my column-draughts engine is that I calculate how many draws by repetition were found starting from current node and if it's bigger than 0 then I don't store score from this node in TT. Forum discussion about this: http://www.open-aurec.com/wbforum/viewtopic.php?p=186089#p186089

Here is my code: https://github.com/kubpica/Laska/blob/main/Assets/AI/LaskaAI.cs#L469 It's heavily commented so it should explain my tought process, it should also explain difference between fail-soft and fail-hard.

Anyway, your code and video helped me a lot, thank you! :)

[SebLague]

Thanks for taking the time to share your findings! When I return to this project I'll definitely take a look at your implementation and the posts you've linked. Would be great to get the TT working properly at last :)