Its not a blunder. At first I wondered if you blundered a 3 move rep but it is not a 3 move rep obviously. No idea myself.
That's how the engine evaluates if you repeat the position.
This is a well known feature (or bug, depending on whom you ask), and isn't limited to Stockfish.
For example, from chessprogramming.wikispaces.com/Repetitions:
"Threefold repetition implies a position occurred thrice, that is repeated twice. When to score the position as a draw, however, is an entirely different matter. Most programs do this on the first repetition..."
Also check out the discussion at http://support.stockfishchess.org/discussions/problems/117-incorrect-evaluation-example
The discussions at http://www.talkchess.com/forum/viewtopic.php?t=51000&postdays=0&postorder=asc&topic_view=flat&start=0
and
http://www.talkchess.com/forum/viewtopic.php?t=48149&postdays=0&postorder=asc&topic_view=flat&start=0
also touch on this.
In the first of those talkchess links you'll see that several other engine authors do the same thing (Daniel Shawul of Scorpio and Robert Hyatt of Crafty, among others).
It's a conscious decision on the part of engine authors that doesn't really affect gameplay (there are one or two VERY rare cases where it could affect gameplay, one of which is pointed out by Hyatt in the first talkchess link), but does annoy humans quite a bit in analysis.
It's one of those things that isn't likely to change, because "fixing" it doesn't strengthen the engine's play (and gets more complicated to implement, with a small search overhead).
It's just something to be aware of.
Hope that helps :)
For example, from chessprogramming.wikispaces.com/Repetitions:
"Threefold repetition implies a position occurred thrice, that is repeated twice. When to score the position as a draw, however, is an entirely different matter. Most programs do this on the first repetition..."
Also check out the discussion at http://support.stockfishchess.org/discussions/problems/117-incorrect-evaluation-example
The discussions at http://www.talkchess.com/forum/viewtopic.php?t=51000&postdays=0&postorder=asc&topic_view=flat&start=0
and
http://www.talkchess.com/forum/viewtopic.php?t=48149&postdays=0&postorder=asc&topic_view=flat&start=0
also touch on this.
In the first of those talkchess links you'll see that several other engine authors do the same thing (Daniel Shawul of Scorpio and Robert Hyatt of Crafty, among others).
It's a conscious decision on the part of engine authors that doesn't really affect gameplay (there are one or two VERY rare cases where it could affect gameplay, one of which is pointed out by Hyatt in the first talkchess link), but does annoy humans quite a bit in analysis.
It's one of those things that isn't likely to change, because "fixing" it doesn't strengthen the engine's play (and gets more complicated to implement, with a small search overhead).
It's just something to be aware of.
Hope that helps :)
thanks a lot @a_pleasant_illusion, good links.
I just checked http://support.stockfishchess.org/discussions/problems/117-incorrect-evaluation-example
but it seems this is fixed in Stockfish 8. The eval doesnt drop on my system (Win 7, Stockfish 8).
I just checked http://support.stockfishchess.org/discussions/problems/117-incorrect-evaluation-example
but it seems this is fixed in Stockfish 8. The eval doesnt drop on my system (Win 7, Stockfish 8).
i have experienced the inverted case: Stockfish gives a big advantage for one side but repeats moves. However, it has been a while since i ran into this case, so it may be fixed in Stockfish 8.
@SelfmateMan : I don't remember seeing a patch changing that behavior, and I just checked it with SF8 and it also shows 0.
How exactly did you test?
To exhibit the behavior, SF has to know that the position has occurred already, so whether you see 0.00 is going to depend on what UCI commands are being sent.
If you use an interface that just sends the FEN of a position to the engine with no move history, then SF won't show the 0.00 eval.
If your interface sends the current position as the start position (or an earlier FEN, so long as the first occurrence of the repeated position is included) plus the moves to reach the current position, then it will.
So, if you open up the SF8 executable directly, so that you have a console window, try the following sets of commands (each command separated by pressing Enter in the console).
First set:
position fen 8/8/1p6/6p1/4PkP1/5P2/PPP1K3/8 b - - 3 42
go depth 20
Second set:
position fen 8/8/1p6/4k1p1/4P1P1/5P2/PPP1K3/8 w - - 0 41 moves e2d3 e5f4 d3e2
go depth 20
Both sets of commands bring you to the same point in the game, after white played the king from d3 back to e2.
The first gives the engine no history of the previous position and moves, and it will give a big negative score (score in UCI is for side to move, so black is losing, as he obviously is).
The second should both on SF8 and current dev version show a score of 0.
I'd wager whatever interface you're using is just sending the FEN of the current position with no move history.
Hopefully that all makes sense :)
How exactly did you test?
To exhibit the behavior, SF has to know that the position has occurred already, so whether you see 0.00 is going to depend on what UCI commands are being sent.
If you use an interface that just sends the FEN of a position to the engine with no move history, then SF won't show the 0.00 eval.
If your interface sends the current position as the start position (or an earlier FEN, so long as the first occurrence of the repeated position is included) plus the moves to reach the current position, then it will.
So, if you open up the SF8 executable directly, so that you have a console window, try the following sets of commands (each command separated by pressing Enter in the console).
First set:
position fen 8/8/1p6/6p1/4PkP1/5P2/PPP1K3/8 b - - 3 42
go depth 20
Second set:
position fen 8/8/1p6/4k1p1/4P1P1/5P2/PPP1K3/8 w - - 0 41 moves e2d3 e5f4 d3e2
go depth 20
Both sets of commands bring you to the same point in the game, after white played the king from d3 back to e2.
The first gives the engine no history of the previous position and moves, and it will give a big negative score (score in UCI is for side to move, so black is losing, as he obviously is).
The second should both on SF8 and current dev version show a score of 0.
I'd wager whatever interface you're using is just sending the FEN of the current position with no move history.
Hopefully that all makes sense :)
Yes, you are right of course. Scid only gives the fen and no moves. When i execute these commands in the console i get the results you predicted, "cp -1000" with the first and "cp 0" with the second. Very interesting. This also explains why it sometimes repeats the moves in my gui but still shows an andvantage for one side.
I think it is good to give 0.00 on the first repetition and as a reward gain more engine power. If one knows it, it is no problem.
I think it is good to give 0.00 on the first repetition and as a reward gain more engine power. If one knows it, it is no problem.
it also works when i force the engine: "position startpos moves g1f3 g8f6 f3g1" and "go depth 20 searchmoves f6g8" - awesome. I always thought engines ignore repetitions for performance reasons. But they dont.
Thanks all!
This topic has been archived and can no longer be replied to.