As you know Mediocre supports both the UCI and xboard protocols (although it's always supported UCI a bit better). But fact is it hardly really supports xboard, there is atleast one bug that I know of (when playing multiple games) that causes Mediocre to play illegal moves.
I've not wanted to touch it since frankly I find xboard annoying and confusing.
But while implementing pondering I had to start digging in the mess again.
For UCI it took about an hour to get it to work, possibly with a bug or two (I haven't tried it extensively yet).
When trying to do the same for xboard I had to change a ton of things, mainly due to xboard thinking for some reason that it's a good idea to not give any information whatsoever to the engine.
The clearest example of this is UCI sending "go ponder" when it's time for the engine to ponder, and the neat little "ponderhit" UCI sends if the next move from the opponent is the same move as the engine said it was pondering on. If it wasn't a ponderhit UCI simply sends a new search-string.
Even if the pondering is not implemented like this (picking a move and thinking on it), the information can still be easily used to control the thinking (starting and stopping pondering).
Xboard does nothing, except telling the engine "hard" at the beginning of the game (logical choice of command I know).
When the opponent moves, the commands are sent as usual, even though the engine is pondering.
This completely messed up my way of handling interrupt of the search. Since I now have to store the commands sent during search (or else the engine will "forget" what move was played since the same command is used to tell the engine to stop ponder).
Ok I'll stop ranting for now. :) Atleast ponder will be done soon, if xboard allows me to.
Follow the process of creating a chess engine
Jan 30, 2009
Jan 23, 2009
[Plan] CCT 11 preparations
CCT 11 starts in two months (http://cctchess.com/) and I'm going to try to get Mediocre at its best behaviour by then. This is what I'm going to look at until then.
- Pondering - This has been on my todo-list for almost two years now and it's time it gets done. Not having pondering is essentially like playing with half the time (almost atleast) against engines that has it.
- Endgame knowledge - I have some endgame knowledge ready for upcoming versions, they include things like understanding draws with a rook pawn against queen and similiar issues. At first I wanted tablebases for this, but I don't want Mediocre to be dependant on them. I might look at tablebases at a later point however.
- Evaluation issue - Resolving the weird bug with piece square tables is a priority. I thought i had a pretty smart evaluation routine, but when a thing like that comes along I just don't know anymore. Awarding centralized pieces in the mobility function might be one way to go.
Jan 22, 2009
[New Version] v0.34 - Bugfixes and optimizations
Changes:
Also a big thanks to George Koch who helped with a bunch of the optimizations and feedback.
Download here
- Fixed a bug in the reptition detection table (repetitions were not replaced so the table would eventually fill up)
- Fixed a bug in SEE (where black king's attack squares were added to white's side)
- Fixed a problem with loading the opening book (perfomance.bin was hard coded and hence the only opening book name that was accepted)
- Fixed a bug where endgame piece square tables always were used after opening phase
- Fixed a bug in the xboard protocol where time was reported in milliseconds (not centiseconds)
- Fixed a bug in the UCI protocol when the same position was analyzed numerous times (reptable was not updated)
- Fixed a bug with probing pawn eval when no pawns were on the board
- Fixed a bug with the draw probability in evaluation (it simply wasn't used)
- Fixed contempt factor, should work now
- Move generation slightly optimized
- Some small optimizations here and there
- Aspiration window researches now only resets the exceeded limit
Also a big thanks to George Koch who helped with a bunch of the optimizations and feedback.
Download here
Jan 21, 2009
[Other] Test tourney for Mediocre v0.34 (in development)
After hitting a dead end with the new Board-class and getting nothing but confused with changes to the evaluation I decided to go back to the old Board-class and implement all the obvious bug fixes I found (excluding the one mentioned in my previous post of course).
This turned out to be a good move it seems as this test tournament shows.
But the important part is that they did that in previous test tournaments as well so the results should be valid when comparing the strength of Mediocre versions.
Mediocre v0.334 scored 200.5/400 which is 50%, and this result (243/400) is 60% which gives a 70 rating point difference (I believe).
Not sure how accurate this is, especially since some engines gives the victories away, but it should prove that the new version is clearly better, I hope.
This turned out to be a good move it seems as this test tournament shows.
As mentioned earlier some of these engines are acting up quite a bit, for example does BBChess seem to only use about 10 seconds of the minute for any length of game and FluxII loses due to illegal moves now and then.
Engine Score Me
01: Mediocre 243,0/400 ····················
02: Hamsters 19,5/20 111111111111=1111111
03: Hermann 16,5/20 1=1=11=1011111111011
04: Diablo 15,5/20 1=111111111=11=11000
05: LittleThought 14,5/20 0111111111011010=110
06: NanoSzachy 13,0/20 1=00=111011001101111
07: Counter 12,5/20 11==0001=01=11==111=
07: Gaia 12,5/20 1=11=10110001=001111
09: AliUCI 10,5/20 111010000=0101110110
10: Feuerstein 8,0/20 =00000011101=0100011
10: GreKo 8,0/20 =111000=010000101100
12: Amundsen 7,0/20 10010000110101100000
13: Bison 5,5/20 000001001010=0100010
14: Gibbon 4,5/20 0100010000001100000=
15: Clarabit 3,5/20 100=00000000000=00=1
16: Lime 2,5/20 =0000000001000010000
17: BBChess 1,5/20 000000000010000=0000
18: Bikjump 1,0/20 00000000001000000000
19: FluxII 0,5/20 000000000000000000=0
19: Vicki 0,5/20 =0000000000000000000
21: Roce 0,0/20 00000000000000000000
But the important part is that they did that in previous test tournaments as well so the results should be valid when comparing the strength of Mediocre versions.
Mediocre v0.334 scored 200.5/400 which is 50%, and this result (243/400) is 60% which gives a 70 rating point difference (I believe).
Not sure how accurate this is, especially since some engines gives the victories away, but it should prove that the new version is clearly better, I hope.
[Other] Evaluation "problem"
One of the (many) bugs I've discovered while working with Mediocre the last month was that it uses the wrong piece square tables for the most part of the games.
Mediocre has two kinds of tables, for opening/middle game and for endings.
The bug was that Mediocre changed to ending tables after the opening phase. That is awarding moving the king and queen into the center etc. in the middle game...
The weird part is that this greatly improves the performance of Mediocre. "Fixing" the bug in v0.334 and running a match against a non-fixed version results in a clear victory for the latter.
I assume this has to do with the mobility/piece square features not being scaled as they should.
I will have to take a long look at the evaluation again since this is clearly a bad thing. :)
Mediocre has two kinds of tables, for opening/middle game and for endings.
The bug was that Mediocre changed to ending tables after the opening phase. That is awarding moving the king and queen into the center etc. in the middle game...
The weird part is that this greatly improves the performance of Mediocre. "Fixing" the bug in v0.334 and running a match against a non-fixed version results in a clear victory for the latter.
I assume this has to do with the mobility/piece square features not being scaled as they should.
I will have to take a long look at the evaluation again since this is clearly a bad thing. :)
Jan 16, 2009
[Other] Two games from ICC
Having left Mediocre on ICC for the evening I got back and noticed two quite exciting games. Not so much the games but who had played. :) (Jaan Ehlvest played a match against Rybka in 2007 which makes him a particulary fun opponent to meet)
Jan 15, 2009
[Other] Some progress
I finally have a version of Mediocre that seems better than v0.334, a few more things to fix and it's ready for release.
The rewritten Board-class is both a blessing and a pain, I have found quite a few bugs due to it, simply because it doesn't accept faulty positions and moves at all. It immediately crashes the program. :)
This is a good thing of course since tricky bugs are much easier to find.
However to my disappointment it seems it actually turns out to be slightly slower than the old Board-class. Not when running the perft-tests, but rather when the engine is actually up and running (searching moves). I'm guessing it is due to the increased number of method calls, especially in the evaluation (things like board.getWBishops()[0].getPosIndex()).
At one point I was thinking about throwing it away, but it is just so much better coded now that I just can't. I will have to try to find some optimizations later on instead.
-
I'm currently working on adding some endgame knowledge. I was thinking about adding support for tablebases, however I will put that off for some time. Instead I'm adding basic endgame positions (like KPvK etc.) manually. More fun and less work that way. :)
As a measure I'm using the eet.epd endgame test suite. Mediocre v0.334 scored 15/100 at 5 seconds per position. I want the next version to get around 30/100.
The rewritten Board-class is both a blessing and a pain, I have found quite a few bugs due to it, simply because it doesn't accept faulty positions and moves at all. It immediately crashes the program. :)
This is a good thing of course since tricky bugs are much easier to find.
However to my disappointment it seems it actually turns out to be slightly slower than the old Board-class. Not when running the perft-tests, but rather when the engine is actually up and running (searching moves). I'm guessing it is due to the increased number of method calls, especially in the evaluation (things like board.getWBishops()[0].getPosIndex()).
At one point I was thinking about throwing it away, but it is just so much better coded now that I just can't. I will have to try to find some optimizations later on instead.
-
I'm currently working on adding some endgame knowledge. I was thinking about adding support for tablebases, however I will put that off for some time. Instead I'm adding basic endgame positions (like KPvK etc.) manually. More fun and less work that way. :)
As a measure I'm using the eet.epd endgame test suite. Mediocre v0.334 scored 15/100 at 5 seconds per position. I want the next version to get around 30/100.
Jan 11, 2009
[Other] Bugs bugs bugs
The new Board-class of course had a bunch of more or less obvious bugs.
The last was a bug showed itself deep in the search trees (14 ply searches or more usually) and caused Mediocre to crash.
After 6 hours of bug-hunting I narrowed it down to pawn endings where one side had a pawn that still could move two steps.
Once found it was very obvious (and quite severe)... the zobrist key was updated according to where the en-passant-capturing pawn moved, and not to where the captured pawn actually was.
This caused faulty moves to be used in the search (from the hash move). Of course this didn't show up in the perft-checks since the zobrist was updated "correctly", just that the key was actually wrong.
Also it didn't show up until late in the trees (and usually in pawn endings) since the transposition table had to be quite full in order to moves actually existing in the faulty key-places.
-
Anyway, after some testing this new Board-class seems to offer a slight improvement in strenght. On to more interesting things.
The last was a bug showed itself deep in the search trees (14 ply searches or more usually) and caused Mediocre to crash.
After 6 hours of bug-hunting I narrowed it down to pawn endings where one side had a pawn that still could move two steps.
Once found it was very obvious (and quite severe)... the zobrist key was updated according to where the en-passant-capturing pawn moved, and not to where the captured pawn actually was.
This caused faulty moves to be used in the search (from the hash move). Of course this didn't show up in the perft-checks since the zobrist was updated "correctly", just that the key was actually wrong.
Also it didn't show up until late in the trees (and usually in pawn endings) since the transposition table had to be quite full in order to moves actually existing in the faulty key-places.
-
Anyway, after some testing this new Board-class seems to offer a slight improvement in strenght. On to more interesting things.
Subscribe to:
Posts (Atom)