gnuchess 5.07.1b

[Jim Ablett]

GnuChess 5.07.4b JA Windows builds - x64 & win32

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

Jim.

[Michel]

I posted 5b. This will be the last version for a while. GNUChess will no longer make false draw claims. I also implemented the "." command (periodic updates) so there is some feedback during analysis.

Unfortunately I discovered a case of search corruption for the following FEN.

r1r4k/2q2ppp/4p3/4n1P1/1p1pQ2P/pP3P2/P1P1N3/1K1R2R1 b KQkq - 0 1

At ply 8 the evaluation drops to zero and the PV is bogus.

I have not observed this is in any game.

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

EDIT: To be clear. The search corruption bug is also in stock 5.07. It is not a result of my modifications.

[Dann Corbit]

Here is what I saw with that build:

Code: Select all

dcorbit@DCORBIT2008 /c/pgn/winboard-engines/gnuchess-5.07.5b/src
$ ./gnuchess
GNU Chess 5.07.5b
Adjusting HashSize to 1024 slots
Transposition table:  Entries=1K Size=48K
Pawn hash table: Entries=0K Size=32K
White (1) : xboard
new
post
sd 12
setboard r1r4k/2q2ppp/4p3/4n1P1/1p1pQ2P/pP3P2/P1P1N3/1K1R2R1 b KQkq - 0 1
go
1 240 0 89
1 238 0 188  f5 gxf6
2 247 0 2924  d3 Nd4 dxc2+ Qxc2 Qxc2+ Nxc2 Nxf3
3 323 2 15542  d3
3 323 3 24537  d3 g6 dxe2
4 402 6 52814  d3
4 454 10 83255  d3 Qxd3 Nxd3 c3 Qxc3 Nxc3 bxc3
5 471 23 193750  d3 c4 bxc3 Rxd3
6 465 67 614237  d3 c4
7 390 514 4692752
7 60 1333 10911392  Rab8 Qf4 Nc6
8 135 1460 11929994  h6
8 1170 2925 26395737  d3  xd3+
9 1090 3045 27439216
9 0 3186 28410633  d3  xc8+
10 0 3192 28451135  d3  xc8+
11 0 3225 28653814  d3  xh8+
12 0 3290 29040101  d3  xc7+
move d4d3
1 0 0 2  ( xh8+)
1 0 0 119  ( xh8+)
2 0 0 236  ( xh8+)
3 0 0 353  ( xh8+)
4 0 0 470  ( xh8+)
5 0 0 587  ( xh8+)
6 0 0 712  ( xh8+)
7 0 0 837  ( xh8+)
8 0 0 962  ( xh8+)
9 0 0 1087  ( xh8+)
10 0 0 1212  ( xh8+)
11 0 0 1337  ( xh8+)
12 0 0 1462  ( xh8+)
13 0 174 1052173  ( xh8+)
14 0 397 2460937  ( xh8+)
15 0 528 3641553  ( xh8+)
quit


dcorbit@DCORBIT2008 /c/pgn/winboard-engines/gnuchess-5.07.5b/src
$

[Michel]

8 135 1460 11929994 h6
8 1170 2925 26395737 d3 xd3+
9 1090 3045 27439216
9 0 3186 28410633 d3 xc8+
10 0 3192 28451135 d3 xc8+
11 0 3225 28653814 d3 xh8+
12 0 3290 29040101 d3 xc7+

The exact behaviour depends on the hash size etc... In this case the eval drops to zero at depth 9 and the PV contains
nonsense moves such as xc8+ .

The bug persists when disabling hash and null move.

The GNUChess source does not contain assertions. So it is quite difficult to debug.

[Michel]

Well the mystery is solved. The FEN is illegal!

There is no king on e8 but yet the FEN asserts that all castling rights exist.

So somewhere in the search a bogus castling move was generated.

EDIT: It seems such FEN's are actually generated by xboard when doing set position.

[H.G.Muller]

I thought I fixed that. Which XBoard version is this?

[Michel]

I thought I fixed that. Which XBoard version is this?

4.4.0 beta2.

[H.G.Muller]

OK, it could be I fixed it after that. The bug report in the forum has been sitting here a long time, but I nearly forgot about it and remembered just before the release that I never had acted on it. (Probably because the problem was already fixed in my mind as soon as i saw it.)

The faulty FENs happened after using the edit-position menu, correct? I had just never put code in there to determine castling rights after the setup was made, when I added castling awareness to WinBoard. But it should be there in the 4.4.0 release.

[Michel]

I expect GNU Chess to perform around 2400 in my tournament after it is fully fixed and a fast 64-bit compile is made.

Well I think the current GNUChess can be improved a lot. Its NPS is quite good. Slower than Crafty but faster than Toga for example.

Unfortunately the branching factor is much higher than Toga. GNUChess spends a lot of time analyzing moves which are obviously bad or irrelevant. Presumably its move ordering algorithm at CUT nodes is not optimal. IID might help here.

I need to make it print out statistics first.

EDIT2: The problem might be the hash table I think. It was designed for small size but probably it cannot cope with the large hash tables that are used today. As a result there is an excessive amount of collisions and many CUT nodes at low height are overwritten.

EDIT: I fixed the problem of GNUChess doing bogus searches after a setboard command with incorrect castling rights. It is good that this is fixed now in xboard but that wouldn't help people using older versions of xboard. They would incorrectly attribute this to a bug in GNUChess (as I did at first).

[Kirill Kryukov]

This is great that GNU Chess is being worked on after all these years. I will wait for more or less final/stable version with 64-bit Windows build, then I'll retest it for my tournament. Just let me know when you think it's ready.

[Jim Ablett]

GnuChess 5.07.6b JA Windows builds - x64 & win32

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

Jim.

[Michel]

To Jim: thanks!

To Kirill: I think this version is stable (it fixes all the issues I know off).

Ultimately I want to understand why GNUChess's branching factor
is so much higher than Toga's but that will be a while.

[Tim Mann]

It would be great if you would contact the "official" GNU Chess project at https://savannah.gnu.org/projects/chess and get them to include your fixes in the source tree there. That will help them get wider distribution.

I'd suggest offering to join the project so that you can check your changes in directly. That will be easier for the current project maintainers, since it seems like they are not actively working on the project anymore.

[ignacioalex]

The maintainers of the Debian package of Gnuchess have made some small modifications to Gnuchess 5.07:

http://packages.qa.debian.org/g/gnuchess.html

Do you think these would be worth including in a 5.07.7b release?

[Michel]

Do you think these would be worth including in a 5.07.7b release?

I think the Debian fixes are cosmetic. Eventually they should be incorporated.

Unfortunately I think GnuChess still contains fundamental bugs.

I fixed one: in some cases GnuChess would during search not recognize a promotion which resulted
in a pawn sitting on the 8th rank. This bug did not seem to affect playing strength as it was triggered quite rarely.

A more serious problem is that GnuChess seems to play weaker with more hash. I don't know why. I found a test position which triggers an explicit search bug related to hashing during analysis, but not in normal play.

On the positive side: I implemented LMR which increases the playing strength noticeably.

[ignacioalex]

Another area where there seems to be a lot of room for improvement is in the time management when playing under a fixed time per move time control (configured with the st command).

In a 60 seconds per move game, GNU Chess 5.07 only uses a fraction of the available time, typically about 6 seconds per move. In a 2 seconds per move game it simply forfeits on time as soon as it leaves the opening book.

In GNU Chess 5.07.6b things seem to have improved considerably: it will still use just a fraction of the total available time, but it no longer forfeits on time. However, when playing white it plays instantly and does not use any of the available time at all.

Perhaps most people who use GNU Chess play under standard time controls (configured with the level command), but I like to set 2 seconds per move games where I can sit and watch the gladiators fight!

[Michel]

Time management is a complete mess in GnuChess. It would need to rewrite it.

EDIT:

Is

level a b c

a legal level command if both a and c are non-zero?

[Michel]

Ok I posted 5.07.8b. Changelog

* Crude LMR implementation. It seems to increase the
strength of GNUChess somewhat.

* Fix of IsLegalMove{}. Sometimes it happened a pawn
got stuck on the 8th rank (this was related to killer moves).

* Fix of st command.

* Do node counting at beginning of search. This is easier.
Also: previously there was a bug which made GNUChess count
many nodes twice. As a result the reported nps was too
high by a factor of almost two.

* Help string for sd command was mangled.

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

The analysis bug is still unfixed (I don't know what causes it). Chances are that
this bug would also explain why GnuChess seems to play weaker with more hash.

It would be great if you would contact the "official" GNU Chess project at https://savannah.gnu.org/projects/chess

I did but so far the reaction has been very limited.

[ignacioalex]

It would be great if you would contact the "official" GNU Chess project at https://savannah.gnu.org/projects/chess

I did but so far the reaction has been very limited.

Maybe you should create a new fork in Source Forge.
I'm working on a GUI that I intend to release integrated with some engines out of the box (including Gnuchess 5.07.?b), and if you set up a bug tracking system I can contribute with bug reports.

[Michel]

Maybe you should create a new fork in Source Forge.

I don't really have the time to give GnuChess the makeover it deserves.

It is quite strange. The GnuChess source contains all the hard parts of a chess engine but the final product is not polished. For some reason everyone lost interest at version 5.07.

I am convinced that with proper bug fixing, profiling, tuning and implementing the newer search ideas GnuChess would become much stronger.

Sometime in the future I plan to export the parameters of the search and the evaluation function which will make tuning easier. But first I need to fix the analysis bug. Not much point in tuning a program that has major bugs.