Joost, I apologize for my slow reply here. I really appreciate all the work you're putting into SCID! I've caught up on the thread, but I think this may be the best email to base my reply on. I've downloaded and compiled the latest SCID from CVS as of today (Nov 28th).
On Fri, 2010-11-19 at 16:01 +0100, Joost 't Hart wrote: > On 11/19/2010 03:03 AM, Joost 't Hart wrote: > > A detail: Are you sure that the score in the variation goes in front of > > the move 1.Nf3? This would be something I cannot explain. I would > > expect 1.Nf3<score> Nc6 etc... > > Another, far more more serious, ouch! > A lazy UCI-only way of extracting the starting move from the engine line. > Crafty inserts a space character between dot-after-move-number and the move > itself... > > This corrupts the idea of inserting the starting move first (this fails), > adding a score (Ok) and then add the remaining moves (ok, but including > the starting move). > All M > Will be in CVS today. Yes - I see that that the score is now after the move, the way you were intending it. > > >> Another strange behavior is that sometimes it's suggesting moves that > >> actually have a score *lower* that it's analysis of the move that was > >> actually mode. For example it suggests a line that is +3.2 when it's > >> evaluation of the actual move that was made is +3.6. > > > > Can you be a bit more specific? Just dump a bit of annotated PGN if you > > have it available. What you tell us would indicate a bug (which is > > different > > from the one above), but I have no idea where to start checking. > > I cannot reproduce this, but this could be read as "I cannot reproduce this > any more after tackling the issue above". I am still interested in getting > a bit of PGN from you, but an explanation could be the following: > > As the engine progresses in the game, its horizon (the point beyond which > it cannot see what's going on on the board) also progresses. This means that > the engine can (will!) adjust the score of a certain line constantly. This > adjustment can be in both directions, in that the line can appear stronger > or weaker than it appeared before. > > This is one of the reasons why the annotation checks if the engine's > best-move is > equal to the move in the game. If that is the case, than we can forget > about the (previous) best-move score, and take the new game move score > instead, > simply because the latter is more accurate. > > The bug in the move extraction above also makes this move comparison fail, > which means that > > 1) Annotation cannot see that the best move is identical to the game move, > so it may add a variation that it should not add. > 2) The engine's horizon problem is not handled, so the reported score of > this > variation line may be better or worse than the game move score. > > Can you confirm that the first move in the variation with this lower score > is the same as the move in the main line? If not, the reasoning above is not > the explanation for what you have seen. I really have to apologize here. I'm slapping my own forehead for not saving the analysis which annotated this way. It happened twice in a single game. I can tell you that I'm analyzing the same game now with the current CVS SCID and I'm not seeing this behavior anymore. My experience with the this in the past, however, lines up with your theory: > Due to the horizon effect it can happen that the engine realizes in > hindsight that the game move is actually stronger than the best move he > expected. The first move in the variation was definitely not the same as the first move in the main variation. I was using 5 seconds per move on the computer though, so it may not have been seeing very deep during that session (or maybe some other process was eating CPU). In general - SCID annotation is now continuing to show moves that exceed the threshold I set even though it considers the game "won", and it's also showing faster mates. This is precisely the behavior I was hoping for! I think this capability will prove quite helpful for lower level players such as myself. Thank you so much! I also did an analysis with Stockfish, and I am noticing one strange behavior. In the annotation, it's showing a Mate-in-X that is one more that it should be. For example, it's showing: ##### 46.Ke6+ +-- Stockfish 1.9.1 JA 64bit: 100:M4 (46.Ne4 48:M4 46..Kc8 47.Bg3 Kd8 48.Nc5 Kc8 49.Ra8#) ##### So in the annotation, it's reporting this variation as "M4" but shouldn't it be showing up as "M3"? When I look at the actual engine window, it's showing "M3". It's doing this with all mate-in-x annotations. Thanks, -Matt ------------------------------------------------------------------------------ Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev _______________________________________________ Scid-users mailing list Scid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/scid-users
