📝Greg Strong wrote on Sun, Feb 16, 2020 08:42 PM UTC:
Thank you very much for the help. I think I've gotten to the bottom it. It was tricky because there were several things going on.
I think the main problem was indeed with the TT. Those 169 scores you were seeing were mate positions but those weren't true mate scores. Amateur mistake here ... At some point I increased the value I was using to represent INFINITY (CHECKMATE) and I made the value larger than the number of bits I had reserve in my TT entry for storing the score. So those 169 scores kind of worked - it still prefered them to other things and prefered quicker mate, but other things didn't work. For example, the mate distance pruning didn't trigger because it didn't consider them mate scores. I'm sure there are other places in the code with similar issues.
I found this last night but correcting for it did not solve my problem because I had since introduced a new problem since the release of version 2.2. One of the things I'm doing for 2.3 is streamlining the code for Rules that store state information. Instead of each Rule-derived class handling this itself, I now derive Rules that store state information from a template class RuleWithState. Well, in doing that, I broke the DrawByRepetition rule and that was the reason I was still experiencing draws where there should have been wins.
Since things are still needing work on 2.3 and since this is a pretty major problem, I will release a service pack for version 2.2 today or tomorrow. I will also add the feature for saving the games for games in run in batch mode.
Thank you very much for the help. I think I've gotten to the bottom it. It was tricky because there were several things going on.
I think the main problem was indeed with the TT. Those 169 scores you were seeing were mate positions but those weren't true mate scores. Amateur mistake here ... At some point I increased the value I was using to represent INFINITY (CHECKMATE) and I made the value larger than the number of bits I had reserve in my TT entry for storing the score. So those 169 scores kind of worked - it still prefered them to other things and prefered quicker mate, but other things didn't work. For example, the mate distance pruning didn't trigger because it didn't consider them mate scores. I'm sure there are other places in the code with similar issues.
I found this last night but correcting for it did not solve my problem because I had since introduced a new problem since the release of version 2.2. One of the things I'm doing for 2.3 is streamlining the code for Rules that store state information. Instead of each Rule-derived class handling this itself, I now derive Rules that store state information from a template class RuleWithState. Well, in doing that, I broke the DrawByRepetition rule and that was the reason I was still experiencing draws where there should have been wins.
Since things are still needing work on 2.3 and since this is a pretty major problem, I will release a service pack for version 2.2 today or tomorrow. I will also add the feature for saving the games for games in run in batch mode.