On 11/19/2010 03:03 AM, Joost 't Hart wrote:
Hi. Still Scid time.
> On 11/18/2010 07:38 PM, Matthew Twomey wrote:
>> I grabbed this from SVN and compiled it. I tried annotating with with
>> both Stockfish an Crafty.
>>
>> Stockfish UCI
>> -------------
>> Annotation appears to function as designed when "Annotate all moves" is
>> enabled.
>>
>> Crafty 23.1
>> -----------
>> About every other time I start a Crafty analysis, the annotation text
>> doesn't show the score, instead it just shows an Mx value (e.g. M1,
>> M6, ...etc). However it does this in non-mating positions. For example,
>> it indicates all moved it's suggesting are "M1" moves. Here is an
>> example:
>>
>> 1.e4=
>> Crafty v23.1:14:M1
>>
>> (14:M1 1.Nf3 Nc6 2.Nc3 Nf6 3.e4 e5 4.Bb5 Bb4)
>>
>> So this is obviously not a mate situation. Once it starts doing this, if
>> I exit SCID and restart it, the issue is usually resolved, but sometimes
>> I have to exit and restart a couple of times.
<zip>
> 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).
Will be in CVS today.
>> 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.
Cheers,
Joost.
<zip>
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
Scid-users mailing list
Scid-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/scid-users
