Friday, March 24, 2017
In iCE I actually never bothered with the Standard Algebraic Notation described by FIDE. The UCI protocol uses Long Algebaric Notation (LAN) which is much simpler to implement in a chess program.
For SAN you have to implement a move generator, move making code, check and mate detection. And this all to just output a given move on the screen. For LAN output all you need is a table with the square names (0 = A1, 1 = B1, ... 63 = H8) and the piece letters for promotion (n,b,r,q).
The core engine functionality does not require SAN implementation however I have some helper functions e.g. running an EPD test suite or the simple output of the divide function (divide counts the resulting positions that are reached up to a given depth for all legal moves in a position) where it would be nice to have the output correctly.
So to not get out of programming practice I implemented SAN output in iCE. It is still not fully correct as it will include the source file or rank if two pieces can reach a target square even if one of the pieces is pinned. But this will not keep me wake at night.
Here is how it looks now. Probably no one except me will ever see such output but that is the point in chess programming. You mainly do it for yourself.
position fen b3k1r1/4p3/4K3/8/R5R1/8/8/6R1 w - - 0 1
move divide #
Total Nodes of 35 moves : 7.690.939, Time : 0.062 sec
Friday, November 18, 2016
Last weekend in Leipzig the yearly city championship for kids U8 - U18 took place. Although my younger son Julian is only 8 years they both played in the U12 division as he is already qualified for the upcoming district championship in the U10. This means he had to play one division up this time and he took this as an opportunity for training against stronger players.
Time control was 60 minutes for the game which is for kids already quiet a long time. The first matches were usually already over 5 minutes after the round started. Good thing is that no match is decided by time trouble.
My kids did very well. After 5 games little Julian was leading the U12 but lost then game 6 against his brother after a long exhausting fight and then also game 7.
Finally Jonas, my elder son, did win the division and Julian finished 3rd. So for both a very successful tournament. Julian is with the 3rd place now additionally qualified for the U12.
For me it means I need a week vacation in February when the district championships in U10 and U12 take place. But time for my kids is never wasted.
|Jonas vs. Julian Petzke, duel of the brothers in Round 6 at board 1|
Wednesday, August 24, 2016
|White moves and wins|
In order to not tell false positives (classify a position as DRAW which is not) the recognizer code was very complicated. It had to spot all the exceptions. Even KNNK is not necessarily always a DRAW.
A lot of effort went in to assembling all those rules but now I finally decided to test how much damage it does if I throw them away. And the answer is
None at all.
"By a strange coincidence “None at all” is exactly how much suspicion the ape-descendant Arthur Dent had that one of his closest friends was not descended from an ape, but was, in fact, from a small planet somewhere in the vicinity of Betelgeuse." D. Adams.
So I trowed them out and replaced them by a scaling factor for each endgame type that scales the score towards a draw, sometimes depending on some easy knowledge (e.g. wrong rook pawn). Maybe iCE will play a bit more stupid in endgames but it does not hurt its overall playing strength. So I take the chance to remove 16.000 lines of code (6000 lines real code and 10.000 lines for additional tables that contain positions with exceptions).
A big step towards simplification.
The git protocol
D:\Docs\cpp\ice\ice>git merge eg-simplify
endgame.cpp | 144 -
endgame.h | 23 -
eval.cpp | 66 +-
eval.h | 52 +-
evaleg.cpp | 6044 ++------------------------------
krkp.h | 10947 ----------------------------------------------------------
version.h | 6 +-
7 files changed, 399 insertions(+), 16883 deletions(-)
delete mode 100644 krkp.h
Friday, July 8, 2016
As I recently upgraded my development machine to Windows 10 I thought it is now time also to switch to a more recent compiler. So far I was using Visual Studio 2010 for compiling iCE which is now a bit outdated.
After a clean Windows 10 setup I installed the Visual Studio 2015 Community Edition and imported my sources. Overall it was pretty painless. I got one easy to fix syntax error that VS2010 did not report and several warnings about potentially dangerous type conversions.
The later are not really a problem as it was converting constant values and I knew it worked but to get rid of the warning I fixed it.
Now it compiles nicely and the resulting executable is at least as fast as before. So whenever I feel the urge to try something out in iCE I'm still able to do it.
Monday, June 13, 2016
This weekend I had the pleasure to escort my boys to the City Championship in Chess and they did exceptionally well in their age class U8 and U10. Julian managed to win the U8 and Jonas missed the tournament victory only by half a Buchholz point in the U10.
Congratulations. You are making progress much faster than me with my engine.
Congratulations. You are making progress much faster than me with my engine.
|Julian Petzke (U8) playing Board 1 in the final round|
|Size matters not. Look at me. Judge me by my size, do you? Hmm? Hmm. And well you should not. - Yoda|
|Jonas Petzke coming in at 2nd place in U10|
|Jonas and Julian Petzke enjoying their success|
Monday, February 15, 2016
Currently I have only limited time for my project and I also want to take a bit of a break from programming. So after my release of iCE 3 I decided to go back to an area where I'm not so involved. I thought it is time to do a little evaluation parameter tuning again. Here the computer does the stuff on its own.
My idea was now to not tune the whole set but to keep the current values for material. Those are dominant terms (if the pawn value is badly wrong the eval is bad even if it has a good weight for the rook on a half open file). So if I keep the material values the other minor terms get more pressure and maybe they converge to a better set.
As the only tuning method that worked for me so far is the population based incremental learning (a GA type of optimization) I used this one. I used a population size of 256 and let the tuner run for almost 1500 generations.
After every 100 generations I took the current state of the tuning and let it run a small match (3000 games) against the base version.
After 100 generations the set was already only 50 ELO worse than the base version. This is pretty fast considering the fact that except from material all weights started from random values and converged to a set that gets about 3000 ELO on the CCRL scale. Over time the tuner was able to improve the set a bit further.
In the final iteration the final set was at -6 ELO (16000 games). After I optimized the build for the new set (the base version was also optimized) the new set was at +3 ELO.
In the tuning run the tuner played 750.000 games at very fast time controls.
So it confirms the method works but it is not able to improve the weights any further significantly. However it is better than the Texel method for iCE. After minimizing the evaluation error using this method the engine lost 24 ELO.
I think I will try some other methods in the future and hopefully can squeeze out a bit more than 3 ELO.
Tuesday, February 9, 2016
|Julian Petzke (2nd from left) among the runner ups (2nd places) in the District Chess Championship 2016|
Julian, my younger son, just played a good tounament and with 6 out of 7 points he finished 2nd. Only 1 buchholtz point was the distance to the 1st place. Anyway. Well done!
Time control was 75 minutes for 40 moves and 15 minutes for the rest of the game. This is an eternity for such young kids. And probably halve the games were already finished after 30 minutes. Julian was among the ones that took their time which was probably a good part of his success.
Now he is qualified for the U8 Chess championship of Saxony.