gnuchess 5.07.1b

[Kirill Kryukov]

It's wonderful to see GNUChess under development again, after years of stagnation!

My top feature requests: 1. No crashes. 2. UCI. 3. Gaviota tablebases. (4. Stronger play)

All the best of luck to you in development!

[Kirill Kryukov]

By the way, I'd also like a clarification regarding how this project is related to GNU Chess project. Is it a completely independent fork now, or is the development synchronized with the original GNU Chess maintenance?

[Michel]

By the way, I'd also like a clarification regarding how this project is related to GNU Chess project. Is it a completely independent fork now, or is the development synchronized with the original GNU Chess maintenance?

You are correct to ask.

Version 9b is just some bug fixes. So it is basically still the same old GnuChess.

When I made the first such fixes I announced them on the GnuChess mailing list but got essentially no reaction.

Since the source of GnuChess 5.07 is messy (there are numerous undocumented global variables
which are accessed at random places) making small bug fixes is quite frustrating.

So that's when I decided to refactor things. Unfortunately this is for the moment indeed a completely
independent development. My development version is playing on FICS (GnuCheese).
It doesn't have any new features yet but at least it is stable.

I hope that when eventually I have some genuine new stuff to show perhaps the GnuChess maintainers
take interest.

[Michel]

I put up a new version of gnuchess here

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

(version gnuchess-5.07.94b).

It is in fact several months old since I find that chess programming unfortunately
takes too much time. I decided to make it public so that perhaps
other people can play with it. It is of course still a patzer.

Changes

Code cleanup.
Stability fixes (it has played 5631 games on FICS without crashes as far as I can tell).
Some endgame eval bugs fixed.
Recognition of wrong color bishop in KBPK endgame.
A rudimentary form of LMR and more aggressive nullmove pruning (borrowed from stockfish),
Decent hash table implementation (4 buckets).
True pv's (triangular array).
More feature options.

Caveats:
=======

When starting gnuchess with -s one should specify twice the number
from before.

E.g. gnuchess -s 2097152 now gives a hash table of 50Mb whereas
before it would give a hash table of 100Mb.

The book format has changed. I was planning to do away with the gnuchess
book format all together and replace it by the polyglot book format. But
first I would need to convert the gnuchess book (which has the advantage
that the source has been screened for GPL compatibility) to polyglot format.
So gnuchess 5.07.94b uses (more or less) polyglot hash codes
but is otherwise still in the old format.

[Michel]

Well I just played 1000 games of 94b against 9b at 1min+1sec time control.

94b came out with a score of 69%. According to BayesElo the elo difference
is 112.

I don't know if the difference will persist under longer time controls, but
in any case, given that I made only small tweaks, this suggests that
GnuChess still has a lots of room for improvement.

[Alex Guerrero]

Hi Michel.
I did a win32 compilation with MinGW and Gnuchess 5.07.94b has errors of adjudication with black pieces.

Code: Select all

[Event "Computer Chess Game"]
[Site "4
"]
[Date "2010.07.13"]
[Round "*"]
[White "GNU Chess 5.07.94b"]
[Black "GNU Chess 5.07 (JA:Rev 0.1)"]
[Result "0-1"]
1. d4 Nf6 2. c4 e6 3. Nc3 Bb4 4. g3 O-O 5. Bg5 d5 6. Nf3 Nc6 7. Bg2 h6 8. Bxf6
Qxf6 9. Rc1 dxc4 10. O-O Rb8 11. e3 b5 12. Ne4 Qd8 13. a3 Be7 14. a4 Ba6 15.
Nfd2 Nb4 16. axb5 Bxb5 17. Nc3 a6 18. Rb1 c5 19. dxc5 Bxc5 20. b3 Nd5 21. Bxd5
exd5 22. bxc4 dxc4 23. Nde4 Ba3 24. Qc2 Qe7 25. Rfd1 Qe6 26. Ra1 Bb4 27. Rd4
Rfc8 28. Rad1 Kf8 29. Nd6 Rc6 30. Nf5 Be7 31. Nd5 Bg5 32. Re4 Qxf5 33. Re8+
Rxe8 34. Qxf5 g6 35. Qb1 Kg7 36. Qa1+ Kh7 37. h4 Bd8 38. Qd4 Rce6 39. f3 Bc6
40. Qxc4 Bxd5 41. Rxd5 Bb6 42. Kg2 Bxe3 43. Rd6 R8e7 44. Rxa6 Bb6 45. g4 Rc7
46. Qb3 Rcc6 47. Ra4 Kg7 48. Qb2+ f6 49. Re4 Rxe4 50. fxe4 g5 51. Qb4 Kf7 52.
h5 Bc7 53. Qa4 Rc3 54. Qd7+ Kf8 55. Qh7 Be5 56. Qxh6+ Ke7 57. Qh7+ Kd6 58. Qf5
Rc2+ 59. Kf3 Rc3+ 60. Ke2 Rc2+ 61. Ke3 Rc3+ 62. Kd2 Rb3 63. h6 Rb2+ 64. Kd3
Rb3+ 65. Kc4 Rc3+ 66. Kb4 Re3 67. Qc8 Rxe4+ 68. Kb5 Re1 69. Qf8+ Ke6 70. h7
Rb1+ 71. Ka4 Ra1+ 72. Kb3 Rb1+ 73. Kc2 Rh1 74. h8=Q Rxh8 75. Qxh8 Ke7 76. Qh7+
Ke6 77. Qb7 Kd6 78. Kd3 Ke6 79. Ke4 Kd6 80. Qd5+ Kc7 81. Kf5 Kb6 82. Ke6 Ka6
83. Qb3 f5 84. Qc4+ Ka7 85. gxf5 Bh8 86. Qc7+ Ka6 87. Kd5 Be5 88. Qxe5 Kb7 89.
Kd6 Ka7 90. Qb5 g4 91. Kc6 Ka8 92. Qb7# 0-1 {White Mates}

[Event "Computer Chess Game"]
[Site "4
"]
[Date "2010.07.13"]
[Round "*"]
[White "GNU Chess 5.07.94b"]
[Black "GNU Chess 5.07 (JA:Rev 0.1)"]
[Result "0-1"]
1. d4 Nf6 2. c4 g6 3. Nc3 Bg7 4. e4 d6 5. h3 O-O 6. Bg5 c6 7. Bd3 e5 8. dxe5
dxe5 9. Nf3 Qd6 10. Be2 Qb4 11. Qd2 Be6 12. a3 Qb3 13. O-O Bxc4 14. Bxc4 Qxc4
15. Nxe5 Qe6 16. Bxf6 Bxf6 17. Ng4 Rd8 18. Qf4 Bxc3 19. bxc3 Nd7 20. Rfd1 Nb6
21. Qg5 Rxd1+ 22. Rxd1 Rf8 23. Nf6+ Kg7 24. Nh5+ Kg8 25. Rd8 f5 26. Nf6+ Kg7
27. Rxf8 Kxf8 28. Qh6+ Ke7 29. Nxh7 Nd7 30. Ng5 Qf6 31. h4 Kd8 32. exf5 Qxf5
33. Qg7 Kc8 34. g3 Ne5 35. Qe7 a5 36. a4 Ng4 37. Ne4 Kb8 38. c4 Qe5 39. Qd8+
Ka7 40. Qd3 Nf6 41. Nd2 g5 42. hxg5 Qxg5 43. Qd4+ b6 44. Qd6 Kb7 45. Qe7+ Kc8
46. Qe6+ Kb7 47. Nf3 Qg6 48. Qe7+ Ka6 49. Qd6 c5 50. Qc6 Ka7 51. Qc7+ Ka6 52.
Qc8+ Ka7 53. Qe6 Qb1+ 54. Kg2 Qg6 55. Qd6 Qg7 56. Qe5 Qf7 57. Qf5 Qe7 58. Ne5
Qg7 59. g4 Qb7+ 60. f3 Ng8 61. Qe6 Qg7 62. f4 Ka6 63. Kg3 Nf6 64. Qc6 Qf8 65.
g5 Nh5+ 66. Kg4 Ng7 67. Qb5+ Kb7 68. Qd7+ Ka6 69. g6 Qh8 70. Kg5 Qf8 71. f5 Qg8
72. Nc6 Qa8 73. Qc7 Qb7 74. Qxb7+ Kxb7 75. f6 Ne6+ 76. Kf5 Nf8 77. g7 Nd7 78.
g8=Q Kxc6 79. Ke6 Kc7 80. Qg7 b5 81. Qxd7+ Kb6 82. f7 bxc4 83. f8=Q Ka6 84.
Qfd6# 0-1 {White Mates}

[Event "Computer Chess Game"]
[Site "4
"]
[Date "2010.07.15"]
[Round "*"]
[White "GNU Chess 5.07.94b"]
[Black "Gnuchess_500"]
[Result "0-1"]
1. e4 e5 2. Bc4 Nc6 3. Nf3 Bc5 4. b4 Bxb4 5. c3 Ba5 6. d4 d6 7. Qb3 Qd7 8. dxe5
Bb6 9. exd6 Nf6 10. e5 Ng4 11. O-O O-O 12. Ba3 Ngxe5 13. Nxe5 Nxe5 14. Bb5 Qf5
15. d7 Bxd7 16. Bxd7 Nxd7 17. Bxf8 Rxf8 18. Nd2 Nc5 19. Qc4 Rd8 20. Qe2 Ne6 21.
Nf3 Qd3 22. Qxd3 Rxd3 23. Rac1 Nf4 24. Rfe1 Kf8 25. Kf1 c6 26. Ne5 Rd2 27. Rc2
Rd8 28. Nc4 Bc7 29. Rd2 Nd5 30. Rd3 Bf4 31. Ne5 f6 32. Nf3 Bc7 33. Nd4 Nf4 34.
Rf3 Re8 35. Rb1 b5 36. Nxc6 a6 37. Nb4 Re6 38. Re3 Rd6 39. Rbe1 Ng6 40. Re8+
Kf7 41. Ra8 Ba5 42. Ra7+ Kf8 43. Rb1 Ne5 44. Rxa6 Rxa6 45. Nxa6 Bxc3 46. Rxb5
Kf7 47. Ke2 Kg6 48. Nc5 Kf5 49. Rb7 g5 50. Rxh7 Bd4 51. Nb3 Bc3 52. a4 Ng6 53.
Kd3 Bb2 54. Nd4+ Ke5 55. Nb5 Kf5 56. Nd6+ Ke6 57. Nc4 Ba1 58. Ke3 Kd5 59. Nb6+
Ke5 60. Rd7 Kf5 61. a5 Be5 62. a6 Bf4+ 63. Ke2 Bb8 64. Rb7 Ne5 65. Rxb8 Nc6 66.
Rc8 Na7 67. Rc7 g4 68. Rxa7 g3 69. fxg3 Kg5 70. Rd7 f5 71. a7 f4 72. a8=Q fxg3
73. Qd5+ Kg6 74. Rd6+ Kh7 75. Qf7+ Kh8 76. Rd8# 0-1 {White Mates}


Logfile

1279239797.203125: OUT: 9 9999 0 486 Rd8#!
1279239797.203125: OUT: 9 9999 0 488 Rd8#
1279239797.218750: OUT: 10 9999 1 10934 Rd8#!
1279239797.218750: OUT: 10 9999 1 10936 Rd8#
1279239797.343750: OUT: 11 9999 14 57756 Rd8#!
1279239797.343750: OUT: 11 9999 14 57758 Rd8#
1279239797.453125: DEBUG: Timeout. RootMove=d6d8
1279239797.453125: OUT: 11 9999 25 100166 Rd8#
1279239797.453125: OUT: move d6d8
1279239797.453125: OUT:
1279239797.453125: OUT: My move is : Rd8#
1279239797.453125: OUT: 0-1 {White Mates}
1279239797.453125: DEBUG: Clear 0x4
1279239797.453125: DEBUG: Waiting for input...
1279239797.625000: IN: result 0-1 {White Mates}
1279239797.625000: IN:
1279239797.625000: DEBUG: Parsing input...
1279239797.625000: DEBUG: parse_input() called, inputstr = *result 0-1 {White Mates}

[Michel]

Thanks for reporting this.

This was indeed a bug (a copy pasted string which was incorrectly edited).

I wonder why I never got bitten by this. Perhaps because I always use
GUI adjudication so games are never played to mate.

I have posted a new version 5.07.94.1b.

I apologize for the silly version number but I have internally already a higher version number
and I did not want to collide with that one.

[Michel]

I have been running a match of Gnuchess 5.07.94b against Gnuchess 5.07.9b at time control 2+12 to see if the ELO difference persists under longer time controls. This seems to be indeed the case.

Code: Select all

Rank Name                 Elo    +    - games score oppo. draws
   1 GNU Chess 5.07.94b    36   24   24   503   62%   -36   48%
   2 GNU Chess 5.07.9b    -36   24   24   503   38%    36   48%


For fun I also ran (on a different, slower computer) a match of 100 games at 1+1 of 94b against the version of gnuchess that comes with Ubuntu 10.04. The result was 58(win)-7(loss)-35(draw).

[Michel]

I just posted gnuchess-5.07.143b here

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

This time there are 32 and 64 bit windows executables (since apparently people
like this). They are not pgo compiled though as currently my windows build
system is too messy (involving 64 bit versions of Ubuntu Maverick for building and
Windows 7 for testing in VirtualBox on an older 32 bit version of Ubuntu).

There is again elo gain at 1+1 time controls.

Code: Select all

Rank Name                                      Elo    +    - games score oppo. draws
   5 GNU Chess 5.07.141b                        83   15   15  1546   58%    24   27%
  14 GNU Chess 5.07.94b                          7   11   11  2991   54%   -16   33%
  35 GNU Chess 5.07.9b                        -115   18   18   998   31%     7   40%

This is against 4 opponents (pawny, gaviota, tornado and daydreamer).

The elo gain seems to be mostly due to improved tactics as the positional play
(in particular in the endgame) is still pretty bad (and perhaps got worse). I think the search can be sped up
easily by another 10/20% but further elo gain should come from optimizing/extending and
tuning the evaluation function (which has many glaring holes).

To do this I will have to revise my testing system (1+1 is just too slow for tuning).
This will have to wait at least a couple of months though as I will be busy with my
professional life.

[ignacioalex]

Congratulations for your continued interest and enthusiasm at moving GnuChess forward!

May I leave a feature request for future revisions of GnuCheese: add a user friendly way of adjusting the engine strength (something like Crafty's "skill" command). Althought this might not be of much interest to chess engine enthusiasts who are always squeezing the most performance they can get, I think it's an essencial feature for chess amateurs playing a casual game through their GUIs. Playing against an engine is not fun anymore after being crushed ten times in a row!

[Michel]

May I leave a feature request for future revisions of GnuCheese: add a user friendly way of adjusting the engine strength (something like Crafty's "skill" command).

I agree this is very nice. I also like Rybka's feature of setting the ELO. Some way of reducing the strength of GnuChess is on my TODO list.

Unfortunately there seems to be no consensus on what the best way is to reduce the strength of an engine. For example Crafty recently changed the
implementation of its skill command since skill 1 (which means almost random eval!) still gave you a 1600 player:

http://talkchess.com/forum/viewtopic.ph ... afty+skill

The most predictable approach to reducing strength is slowing down the search speed (speed/2 = elo-70).
But when you get into very low (predicted) elo this gives you an engine which is still too strong tactically (it will not leave a piece hanging).
So you have to introduce eval errors as well and then things get murky as this is very difficult to calibrate.

I will probably introduce two orthogonal options:

ReduceElo: reduce the search speed according to the formula above.
skill: introduce randomness in eval (like earlier Crafty).

[Michel]

Here is an !!!!unofficial!!!! version for possible testing which has a ReduceElo option.

http://alpha.uhasselt.be/Research/Algeb ... 44b.tar.gz

It is a quick hack which works by reducing the search speed using the standard
logarithmic law. I have limited the reduction to 600 elo since for some reason
my approach (inserting sleeps) goes haywire if the NPS become too low.
Negative numbers unfortunately also don't work.

In the end I didn't like the idea of inserting errors in the eval. So I did not implement
a skill command. I may introduce it later.

EDIT: Beware!!! Only use this version for the ReduceElo option. It has has a bug
so that it will be slower than it should be. Even if ReduceElo=0.

EDIT2: In the end this doesn't work well (GnuChess sometimes loses on time when
the speed is reduced). I think I will remove this again until I can make it work properly.

[Michel]

I just posted gnuchess 5.07.150b here

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

GnuChess now has a basic implemntation of the UCI protocol. That should make it much easier to use GnuChess
under Arena (the xboard protocol is supported as well).

Note that Arena autodetects GnuChess as a WinBoard engine. So you should change
it manually to UCI.

It would be nice to get some feedback on the windows executables (do they actually work?).
I do not use windows regularly so I cannot do much testing.

Another change is that GnuChess now understands polyglot books. I converted
the classic GnuChess book to polyglot format. You can find it here

http://alpha.uhasselt.be/Research/Algeb ... uchess.bin

This is perhaps not be the greatest book but it has the advantage that the source
is available and has been screened for GPL compatibility. See here

http://ftp.gnu.org/pub/gnu/chess/

[F.Huber]

I just posted gnuchess 5.07.150b here

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

GnuChess now has a basic implemntation of the UCI protocol.

WOW, great job Michel, many thanks!

After a few short games everything seems to work fine in this UCI version.

One question:
Would it be possible to also keep the support for the old book format (together with the new polyglot format)?
Maybe GnuChess could decide on the bookname extension (*.dat or *.bin) which book code it should use.
I'd just prefer the old book because the new one is almost 8-times as large.

Regards,
Franz

[Michel]

After a few short games everything seems to work fine in this UCI version.

Ok good! Thanks for giving it a try.

I'd just prefer the old book because the new one is almost 8-times as large.

This is weird. On my system the old book.dat is 3710751 bytes.

The new gnuchess.bin is 4431696 bytes. Indeed slightly larger but not 8 times as big!

In order not to have to use two sets of hash keys I converted gnuchess to use the same hash keys as polyglot.. So supporting the old book.dat format would mean reintroducing the old hash keys which I would rather not do since the gnuchess format is not understood by any other program.

PS. I noticed that the supposedly universal polyglot book gnuchess.bin is in fact only understandable by gnuchess! The hash key computation has a bug (an error introduced by cutting and pasting since it used to work). So I will have to post once again a new version and a new book. Sigh...

[F.Huber]

This is weird. On my system the old book.dat is 3710751 bytes.

Well, mine is 608827 bytes. Maybe it's from JA's compile, I can't remember.

PS. I noticed that the supposedly universal polyglot book gnuchess.bin is in fact only understandable by gnuchess! The hash key computation has a bug (an error introduced by cutting and pasting since it used to work). So I will have to post once again a new version and a new book. Sigh...

Yes, I already wondered why it didn't recognize an older book of Fruit (book.bin), I think this should have the same format as Polyglot!?

[Michel]

Yes, I already wondered why it didn't recognize an older book of Fruit (book.bin), I think this should have the same format as Polyglot!?

Yes that was the same problem. I just posted 5.07.151b at the above URL (and a new gnuchess book). Gnuchess should now really understand polyglot books....

[F.Huber]

Gnuchess should now really understand polyglot books....

Yes, it's working now, thanks!

[Michel]

Yes, it's working now, thanks!

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

In a polyglot book short castling is e1h1 whereas in UCI it is e1g1....

Unfortunately Arena is not happy with the former notation....(although you'd expect it wouldn't
mind since it support FRC where it is the correct notation).

[F.Huber]

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

I've just tried a few moves, so I didn't see these problems so far.