[New Version] v0.331 - Bug fix for Winboard and Chessbase interfaces

Changes:

• Fixed a bug that caused the feature command not being recognized by Winboard, and the first id command not being recognized by Shredder and Chessbase

Note: As I said in my previous post I think this should take care of the problems with both Winboard and Chessbase. (it takes care of the Winboard problem for sure)

mediocre_v0.331

[Bug] Both problems solved with one change (hopefully)

I found the problem with the Winboard interface, and I think it is the same with the Chessbase GUI (I will have to wait for Jim Abletts compiles to be sure, guess it is time I get a Java native compiler soon :).

In v0.32 and earlier when starting Mediocre without interface the welcome message and prompt did not show up until a dummy command was entered. This was due to Mediocre waiting for either uci or xboard to come as the first command to determine what protocol to use. If the first command was neither of those it went into line input mode.

I fixed this by always going into line input and if at any time uci or xboard was entered at the prompt, Mediocre switched to the protocol input instead.

But I forgot that I used print and not println for the prompt. This resulted in the feature line starting with the prompt (->feature ... instead of just feature ...), and apparently Winboard did not understand this and hence never received the feature command.

Which in turn resulted in the moves sent by the interface to the engine were on the form e2e4 and not usermove e2e4, so Mediocre could not recognize them.

The same happens in the UCI mode, only the second id command is received (the author one), while the name of the engine (id name Mediocre) is ignored since it is started with the prompt as well.

Hopefully this is why Chessbase GUI is having trouble. Shredder Classic only gives the author name and you have to input the engine name manually but at least it runs the engine afterwards.

Let us hope this takes care of both problems. :)

[Bug] Chessbase GUI problems

Seems I managed to seriously mess something up. :) Apparently Mediocre isn't running under the Chessbase GUI either at the moment.

Hopefully I will be able to fix it today.

[Bug] Winboard problems in v0.33

I have gotten a few reports that Mediocre is not running on the Winboard interface (but works with winboard protocol in Arena). I am trying to track down the bug, posting a fix as soon as I find it.

[New Version] v0.33 - Pawn and eval hash

Changes:

• Eval hash added
• Pawn hash added
• The zobrist keys are now pseudorandom, meaning they stay the same when restarting the application
• Pawn zobrist key added to the Board class
• Pawn eval divided between structure and passed pawns to fit with the pawn hash
• Switched name between 'depth' and 'ply' in the search, depth is the number of plies left to search ply is the number of plies deep the search currently is
• Fractional plies added
• Matethreat extension and pawn to 7th rank extension added
• It is now possible to change the transposition table size in the mediocre.ini file

Note: I am not so sure about strength difference between v0.32 and v0.33, the new version runs faster for sure but there might be some bug somewhere that I have no yet found. Anyway I thought I should release this and see how it works for other people.

I made new addition to the readme.txt about setting the hash table size, here it is so you do not miss it. :)

Mediocre now comes with mediocre.ini in which you can set the size of the hash tables, and decide wether the own opening book should be used.

Since Mediocre is a Java engine it gets 64mb RAM allocated by default. In the .bat file I have now added "-Xmx1024M" which allocates 1024mb RAM instead. This is NOT the size of the hash tables or how much RAM Mediocre will use, it is merely the maximum amount the application CAN use.

If you set the size of the hash table to anything larger than the allocated memory Mediocre will not run. If you want more RAM to be allocated simply increase the number in the -Xmx1024M (e.g. -Xmx2048M). Again this is not how much the application will use, but how much it can use. Decreasing the number will have no other effect than not making Mediocre start if hash table size is set to anything larger.

Have fun playing around with it. :)

Edit: Fixed the version number in the application. Thanks Jim for noticing.

mediocre_v0.33

[Other] A little update

I am still working on getting the new hash tables to work smoothly. I have not had that much time lately since final exams are coming up, but slow and steady wins the race. :)

I hope I will be able to work out the last quirks soon and start looking at pondering and new time management.

[Other] The Jonatan vs. Mediocre match

When I created this blog almost six months ago I had three goals. Mediocre should be able to:

• Play by all the chess rules
• Play on ICS (and versus other engines)
• Beat me in a match

The two first have been done for about five months now, but the last one I have put off.

Mainly because playing a match at classic time controls takes a lot of effort from my side and I want to be sure I get beaten since I probably won't have the motivation to play another match. :)

I think Mediocre is about ready to whoop the floor with me so I will plan a match in the near future, probably beginning of June.

The match will be 10 games at 2 hours per game. And if I get my personal ICC account up and running by then I will play it there (being a student I am a bit strapped for cash, that is the price you pay for too much spare time :).

I should have Mediocre v0.33 ready, and I will try to implement a few time management parameters since I have a feeling Mediocre uses the time pretty badly at longer time controls.

Hopefully I will also be able to implement ponder so Mediocre can play at full strength.

[Other] Still hashing

I have now divided the pawn evaluation so the passed pawns are separate from general pawn structure evaluation. This is needed since passed pawns depend on the king's position (and to some extent on other pieces as well) and that is not included in the pawn hash.

Running the selected.pgn YATS set to 8 ply fixed depth I get these results from v0.32 and the version with eval and pawn hash.

Analyzed Positions    : 26
Different Moves       : 0
Different Scores      : 0
Different Times       : 6

Time Mediocre 0.32    : 1:52
Time Mediocre dev     : 1:25

Nodes Mediocre 0.32   : 11.923.392
Nodes Mediocre dev    : 11.859.579

This is exactly what I am looking for, same evaluations and moves, only faster with the eval and pawn hash.

I will still have to do some testing to find the right sizes for the tables, but it seems to be working without bugs now at least.

[Other] Some hash statistics

As you know I am currently working with the eval and pawn hash for the evaluation. With both implemented it seems Mediocre goes from around 100.000 nodes per second to about 150.000 on my hardware (AMD Athlon 2500+). This is quite promising since it is a pure speed gain, i.e. the exact same number of nodes are visited for each ply of the same position, and the end result is (should be) exactly the same (same move and same evaluation).

From the start position searched to 10 ply I get:

evalHashHits 40409
evalHashMiss 100159
pawnHashHits 126433
pawnHashMiss 14135

As expected the pawn hash hits far more often than the eval hash.

While the eval hash seems to work flawlessly the pawn hash is having some problems. Sometimes returning wrong values, this is of course not acceptable, but instead of just fixing the bug I will take a look at how the pawn evaluation is handled and adjust it to work smoothly with the pawn hash.

[Other] Setting hash table size

I have been working a bit with an eval hash table and pawn hash table. The eval hash table seems to be a quite noticeable improvement and is very easy to implement, there are a few tweaks I can come up with but in general it is pretty straight forward.

The pawn hash table on the other hand is a bit more complicated since it is only part of the evaluation and some things needs to be worked out on every call to evaluation (like the attack table). To take full advantage of the pawn hash it also needs to store information about passed pawns so we do not have to find them every time.

Because of this I had some doubts of how much the pawn hash would actually help, but since the pawn structure changes very rarely it should be a nice boost as long as it gets implemented smoothly.

Sizes

Now Mediocre will have three hash tables, main transposition table, eval hash, and pawn hash (and the repetition table, but it is so small it hardly counts). So what sizes should these have?

In Scorpio the default sizes are 16mb for main transposition table, and 8mb each for eval and pawn hash. These ratios seems quite logical (i.e. twice as big main transposition table as eval and pawn hash).

I could implement these sizes in the code directly, but it would be a lot smoother if the user could choose this, and this is currently not possible in Mediocre.

So it is time to be able to choose the hash table size in Mediocre. I have been meaning to do this for quite some time but it seems I always end up trying to implement some playing improvement feature instead.

The UCI protocol comes with a command where the hash size can be set, while Winboard lacks this option. Since Mediocre supports both protocols I am going to start with creating a settings file where the hash size can bet set, and later make it possible to change through the interface using UCI (during run time).

Since we have a settings file we might as well implement a few more settings to choose from. Like if the own opening book should be used or not.

Paths

I ran into a problem when trying to let the settings file decide in what directory the opening book should be located. Since Java is supposed to work on several platforms you have to be careful with using absolute paths. E.g. C:\books\book.zip will not work on a Unix machine.

So to be safe the paths should be e.g. ./books/book.zip

The real problem however was getResourceAsStream (which is used in the Book class) uses the path the file running is in, and not the path the application was started from. So if we use the Mediocre.bat to start Mediocre and have the the binaries in the bin-folder we need to use the current directory to find the Mediocre settings file, but ../book.zip to find the book file if it is located with the Mediocre.bat.

Messy? Yeah. :)

The problem is I can never know if the user is using an executable which will have book.zip in the same folder, or Mediocre.bat which will probably have the book.zip in the parent folder, so both folders will have to be tried which can get messy since getResourceAsStream uses another root directory.

The problem with book.zip is an old problem I have had. So far I have always had it in the bin-folder which is not logical.

I think I will sidestep all this and just assume all files Mediocre needs will be located in the same folder.

More settings

In future releases I might make it possible to change evaluation terms through the settings file as well as things like table bases and such.

(thanks to Tord Romstad for clearing up a few issues with hash tables for me)

[Other] Not 4.0

I noticed the latest release of Mediocre got zipped in a folder called "4.0", just ignore that. It is still v0.32. I have no idea why I named the folder that. :)

[Other] v0.32 test run

I ran a small tournament to try out the new version and it went pretty well for Mediocre. 3 minute games, with Arena main book.

01: GreKo 5.2.5     34,0/40
02: Mediocre 0.32   28,0/40
03: Pupsi 0.18      26,0/40
04: Lime_v62        25,0/40
05: GERBIL02        24,5/40
06: Kingsout 0.2.42 24,5/40
07: FluxII 0.7      18,5/40
08: Feuerstein045   17,0/40
09: Tscp181         11,5/40
10: Roce036         11,0/40
11: Vicki 0.021a     0,0/40

2007-04-30 Big one.pgn

The battle for second place behind Greko was quite exciting, but Mediocre pulled off a great last round with 9/10 points (losing only to Gerbil).

Vicki was only reaching depths of around 2-4 ply on my hardware (AMD Athlon 2500+) so it was of course having a hard time, but I will enjoy watching it improve and it is fun seeing the progress from the beginning. FluxII has made some nice progress and is not far behind Mediocre now, I will have to keep up the pace. :)

[Other] Keeping the archive more up to date

I updated the archive with the latest releases of Mediocre.

From now on I will always do this when a new version is released.

[Plan] A reluctant look at hash tables again

Implementing the transposition table and draw by repetition detection was probably the most complicated and tedious thing I have done so far with Mediocre. The bugs are extremely hard to find and can have devastating effects so I have basically left it untouched since version 0.2.

Since I want a pawn hash table, and perhaps also an eval hash table (which I have tried briefly already) it is time to take another look at the structure of the hash tables in Mediocre.

I think there is some optimization to be done in the general setup of the tables as well, especially in the draw by repetition detection scheme.

I just hope I do not mess something up. :)