[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-XBoard] Fwd: xboard

From: h.g. muller
Subject: Re: [Bug-XBoard] Fwd: xboard
Date: Sun, 12 Sep 2010 13:47:43 +0200

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]