It is some time since I have been visiting this Discussion Board regularly, and I tended not to take much interest in items which majored on the 50-move rule as one cannot rely on FIDE not changing '50' to '60' or '40': they had tried to accommodate deeper endgames in the past. I had just been through a sceptical phase after reading Chessbase's neat April Fool story about FIDE raising the K-factor of the ELO system to 60 (which, at the time of writing, is not true). It is really good news that I can set aside my 'April fool' doubts as I hoped. Going from DTZ to DTZ50 is not going to reduce 3718 MB to 857 MB. without throwing away information that is already in WDL and for 2-sided tables) sounds about right, though maybe a bit on the high side. Of course in the end what matters is the combination of size and access time, since all tablebases can be "compressed" to the size of a tablebase generator.Īre you sure about that 857 MB? 3718 MB for "full" DTZ (i.e. In addition I only store the smallest of the "white-to-move" and "black-to-move" tables. I pick a value that I expect to improve compression) and I don't store the "sign" of DTZ50+ values (i.e. In the DTZ50+ table I store draws as "don't cares" (i.e. My DTZ50+ format depends on the WDL50+ tables being available. For positions that are won or lost but for the 50-move rule this is the distance to either a won/lost position 50 moves away from a zeroing move, or to a zeroing move leading to a position that is won or lost but for the 50-move rule. For positions that win or lose under the 50-move rule this is DTZ50. To be precise, I mean DTZ50+ as discussed here some years ago. However, assuming it is not, may I ask if by 'DTZ' you actually mean 'DTZ' - or do you mean 'DTZ50' (where Nalimov's EGTs are 857 MB, much nearer to your 561 MB).
0 kommentar(er)
