Stockfish 2.0 Available

[mcostalba]

Only if the entire PV is visible on your monitor.

...and if you are very fast at counting

[Jouni]

This Stockfish is finally good in most testsuites. Of course it's very difficult/impossible to verify 20+ improvements in test suite, but 2.0 is clearly better than 1.7-1.9. Almost sensationally it solves ALL positions in my old endgametest without tablebases This was the toughest position

[d]2n5/kP6/8/K7/4B3/8/8/8 w - - 0 1

Analysis by Stockfish 2.0 JA 64bit:

...
1.bxc8B Kb8 2.Bef5 Kc7 3.Kb5 Kd6 4.Kc4 Ke5 5.Kc5 Kf4 6.Kd4 Kf3 7.Be4+ Kf4 8.Bd7 Kg5 9.Ke5 Kh5 10.Kf4 Kh6 11.Bef5 Kg7 12.Ke5 Kh6 13.Kf4
+- (85.11) Depth: 53/67 00:03:08 1052mN
1.bxc8N+ Kb8 2.Nd6 Kc7 3.Nf5 Kd7 4.Bd5 Ke8 5.Kb6 Kf8 6.Be6 Ke8 7.Kc7 Kf8 8.Kd6 Ke8 9.Ke5 Kf8 10.Kf6 Ke8 11.Nd6+ Kd8 12.Nc4 Ke8 13.Ne5 Kf8 14.Ng6+ Ke8 15.Ke5 Kd8 16.Kd6 Ke8
+- (#27) Depth: 53/67 00:04:05 1360mN

Jouni

[Uri Blass]

This Stockfish is finally good in most testsuites. Of course it's very difficult/impossible to verify 20+ improvements in test suite, but 2.0 is clearly better than 1.7-1.9. Almost sensationally it solves ALL positions in my old endgametest without tablebases This was the toughest position

[d]2n5/kP6/8/K7/4B3/8/8/8 w - - 0 1

Analysis by Stockfish 2.0 JA 64bit:

...
1.bxc8B Kb8 2.Bef5 Kc7 3.Kb5 Kd6 4.Kc4 Ke5 5.Kc5 Kf4 6.Kd4 Kf3 7.Be4+ Kf4 8.Bd7 Kg5 9.Ke5 Kh5 10.Kf4 Kh6 11.Bef5 Kg7 12.Ke5 Kh6 13.Kf4
+- (85.11) Depth: 53/67 00:03:08 1052mN
1.bxc8N+ Kb8 2.Nd6 Kc7 3.Nf5 Kd7 4.Bd5 Ke8 5.Kb6 Kf8 6.Be6 Ke8 7.Kc7 Kf8 8.Kd6 Ke8 9.Ke5 Kf8 10.Kf6 Ke8 11.Nd6+ Kd8 12.Nc4 Ke8 13.Ne5 Kf8 14.Ng6+ Ke8 15.Ke5 Kd8 16.Kd6 Ke8
+- (#27) Depth: 53/67 00:04:05 1360mN

Jouni

The 85.11 evaluation suggests a bug in stockfish.
It suggests that stockfish can evaluate a drawn position as a winning position.

Uri

[Tord Romstad]

The 85.11 evaluation suggests a bug in stockfish.
It suggests that stockfish can evaluate a drawn position as a winning position.

Well, sort of. It's a bug in the sense that "SF thinks it is winning, but it's wrong", but not in the sense that "the code doesn't work the way the programmers intended". We've always been aware that the program doesn't realize that KBB vs K is a draw with two equal-colored bishops, and there's even a comment mentioning this:

Code: Select all

/// Mate with KX vs K. This function is used to evaluate positions with
/// King and plenty of material vs a lone king. It simply gives the
/// attacking side a bonus for driving the defending king towards the edge
/// of the board, and for keeping the distance between the two kings small.
template<>
Value EvaluationFunction<KXK>::apply(const Position& pos) const {

  assert(pos.non_pawn_material(weakerSide) == VALUE_ZERO);
  assert(pos.piece_count(weakerSide, PAWN) == VALUE_ZERO);

  Square winnerKSq = pos.king_square(strongerSide);
  Square loserKSq = pos.king_square(weakerSide);

  Value result =   pos.non_pawn_material(strongerSide)
                 + pos.piece_count(strongerSide, PAWN) * PawnValueEndgame
                 + mate_table(loserKSq)
                 + distance_bonus(square_distance(winnerKSq, loserKSq));

  if (   pos.piece_count(strongerSide, QUEEN)
      || pos.piece_count(strongerSide, ROOK)
      || pos.piece_count(strongerSide, BISHOP) > 1)
      // TODO: check for two equal-colored bishops!
      result += VALUE_KNOWN_WIN;

  return strongerSide == pos.side_to_move() ? result : -result;
}

I think I'll finally address this limitation in Stockfish 2.1 (but not in 2.0.1, because this is a bugfix release which is meant to be functionally equivalent to 2.0). It just hasn't seemed worth the effort so far, because this knowledge will obviously not give a measurable increase in playing strength. But because it will only require one or two extra lines of code, I can just as well do it.

The specialized endgame evaluation functions in Stockfish were not written in a very systematic fashion, and were never intended to be 100% complete. I added them one by one, whenever I got tired of watching Stockfish misunderstanding basic endgames that even I knew how to play and evaluate perfectly. Because the KBB vs K endgame with two equal-colored bishops didn't occur particularly often in games I watched, I never got sufficiently tired of this endgame getting misevaluated to add any special code for it.

Thanks to both of you for reminding us of this tiny little weakness.

[Sven]

The 85.11 evaluation suggests a bug in stockfish.
It suggests that stockfish can evaluate a drawn position as a winning position.

Well, sort of. It's a bug in the sense that "SF thinks it is winning, but it's wrong", but not in the sense that "the code doesn't work the way the programmers intended". We've always been aware that the program doesn't realize that KBB vs K is a draw with two equal-colored bishops [...]

I even think that KBB vs K with equal-colored bishops should be handled differently. It is a draw by FIDE rule, so the engine should always detect it as "end of game", maybe even outside the evaluation function. If the search never passes an "end of game" position to the evaluation function then the latter can be faster by avoiding to check the same conditions again (ASSERT()-ing instead).

The more general case for "KBB vs K" is: "there are only (2) kings and (>= 0) bishops on the board, and all bishops are standing on equal-colored squares". This includes "K vs K" and "KB vs K" as trivial cases, and also covers cases like "KBBB vs K" or "KB vs KB" with all white or black bishops on equal colors.

I would agree if you would call it a minor bug. But it is one, considering that a draw by FIDE rule is not detected.

Sven

[bob]

I find that SF 2.0 has approx. 20% lower kN/s than version 1.9.

Yes, 20% slower in terms of N/s sounds about right.

In SF 2.0 we have changed the way to account for the nodes that are now updated in do_move() instead of at the beginning of search()

The reason of the change is that is easier to count the nodes searched on a given sub-tree namely below a split point. Another reason is that code is simplified by this change.

Although there is no a real change in functionality due to this different accounting scheme, user sees a different speed, but actually nothing as changed in this regard.

Good to know that finally stockfish counts nodes correctly.
I think that nodes are moves that you make in the tree
If you go to the beginning of search() without making a new move then there is no new node.

Maybe, maybe not. If you always count at the start of search, you are counting them correctly, except that you exclude the moves you prune, where you might make the move, look at the resulting position, and then choose to prune/unmake the move without calling search. That make/unmake doesn't get counted. If you don't do that sort of pruning, then ++ing at the beginning of search will produce the same result as doing it in Make().

[bob]

Also nice, that SF2 displays selective dept now! But what is "Depth: 32/9"
actually meaning? Is it totally 41 ply?

The UCI protocol allows the engine to send two numbers, "depth" and "seldepth".

"depth" is usually used to display the iteration counter: All strong chess programs use a technique called "iterative deepening". This means that the program starts doing a very shallow search, then a slightly deeper search, and so on, until the allocated thinking time runs out. The "depth" displayed by the chess program is simply the number of such progressively deeper searches that has been performed so far.

"seldepth" has no standard meaning, and different programs use it for different purposes. In SF 2.0, it simply represents the length of the PV displayed by the program.

depth=32 and seldepth=9, as in your example, means that Stockfish is doing (or has just finished) its 32nd progressively deeper search from the root position, and that the length of the current PV is 9 plies.

I think that the common meaning of seldepth is simply the length of the longest line that the computer searched during the search.

I think that the length of the pv does not give us new information because you can calculate it simply by looking at the pv of the program.

Nor does "the length of the deepest search" provide anything useful. One might compute an average number that would be interesting. But in general, it is a useless number overall.

[mcostalba]

If you don't do that sort of pruning, then ++ing at the beginning of search will produce the same result as doing it in Make().

No does not if you don't count also null moves

Consider the common case of null move search:

do_move() -> search() -> do_null_move() -> search()

Currently we count 1 nodes, insted of 2 as it was in 1.9 when count was done at the beginning of search()