Friday, March 24, 2017

Standard Algebraic Notation Headache

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
divide 5
move   divide #
Rxa8#          0
Rxg8#          0
Ke5      384.173
Kf5      316.308
Rga1     212.167
Rb1      263.331
Rc1      260.142
Rd1      230.933
Re1      235.617
Rf1      233.239
Rh1      254.486
R1g2     170.818
R1g3     183.832
Raa1     209.972
Ra2      244.058
Ra3      242.493
Rab4     199.705
Rac4     188.081
Rad4     159.635
Rae4      99.606
Raf4     144.555
Ra5      241.343
Ra6      204.052
Ra7      205.495
R4g2     244.212
R4g3     258.546
Rgb4     294.265
Rgc4     302.132
Rgd4     282.184
Rge4     204.924
Rgf4     300.731
Rh4      359.710
Rg5      224.460
Rg6      166.798
Rg7      168.936
Total Nodes of 35 moves : 7.690.939, Time : 0.062 sec

Friday, November 18, 2016

City Championship 2016 in Leipzig, Germany

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

Proud winners

Wednesday, August 24, 2016

None at all said Mr. Prosser

White moves and wins
Until now iCE contained endgame reconizers that help him to decide whether a position with 4 or 5 pieces is drawn or can be won. Those recognizer usually consisted of a set of rules. The rules where built in a way that  a position can be classified as either DRAW or UNKNOWN. UNKNOWN means it can still be a draw but one the recognizer does not know. If he classifies it as DRAW this is certain and search can be terminated in that node. This cuts the tree very nicely because a lot of branches are just cut off. iCE is often reaching max search depth in drawn positions quickly.

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
Updating cd74337..3d18b03
 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

Switching compiler for my iCE engine

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.

But currently summer is way more attractive and to hot for iCE.

Monday, June 13, 2016

Brain Chess

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.

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

Chess Engine Parameter Tuning

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

District Chess Championship U8

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.