@ramhare said in #9:
> Here, actually, had I spent 10 seconds on the position, I would have seen it was unlikely to be white. Sorry. I was looking for a "black to move" instruction, though.
Did you solve it?
Yes I solved, but firstly I said the position is better for white 'cause of the d and e pushing pawn
Good question. Did not read the treatment yet. But, fast read over to make sure this comment was not part of the treatment.
There is another way that SF and all engine of similar cloth using NNue as trained per SF12 blog, could be attributed the term of oracle. Or to be more precise. How SF without NNue is an oracle.
Simply, NNue or its bigger master version (not clear to me as per many months ago if that is still the process, i assume it is), is being trained using SF classical of moderate search depth at its training input position, as an oracle, in some machine learning parlance, i.e. The score of that search at the input position is trained to approximate the oracle engine score if using a moderate depth search (in good generalization testing, yes, so that it does not only approximate the oracle on training position but also in positions not part of its training, represented by the set of all positions in the whole training set.. etc...). I suspect, versions since SF12 have been honing and optimizing speed along those lines.. perhaps varying the depth or other parameters of the training oracle. But here, i understand this is not what the question was about in essence.. I am making an initial tangent. However, it might tie into it, below.
This is compatible with the view that SF without or without NNue, is about predicting some deep material conversion of a signal that would be contained in the current position, if there is no material gain before such depth. In which case the human impression, would be that SF knows about positional signal of the current position.
The problem, is that it is an oracle of only position information that its classical leaf function is able to detect of the selected positions where it is allowed to actually look at the full position. This has been going on for many versions, and might have been pushed further on the "oracle" dimension, by adding such leaf of small imbalance extension search by approximation via NNue training.
So yes an oracle, but maybe a selective one. And i suspect that was not at all the treatment of the blog. Yet, I think it is a good question, and the sub-question of evaluation standard a few of us have noticed, and not only with last version (or is it of an other order of magnitude?) is one that could be considered by actually looking at the functional optimization process going on during fishtest, in light of the above, with taking parameters as variables, all of them and engine fishtesting, as its training or global optimization process, without generalization testing other than chess engine tournament pools. Here i stop my babble.
From a game theoretical point of view there are only two kinds of moves. Blunders, that is moves that make a won position lose or draw, or make a drawn position lose. And then all the other moves. Objectively speaking they are all the same and equally good.
Now from a pratical point of view of course, they are not the same. One winnable position can be better than another, if it is easier to convert. And conversely, one lost position can be better than another if it's easier to trick the opponent into a mistake. But this isn't an inherent property, rather it's a subjective thing. And being subjective, it mean people can disagree over it - with one another but also with engines.
So I really do think there is such a thing as an engine move.
from a game theoretical point of view. There are three possible outcome values.
There is nothing that say there has to be only one best move. And in order to even call one of those the best move, one would have to hold in ones hand the whole legal tree, in order to be able to compare all the possibilities.
In usual engine chess point of view, there is some assumption that the best engine tournament ELO is actually getting proprotionally or monotically going in the same increasing direction of bestness.... not that it might be only doing so in some restricted sandbox, be it sufficient to beat best individual human players. That is one thing, not really on topic..
But in the case of SF and its "species" of engine design or program of evolution across versions, there is something called an evaluation function supputate or postulated to be a good "predictor" or forecasting measure of something...
What is that something.. I would think it is the odds of outcomes that would happens if many games were played from the position with the evaluation (or score if backminmaxed from a tree search), or with some quality of moves, ideally perfect play. That seems to be accepted here on lichess, and also part of maia chess statistical analysis. or even lichess own conversion curves to interpret SF scores across game phases and ranges of such forecasting evaluation system.
I should say, that I am struggling with such issues... so i welcome contradiction, with some internals, not just contradicting conclusion, but finding arguments that would also allow me to see my errors, not just have to accept some statement from smarter than me... or more experienced than me.
So I don't think that we know the best move for those reasons. on one hand we have no way of knowing if the testing pool of engine in tournament and their current specifications is promoting the equivalent of exploring the full legal tree, and on the other hand, even if it were, that the forecasting postulated functions of position information over smaller and full tree and non-terminal leafs, are actually representing the odds if we had the full tree knowledge.
If has been assumed from the start that material counting was the fixed basis to base all further versions and parameter optimisation of said postulated forecasting function during that engine design program.. that SF has been folllowing and also recently slightly amending, by improving the quality of its leafs evaluation, as tested against other type of engine design we were lucky to have for some period in the testing tournament pools, even with specifications made for the pervious prorgram..
I think game theoretic point of view, and even if we had the full tree, would have to still rely of odds being compiled backward with some reward system based on terminal outcome being coutners over the huge tree. and brought backward to whatever truncated depths smaller tree of candidate paths we would stop to make a deicions on best move.
there, i think we can skip to the practical point of view, being also the game theoretic point of view being augmented with considering smaller tree when in a hurry.. so using the full tree to get rough summary ....
hope i did not babble in vains. i keep trying to explain this understanding, hope fully better each time. i also figure more of it as i read such threads and posts.. more heads is always better.
Best blog post picture ever!
