From: <<mailto:[email protected]>[email protected]>
Date: Sat, Sep 11, 2010 at 4:40 AM
Subject: xboard
To: <mailto:[email protected]>[email protected]
Hi i use your programme for about more than 10 years maybe 20, i cant
remmember. I hate the premove and many features ... I like its simple
presentation. I saw they improved it, maybe too much ..? as you can see it
does not follow rules anymore! Maybe a bug in my computer debian squeeze
on nx7400. Anyway this does not have any importance, i am just happy to
win more often than before with this version.
This is purely an engine matter. In the past XBoard has always
unconditonally believed
engines when they sent the message that they had won the game (or in this
case, that
it was stalemate). You are still running it in thismode, but the modern
version has alternatives.
When you run with the option "-verifyClaims true", (which also can be set
through the
Options->Adjudications dialog), false engine claim would have been
corrected by XBoard
to a forfeit for the engine, and you would have seen the message "0-1
{False draw claim by engine 1}".
(On a true stalemate you would have seen "1/2-1/2 {Xboard adjudication:
stalemate}", at least
when the option -checkMates was true, which should be the default setting.)
Of course that will still leave the question why the engine (apparently
Fairy-Max 4.8O)
did not get the promotion right. It should understand under-promotions, and
with WinBoard
the Windows version of it does handle the current game correctly, when I
set it playing black
after 86... f2, and perform the under-promotion by hand. I will test under
Ubuntu later,
to see if there are problems with the Linux version of Fairy-Max, or that
XBoard somehow
does send the promotion move in a wrong format. In theory both Fairy-Max
and XBoard
should behave completely identicalin this respect under Windows and Linux,
though.
The most likely explanation is that there is a hash-table bug in Fairy-Max,
where it does
perform the proper under-promotion on its internal board, but fails to
correctly update its
hash key, so that it confuses the actual position with the Rook for a
position stored in the
hash table with a Queen, in particular the one after 88.Kh3, which will be
stored in the
table as an illegal position in the latter case. I will look into it, and
report later.
_______________________________________________
Bug-XBoard mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-xboard
