Re: [Bug-XBoard] Fwd: xboard

[h.g. muller]

> From:
> <address@hidden>
> Date: Sat, Sep 11, 2010 at 4:40 AM
> Subject: xboard
> To: address@hidden
>
>
> 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.