In this release we have deeply rewritten the search, we don't expect a big ELO increase from 1.6.X series (if any), but we consider this the base upon which to build future changes.
Indeed new search is completely untested with long time controls, so it might scale much better or much worse than 1.6 series. In our tests (at short time controls) it performs a bit better then 1.6, but nothing earth shattering.
Please report any issue you may find, especially in compiling SF for different platforms. We have done our best to test the sources under as many compilers/OS as possible, but we know there are always surprises from this side.
As usual a big thank you to Jim for his optimized binaries and to the many people that reported bugs and sent patches.
mcostalba wrote:In this release we have deeply rewritten the search, we don't expect a big ELO increase from 1.6.X series (if any), but we consider this the base upon which to build future changes.
The updated search is a very nice read. Would you be willing to share some of your thoughts on the search changes and your plans for the future? I'm especially interested in the decision to do a full evaluation at every node, the new futility matrix, and the blocking moves pruning condition in qsearch. Open source is great, but I really love hearing the perspectives of authors and the ideas behind the code.
Maybe you should know that the older version v1.6.3 JA works with Fancy,
a special software for solving chess problems. (Popeye would be another
option, too) I have got these informations from here:
Aaron Becker wrote:
The updated search is a very nice read. Would you be willing to share some of your thoughts on the search changes and your plans for the future? I'm especially interested in the decision to do a full evaluation at every node, the new futility matrix, and the blocking moves pruning condition in qsearch. Open source is great, but I really love hearing the perspectives of authors and the ideas behind the code.
I can make an educated guess.
Having the full evaluation available at every node, if it can be done without a big performance impact (for example by restructuring the search) allows a multitude of extra pruning techniques to be tried.
I'm guessing they are currently trying to find the optimal parameters for those techniques, and I'd expect the next version to take a big leap.
Gian-Carlo Pascutto wrote:
I'm guessing they are currently trying to find the optimal parameters for those techniques, and I'd expect the next version to take a big leap.
Whoa! A big leap will make things very interesting at the top.