White to move. Rybka cannot see the draw here. It gives a fanciful +4 for ever. Hmm...
(You're right: my tablebases stop at 5 men!)
I think TBs are critical for this position and many others. I was taking a not so subtle dig at those that believe that TBs offer no advantage, even in fixed depth games.
That would be my logic behind it, but I am no programmer and actually, that logic is so simple that I must assume it would have been done already if it is possible. So, there must be complications or problems about it, or I miss something important.
But I know that engines like Patzer and Little Goliath have special algorithms to detect long check series, evaluating them 0.00 disregarding the material balance, without having to calculate them until absolute certainty. I think those failed very rarely, and I think the benefit - often finding deep draws which sometimes would involve surprising sacs in the beginning - is clearly bigger than the risk. That may be something comparable.
a. if evaluation dead flat for each depth from n to n+10 (with say n>10 or whatever), with no material change, circular draw/fortress alert
b. pick main line position after n+10 plys (let's call it P)
c. evaluate P on its own to depth n+10
d. if evaluation of P static flatliner again
e. optionally do b. again on P+n+10 plys in the newly obtained main line
f. if another flatliner is obtained, fortress likely identified, evaluate the initial position as 0.
What are the odds that the engine won't be smarter with this in place, ie get it more frequently right than wrong?
The important thing is not to evaluate it as 0.00 but not to get this position in the first place when you have a winning alternative.
programs basically know only evaluation of the best line and do not know exact evaluation of something that is not in the main line
but only bounds.
The program may expect the opponent not to go to the fortress and it does not have evaluations of the fortress position at different depth to say that the evaluation does not improve.
It may be possible to evaluate the full path and not to evaluate position only based on the leaf but the problem is that in this case you will not be able to prune based on hash tables when the path is different.
> But if the current (board) position is +4 (statically) and after a depth of 11 or 13 plies it still has NOT grown to 4.5 at least, it isn't really such a big advantage because there is no progress. Maybe a 'no progress penalty' could be assigned.
I don't think it would work for these reasons:
1. The line could have a slight swing in where the first plies had a great rise (from about +4 to +5), and then plenty of "not as good" (to +3.5) and "but better than that" (+3.9) and this should not be penalized the same as one that jumped from +4 to +3.9 directly.
2. The statically position at the root means nothing, you are talking about 0 ply, and it could be totally wrong (Like ply 0 thinks you're winning by a rook, but ply 1 show you lose the queen and are suddenly losing by 4 pawns), so the score from there can't be used for anything. Also, if you go from hash, only the last moves have a score, so you get lost.
3. You are comparing PVs, that assume that the opponent will do best play, but in an actual game the opponent most probably won't follow these PV moves, so when you add a 'no progress penalty' and your engine avoids those 'no progress' moves, it's probably avoiding best play itself without a real reason.
4. When the engine changes best move, the evaluations of previous plies suddenly becomes important, so it should store them somewhere (store the evaluations of all the plies of all possible moves just in case that they become the new Principal Variation), and this would slow down the engine as to nullify the possible improvement.
5. What's this margin that should be achieved to not mark the position "no progress"? Maybe the position takes 14 plies to improve 0.49, but if you penalize it, the engine has to choose another move that doesn't improve as much.
So, I don't think that this is a good solution, though it sounds logical at first sight.
Assigning evaluation scores based on what happened earlier in the search tree introduces all sorts of complications with the transposition table. This is called 'path-dependent evaluation'.
Rybka does this in only one case - when the 50-move rule comes into the picture. I've decided that it's better in that case to make the adjustment abruptly (ie. 50 moves is assigned a draw score) than gradually, because the manoevering does often have a purpose.
If I could determine when further manoevering is pointless, then something better would be possible. Eventually, this will be improved.
Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill