gnuchess 5.07.1b

[Michel]

I made an attempt to fix some of the cosmetical issue that gave gnuchess a "crappy" feel. I think I also fixed the time management code but I cannot explain why the previous code gave time losses. I cannot reproduce this on my computer.

Here are the fixes.

- The biggest change is that GNUChess now listens to input while searching.
This happens only in xboard mode since it messes up the display in
GNUChess's non xboard mode (anyone uses this still?). The input
polling code of GNUChess 5.07 is rather tricky. It uses a separate thread
with two locks and a condition variable. I hope I have not created
any deadlocks.
- As a consequence the ? (movenow) and quit commands now work at arbitrary times.
Thus xboard will no longer hang if you quit it while GNUChess is searching.
-No pondering if the plycounter is zero.
-The memory command is supported.
-"white" and "black" do not reset the engine when they are supposed to be noops.
-The number of moves to go till the next time control are kept up to date for both colors even when moves are forced.
This is important since the number of moves is used for the time budget.
- The output of the "post" command now follows the standard.
- sd works now
- GNUChess now distinguishes between illegal moves and illegal commands.
- The level command now supports the min:sec syntax.
- No more strange move reporting.
- Lots more debugging output suppressed.

Here is a test release. Only source code since I work on Linux and I do not know how to cross compile executables that use pthreads.

http://alpha.uhasselt.be/Research/Algeb ... s-release/

[Jim Ablett]

Hi Michel,

Nice job

I've compiled the Windows x64 & win32 Intel compiler pgo executables
and also fixed the src to compile ok with Windows Intel/Msvc compilers

http://www.mediafire.com/?kjgzymogzon


Jim.

[Michel]

Thanks a lot. That's a fast compile!

I left an annoying debug print in the output of the memory command (this has no practical consequences).

I'll wait a bit to see if there are other comments before posting a new version.

[F.Huber]

I'll wait a bit to see if there are other comments before posting a new version.

Ok, here is a comment:

Look at the analysis when GnuChess ponders, it seems to think about the opponents move but not about its own!?
No other GnuChess version (or any other engine) ever did this ...

[Michel]

Look at the analysis when GnuChess ponders, it seems to think about the opponents move but not about its own!?
No other GnuChess version (or any other engine) ever did this ...

Hmm. I'll have a look. I found some more bugs as well.

[H.G.Muller]

No other GnuChess version (or any other engine) ever did this ...

All my engines (that can ponder) think about the opponents move and not their own. There are many other that ponder this way too. Usually they give it away by showing the score with the opposite sign while pondering. (In Joker I invert the ponderscore befre printing, so it is less obvious.)

[F.Huber]

No other GnuChess version (or any other engine) ever did this ...

All my engines (that can ponder) think about the opponents move and not their own.

Well, of course I was talking about normal chess engines ...

[Michel]

Well, of course I was talking about normal chess engines ...

I think the standard format for the PV during pondering is (ponder_move) rest of PV. GNUChess now does it this way.

I flipped the sign of the score reported by GNUChess during pondering so that it now always reports from the engine's
POV.

[H.G.Muller]

Well, of course I was talking about normal chess engines ...

Then I wonder how you define normal. Beause it could very well be that most Chess engines actually ponder this way.

[Michel]

Ok I posted gnuchess 5.07.2b here

http://alpha.uhasselt.be/Research/Algeb ... s-release/

Various bug fixes. In particular there was a bug (not my doing!) which caused
gnuchess 4.07.2b to react very slowly to closing the xboard window. Remarkably
standard gnuchess did not suffer from this because the effect was undone by another bug.

TO Jim Ablett

I hope you can make a windows compile. To make your work easy I have tried to patch your sources
with the modifications 1b->2b. The result is here

http://alpha.uhasselt.be/Research/Algeb ... ja_pre.zip

Michel

[Jim Ablett]

Ok I posted gnuchess 5.07.2b here

http://alpha.uhasselt.be/Research/Algeb ... s-release/

Various bug fixes. In particular there was a bug (not my doing!) which caused
gnuchess 4.07.2b to react very slowly to closing the xboard window. Remarkably
standard gnuchess did not suffer from this because the effect was undone by another bug.

TO Jim Ablett

I hope you can make a windows compile. To make your work easy I have tried to patch your sources
with the modifications 1b->2b. The result is here

http://alpha.uhasselt.be/Research/Algeb ... ja_pre.zip

Michel

Here's the new Windows builds, x64 & win32 Intel compiler 11/10 pgo. No problems compiling the latest src.


http://www.mediafire.com/?zmzmqlzcwyg

Jim.

[Michel]

Thank you very much!

Michel

[Kirill Kryukov]

Thanks to Michel for fixing the horrible time usage bug! Also thanks to Jim for a fast 64-bit compile!

I started a gauntlet with GNU Chess 5.07.2b 64-bit JA. I'll wait for more games to finish before reporting about time losses (so far no time losses with this fixed version).

[Kirill Kryukov]

OK, a gauntlet of 64 games is complete, with 7 time losses by GNU Chess 5.07.2 64-bit JA. So far it looks the same like before, which means losing on time has not been fixed yet.

Time allocation with external book is fixed. GNU Chess was playing with external GUI-controlled book in this gauntlet, playing at about the same rate through the game.

[Michel]

So far it looks the same like before, which means losing on time has not been fixed yet.

Unfortunately I cannot reproduce this but I work primarily on Linux.

I am wondering if the cause is pthreads on windows....

Here is a version of GNUChess that does not use pthreads (so it is easy to compile with gcc on windows).

http://alpha.uhasselt.be/Research/Algeb ... b-npth.exe

Of course this will be slower than Jim's version since it has not been specially optimized.
But perhaps you can try it (I don't want to bother Jim with a new compile for every test version).

[Kirill Kryukov]

Thanks, I will start a gauntlet with this version tonight.

[Michel]

BTW Do you have a log of the time losses?

Is it GNUChess running out of time in the normal way or does it fail to start a game altogether?

Michel

[Kirill Kryukov]

I don't have log, but I'll be happy to save log if you remind me how to configure GNU Chess to do it.

It starts to play every game, and plays normally until finally running out of time. In the evening I will check at which move the time losses happen, if it is near the time control boundary or not.

[Michel]

I think I now observed a strange time loss as well....

EDIT: So do not bother testing this version!

[Kirill Kryukov]

Good. Very nice that you are looking into it. Because time losses do leave a bit of "crappy feel" in your own words. It does not happen every game, about 1 in 10 roughly speaking, in my tests. (GNU Chess 5.07 now finished 2048 games in my tournament - 1024 with external book, 1024 without).