Dann Corbit wrote: ↑Wed Apr 17, 2019 2:26 am
Try this one in your favorite chess engine and you will see the problem immediately (unless some engine scores it zero):
[d]7r/6p1/7P/p1r1p1k1/Pp1pPp2/1PpP1Pp1/2P3P1/K6R w - -
Nice study. This is a draw where engine thinks its a win.
I have seen even worse where engines thinks the other side is winning when in fact it is the opposing side which wins.
I told my wife that a husband is like a fine wine; he gets better with age. The next day, she locked me in the cellar.
While I agree with you these situations are very rare and works both ways.
Adjudication massively speeds up the process of testing, and if only 1% of the games produce wrong results it's still worth to adjudicate.
Raphexon wrote: ↑Wed Apr 17, 2019 1:02 pm
While I agree with you these situations are very rare and works both ways.
Adjudication massively speeds up the process of testing, and if only 1% of the games produce wrong results it's still worth to adjudicate.
Speed vs accuracy.
I agree with your point that these situations are so rare that it's not worth slowly down the testing. However, I'm not even sure if it is a wrong result. If the White player wrongly evaluates the position as "clearly lost", enough to effectively resign, then I think a win for Black is the correct result. An engine's rating should factor in positions where it thinks it is clearly lost even when it is a draw. Then if the engine improves its evaluation of such positions, its rating will increase.
nothing helps. white always exchanges rooks, and it’s a fortress. saccing the remaining rook for the g-pawn also doesn’t work because opposition. nor even saccing the g pawn after that, still opposition.
Funny how humans can reduce the whole problem down to a few logical concepts, but nobody has found a way to do it algorithmically. Interestingly enough an algorithmic part-solution to many of these fortress positions (without sacrificing speed) is staring programmers in the face, but I don’t think anyone has ever realised it.
template<Tracing T>
ScaleFactor Evaluation<T>::scale_factor(Value eg) const {
Color strongSide = eg > VALUE_DRAW ? WHITE : BLACK;
int sf = me->scale_factor(pos, strongSide);
// Try to handle a fully blocked position with all pawns still
// on the board and directly blocked by their counterpart,
// and all remaining pieces on their respective side.
// Test position r7/1b1r4/k1p1p1p1/1p1pPpPp/p1PP1P1P/PP1K4/8/4Q3 w - - bm Qa5+
if ( pos.count<PAWN>() == 16
&& popcount(shift<NORTH>(pos.pieces(WHITE, PAWN)) & pos.pieces(BLACK, PAWN)) == 8)
{
Bitboard b, Camp[COLOR_NB];
for (Color c : { WHITE, BLACK })
{
b = pos.pieces(c, PAWN);
Camp[c] = 0;
while (b)
{
Square s = pop_lsb(&b);
Camp[c] |= forward_file_bb(~c, s);
}
}
if ( !(pos.pieces(WHITE) & Camp[BLACK])
&& !(pos.pieces(BLACK) & Camp[WHITE]))
return SCALE_FACTOR_DRAW;
}
// If scale is not already specific, scale down the endgame via general heuristics
if (sf == SCALE_FACTOR_NORMAL)
{
if ( pos.opposite_bishops()
&& pos.non_pawn_material(WHITE) == BishopValueMg
&& pos.non_pawn_material(BLACK) == BishopValueMg)
sf = 16 + 4 * pe->passed_count();
else
sf = std::min(40 + (pos.opposite_bishops() ? 2 : 7) * pos.count<PAWN>(strongSide), sf);
}
return ScaleFactor(sf);
}