I have been testing floats rather than ints for the evaluation in GWD. As GWD uses embedding vectors for the evaluation of the neural network GWD no longer needs NNUE and evaluation using floats is just as fast as ints.
The idea was to add the material-balance 'behind the comma' to the evaluation rather than as an int (that pollutes the minimal-window) to avoid exchanges. You can get rounding-errors when using floats leading to inconsistencies like alpha + minimal_window == alpha, so you have to use 'scaled floats': floats multiplied by say a 1000 rounded (or truncated) to an int. The minimal window has to be the resolution of the evaluation, so if you use 1000 the minimal window should be 1e-3 (or 1 scaled). The 'int' version uses int((float output of the neural network) / (the average output of the neural network of positions without kings and one man difference)), the 'float' version uses int((float output of the neural network) / (the average output of the neural network of positions without kings and one man difference) * 1000);
Somewhat unexpected the float version searches a lot deeper (although the match result against Kingsrow stayed the same, suggesting that the match result is limited by the evaluation of the neural network), but this allowed me to explore tweaks (more conservative search extensions and reduction settings) that slow down the 'int' version of GWD too much. Some of the tweaks disable features, and surprisingly:
- I can disable TT based singular extensions in the float version: the match result stays the same. If I disable them in the int version the match result gets (much) worse.
- I can disable the quiescence search in the float version: the single-threaded match result is slightly worse than that of the int version, the multi-threaded match result is the same. If I disable the quiescence search in the int version both the single- and multi-threaded match result get (much) worse.
