Here are some things I will be looking at:
- End game - I recently played a 300 game 1+1 minute match against an old version of Rybka and the result was 300-0 to Rybka. :) However I noticed that Mediocre surprisingly often came out of the middle game with an even or slightly worse score, and rarely (very rarely :) even slightly better. Only to be annihilated in the end game.
To be honest I have worked extremely little with the end game in Mediocre and I think it is time I look into that. Some simple end game knowledge should make a big difference. And it is probably worth looking into some more separation of the evaluation to make better calls in the end game.
Perhaps the next match could end 299.5/0.5 instead... :) - Transposition tables - When I wrote the transposition tables class in January I basically only tried to make it work. I am sure there are tons of things to improve in there and I would not be surprised if there is a bug or two as well.
Since the class itself is quite small a complete rewrite is probably in order, and also cleaning up the repetition detection while I am messing around in there should be worth it. - Check history - As it is now the search checks for checks in three or so places. While this might not be that much of a slowdown since the check detection is quite fast it could obviously be better. I have made a few attempts at making the board remember if the position is check or not, and even had it in a version I was about to release but removed it at the last minute since it was so messy.
This takes some major restructuring to work as I want, but hopefully it should help a bit atleast. - Definitions - This is a rather 'cosmetic' change to the code but the way I am using the definitions interface is just wrong in every way. :) A Java interface should not contain any real code, it is just not supposed to work like that. Java does not have .h-files like C and there is a reason for it, so using the Definitions file like I have done just has to go.
3 comments:
Endgame knowledge should help a lot (even simple cases like recognising KNK and KBK draws), but you already said you were going to access TBs with Java, so this seems to be quite a task. Do you know of any documentation of the Nalimov format?
Another point that puzzles me is why you implement so many features twice - once for white and once for black. However, this is quite common in top engines, too. Do you do this for the speed gain?
As I said earlier TBs are quite a bit in the future and I haven't even started looking at it. For now I'm going to look at things like outside pawns and similar, so they can be recognized before it is too late.
About doing things twice I haven't really thought of it, it's just the way that felt most natural for me. It should probably help a little bit with the speed but that is not the reason I'm doing it.
Separating the code just makes it more clear to me, instead of having some nifty way of doing it for both sides at once.
Hi jonatan
I hope all is well! Good luck with the new additions to Mediocre. I am also hard at work trying to get my engine ready for the 15th tournament on WBEC Ridderkerk. I hope Vicki does not completely embarrass me! Hope it goes well with your preparations... and enjoy!!
Post a Comment