TalkChess.com

The depth value at the root will be approximately 22 + (distance to leaf). Indeed, but there is still a horizon problem, although the chances of getting something wrong diminishes when depth goes higher. The search breadth should be considerably wider than vanilla search from root position due to M...

The depth value at the root will be approximately 22 + (distance to leaf). Indeed, but there is still a horizon problem, although the chances of getting something wrong diminishes when depth goes higher. The search breadth should be considerably wider than vanilla search from root position due to M...

I have built a database using a slightly modified SF to adjust MultiPV depending on shallow search results. It now has about 2 billion unique positions, each analyzed with depth >=22 and MultiPV >=5, my experience is that eventually which engine or parameters you use becomes irrelevant - it converge...

I am not quite clear what the purpose of this is.

I believe that is used to filter known worse moves at root given WDL information.

I believe there is a misconception that being totally "zero" would introduce no bias at all, for one, statistically sound priors may not be the true distribution of their outcome under perfect play, those will in turn get magnified in RL process, in that sense the final strength is limited one way o...

There! I meant Xiangqi tablebases, I have never wrote a generator for chess.

They are time taken for each separate step, DTM is a bit faster because it reuses WDL tables and DTC usually requires more iterations. Note that almost a half of the time are spent on compression because they will quickly become huge without it. You need also consider the time needed to decompress s...

KBNK on single thread:

Build DTC:
45ms
Build DTM:
30ms
WDL with compression:
22ms W:721B B:751B
DTC with compression:
16ms W:2748B B:3060B
DTM with compression:
24ms W:2746B B:3060B

Like you said, it just need more complicated to handle all cases. There aren't much difference in theory, consider this: My_Foul + My_Foul = Lose, My_Foul + Opp_Foul = Draw, Opp_Foul + Opp_Foul = Win, how to correctly define all of them are just specifics. The main point of that paper is to introduc...

And second, http://www.chessdb.cn/query_en/?4k4/9/9/9/9/9/9/4BR3/Cr7/4K1B2%20w The tricky part is to make DTM tablebases, where this secondary counter cannot exist. One easy way is to build DTC first, then use the secondary counter in distance propagation to ensure progression, but this will cause s...