You are right that it is impossible to return a draw-prediction from an alpha beta framework unless it is exact, i.e. you know it is a draw with best play or it is the Score of the end of the PV.syzygy wrote: ↑Sun Jul 05, 2020 3:20 pmSince you're overlooking draws here, it doesn't seem to be that intuitive...Pio wrote: ↑Sat Jul 04, 2020 11:58 pm Honestly I have always thought that it was strange that the win probability was not the standard. There is no problem using win probabilities in an alpha beta framework (just think opponent’s win probability = 1 - my win probability. Thinking in win probabilities is much more intuitive and can also help when tuning the evaluation, deciding on pruning thresholds... .
Reporting scores in centipawns has always worked quite fine, corresponds to how all engines used to work (this has changed now) and avoids making false promises that only confuse users.
Leela works very differently from conventional engines and naturally produces W/D/L predictions. For Leela to work with existing GUIs, it is forced to unnaturally convert W/D/L predictions to centipawn scores. That may not be ideal, but it is as it is. I don't think the solution is to require all existing engines now to be modified to produce W/D/L predictions.
That was not my point however. My point is that it is simple to convert an existing alpha beta engine to work with win probabilities (or should I say win or draw probabilities to satisfy you). Using my way of probabilities in alpha beta has many obvious advantages as I mentioned in my previous post. An additional gain is that can compress the storage space for the transposition table since a size of 10 bits should be more than enough and 8 bits might be sufficient. With 8 bits you could let 1 bit represent if the score is a special score or not and with the rest of the 7 bits tell either the “win or draw”-probability with a granularity of less than 1 % granularity or the distance to mate.
Even though the draw information cannot be reported correctly you could get an estimation by returning the W/D/L information from the end of the PV if you choose to use the draw probability within the engine. Even though the draw probability information by itself will not be passed in the alpha beta framework it could still be used to report an estimation to the GUI and it could also be used within the engine as a way of controlling how much you want to go for a win (contempt is the word I think). For example if you meet a weaker engine you could count draws less hoping for a win gambling for more uncertain lines. The same goes if you desperately need a win or draw in the last game of a tournament.
On a side note I have thought about that it would be really nice to have a different metric for endgame table bases. Would it not be nice to have an EGTB that for each position gives one of the moves that minimises the proof tree of the position. I understand it will take more space but it could be very useful for people wanting to train a neural network on endgame positions as well as for people wanting natural play of the engine in the endgame. Just an idea (since I am not able to do it by myself without a lot of work)