gnuchess 5.07.1b

[F.Huber]

Well actually it shouldn't.... I forgot to translate castling and (less importantly promotion) moves...

Can we expect a fix for this problem?

[Michel]

Can we expect a fix for this problem?

I hope 5.07.152b fixes it.... See here

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

Regards,
Michel

[F.Huber]

I hope 5.07.152b fixes it....

SInce when should a programmer 'hope' that his program works?

Anyway thanks for it,
Franz

[Michel]

SInce when should a programmer 'hope' that his program works?

Well there's always one more bug as they say....

I think PG books are ok now. However there is still a bug in time management in UCI mode.

I had noticed that GnuChess lost quite often on time in Arena in bullet games. I thought is was just Arena using
time from the engine for its own purposes (which is a well known problem).

But it was really a bug. I have fixed it and will post new windows executables tonight.

[Michel]

Ok gnuchess-5.07.153b has been created here...

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

The time losses in UCI mode are gone.

[ignacioalex]

I'm trying to integrate gnuchess 5.07.153b with Haundrix Chess and I'm running into a minor issue: executing the program creates some files in the same directory as the gnuchess exectuable. However, in case of a system-wide install the location of the gnuchess executable will be a read-only directory, so is there a way to change the default location of these output files?

So far I have seen gnuchess.log, gnuchess.pgn and players.dat.

The location of players.dat seem to be hardcoded in players.c:

#define PLAYERFILE "players.dat"

so this would require changes in the code?

The location of gnuchess.log and gnuchess.pgn may be overridden by using the commands 'option LogFile="/path/to/file.log"' and 'option GameFile="/path/to/file.pgn"' after starting gnuchess. However, gnuchess.log is created during gnuchess initialization, and before the GUI has a chance to enter these commands.
Is there an alternate means of setting these properties via command line parameters or environment variables?

[Michel]

executing the program creates some files in the same directory as the gnuchess exectuable. However, in case of a system-wide install the location of the gnuchess executable will be a read-only directory, so is there a way to change the default location of these output files?

I agree this is not nice but does but this actually lead to a crash? In principle I check the return values of the fopen calls. But I will
go over this again.

For the moment I will create a small update which turns off all file generation by default.

Regards,
Michel

PS. I am working on a new version but it is currently too much in flux for release.

[ignacioalex]

I agree this is not nice but does this actually lead to a crash?

Maybe not, I didn't try it. It is just that I would like to create these files in a user's area instead of touching the program's install directory to keep them separate from other users' data.

For the moment I will create a small update which turns off all file generation by default.

That would be fine for me, thanks! In the future would it be possible to add a single option to set the output directory for all such files? It could be a command line parameter, environment variable or a command that the GUI could issue before these files get actually created.

PS. I am working on a new version but it is currently too much in flux for release.

Great to see GnuChess moving forward!

[Michel]

I posted gnuchess-5.07.153.1b here.

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

It plays exactly the same as gnuchess-5.07.153b so there is no need to test it.

Code: Select all

--- 5.07.153.1b

        * Usability fix: turn off all file generation by default.
   
        * Bugfix: In UCI mode GnuChess generated a result claim in winboard format.

        * Usability fix: the test for 64 bit detection has been inverted.
        So the android binary no longer thinks it is 64 bit. This needs a
        more portable solution!

As an experiment I made an android binary which can be imported in Aart Bik's "Chess for Android"
(available for free on the Market).

The binary plays pitifully slow as it has been compiled for an ARM1. But this means it should be easy to beat
which apparently for some people is a good thing.

I have not changed the default Hash size (49Mb). Please let me know if this is a problem for you.
It runs fine on my son's HTC Wildfire (with 320Mb RAM).

[Michel]

I have not changed the default Hash size (49Mb). Please let me know if this is a problem for you.
It runs fine on my son's HTC Wildfire (with 320Mb RAM).

I retrospect consuming 50Mb of (physical) memory seemed a bit excessive for a typical android app.
So I have replaced the binary with one where the default hash size is 24Mb.

[Michel]

I posted gnuchess-5.07.153.2b here.

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

The android binary exposed some bugs in time management: movetime had a granularity of 1 sec (like st in xboard mode).
Furthermore gnuchess did not check the time often enough, causing it to use vastly more time than allowed by movetime (at
low nps).

[abik]

I posted gnuchess-5.07.153.2b.

Works great! Thanks.

[Michel]

Thanks for the nice screenshot!

But... I found another bug which manifests itself only on very slow hardware (like the emulator) with the lowest difficulty setting on Chess for Android. GnuChess uses aspiration search with a small window. Up to now the initial window was essentially random. So it could happen that when searching depth=1 there would be a series of fail lows until the window had correctly adjusted itself. With very small movetime the search could time out before this happened. Then GnuChess would not have a move to play and would return (somewhat arbitrarily) "bestmove nomove". The solution is obviously to search depth=1 always with an open window.

A new binary is at the usual URL.

[abik]

A new binary is at the usual URL.

I am working on a simple engine-engine match feature in Chess for Android. Some screenshots and the PGN of a fast match between your latest binary and BikJump can be found at http://www.open-chess.org/viewtopic.php?f=7&t=601&start=25.

[Michel]

I posted gnuchess-5.07.170.5b here

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

* Gaviota Table Bases support.
* General cleanups.
* Slightly enhanced endgame knowledge.
* Singular extensions (inspired by Stockfish).
* IID (inspired by Stockfish).

In my testing it is somewhat stronger than gnuchess-.5.07.153.3b (latest released version) but
it is still a lot weaker than Fruit and hence than GnuChess 6.

The evaluation is still the old GnuChess 5 evaluation, and also still completely untuned.

To compile in the GTB support you need "libgtb" (either static of dynamic). The makefile that
comes with the GTB distribution will build a static libgtb.a. On Linux it will
also create/install a dynamic libgtb.so.

On Linux if "configure" cannot find libgtb, it will disable GTB support.

[F.Huber]

I posted gnuchess-5.07.170.5b here

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

Hi Michel,

what's this new TCEC GnuChess on your website?
I've already seen a TCEC compile from Jim Ablett, but I would like to know what special version this is.

[Michel]

It is identical to 170.5b except that it has a UCI option to set the compression scheme of the table bases.
This was necessary since Martin uses cp3 and I had hardcoded cp4 in the source. In the future
I will probably detect the compression scheme from the file extension.

To be honest I also fixed a small bug. The UCI option to set the GaviotaTbCache size was non-functional
(there was a == in the source which had to be a =). The default egtb cache size is quite small but
I believe Martin sets it to some gigantic number

[F.Huber]

To be honest I also fixed a small bug.

Thanks for the info, Michel.

But I wonder why no executables?

[Michel]

But I wonder why no executables?

Well generating 64 bit windows binaries is a bit messy for me (it requires two virtual machines, a recent Ubuntu to be able to run mingw64 and a Windows 7 to be able to test the executables, as stock wine does not support 64 bit yet).
So since this is just a small bugfix I decided to forgo the generation of windows binaries this time. Especially given the fact that Jim has kindly made compiles available which are a lot faster than mine anyway.