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

 

 

   

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
Fast-forward
 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

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.

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

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.

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.

G 6 - International Gsei Web Tournament III ed.

iCE played this January as guest engine in the G6 - International Gsei Web Tournament III ed. It had a good start and only lost in the semi final against the later winner Chiron, a commercial Italian engine with 2:4. In the game for 3rd place iCE scored an incredible 6:0 victory against Senpai, the new engine by Fabien Letouzey.

 

iCE wins division 2 in Grahams Amateur Tournament

Five years ago early iCE started in the lowest divison 7 of this touranment. Now it is finally entering the top league. It was a long journey.

iCE 3 ELO gain

iCE ELO gain (absolute values relate to the private ELO list of Lars Hallerström)

The first testing results are now available. I rely envy those guys for their hardware. Looks like iCE 3 gained something in the area of about 140 ELO. This number matches the early results from the CEGT tests so is pretty reliable, at least for TC of up to 5 minutes per game.

Below is the attached cross table. Thank you, Lars, for running the test!

Tournament M5 Cross Table at Round 40

Pos	NAME	Rtg	Fed	Pts	Results	Pct
1	Ice 3.0 (64)	2980		607.5	+451 =313 -236	60,75%
2	Rybka 4.1 SSE42 (64-4cores)	3169		30.0	+24 =12 -4	75,00%
3	Critter 1.6a (64-4cores)	3199		29.0	+20 =18 -2	72,50%
4	Hannibal 1.5 (64-4cores)	3086		24.5	+15 =19 -6	61,25%
5	Texel 1.05 (64-4cores)	3066		24.0	+17 =14 -9	60,00%
6	Chiron 2 (64-4cores)	3109		23.0	+18 =10 -12	57,50%
7	Spike 1.4 (4cores)			21.5	+12 =19 -9	53,75%
8	Senpai 1.0 sse42 (64-4cores)	3052		20.5	+13 =15 -12	51,25%
9	Gaviota 1.0 (64-4cores)	2951		19.5	+9 =21 -10	48,75%
10	Ex 7.88b (64-4cores)	2866		18.5	+9 =19 -12	46,25%
11	Arasan 18.1 (64-4cores)	2914		17.5	+8 =19 -13	43,75%
12	SmarThink 1.80 (64)	2988		17.0	+10 =14 -16	42,50%
13	BobCat 7.1 (64-4cores)	2800		16.5	+9 =15 -16	41,25%
	Spark 1.0 (64-4cores)	2981		16.5	+10 =13 -17	41,25%
14	Cheng 4.37 rc0 (64-4cores)	2887		15.0	+10 =10 -20	37,50%
	Crafty 25.0 JA (64-4cores)	2892		15.0	+8 =14 -18	37,50%
15	Scorpio 2.7.6 JA (64-4cores)	2887		14.0	+8 =12 -20	35,00%
16	Sjeng WC2008 (64-4cores)	2912		13.5	+8 =11 -21	33,75%
17	Tornado 7 (64-4cores)	2944		10.5	+6 =9 -25	26,25%
18	Deuterium 14.01 (64)	2946		8.0	+5 =6 -29	20,00%
19	Pedone 1.3 (64-4cores)	2699		7.5	+5 =5 -30	18,75%
20	Rodent 1.7 (64)	2883		7.0	+3 =8 -29	17,50%
21	Octo 5190 (64-4cores)	2865		6.5	+3 =7 -30	16,25%
	Ktulu 9			6.5	+2 =9 -29	16,25%
22	Fruit 2.3.1	2937		6.0	+2 =8 -30	15,00%
23	Bug2 1.9 (64-4cores)	2829		5.0	+2 =6 -32	12,50%
Tournament start		05 Jan 2016 00:00
Latest update		10 Jan 2016 17:45
Site/ Country		Skrutten644
Level		300

iCE 3 gets released

I'm finally ready to release version 3 of my little chess engine project. It is still only single core as I haven't found the motivation to implement SMP. I'm still on the way to make the engine smarter not faster. So SMP is maybe something for the next release then.

What did change in v3

UCI Options Cleanup The UCI options of iCE are restructured and renamed. Details can be found here: iCE 3 UCI Options

Multi PV support iCE is now supporting Multi PV mode.

Bugfix The ponder protocol implementation is fixed. In Shredder GUI it did not work.

Evaluation: A bit of weight tuning was perfromed. However most changes failed or had only minor impact.

Search Changes: iCE 2 added History Heuristics, Late Move Pruning, Razoring and Counter Move Heuristics. For iCE 3 I optimized the conditions a bit further to make smarter pruning decisions.

Books: I finally touched my book code again. It was necessary as the books contained some errors coming from changes to the internal move format. I also improved the book building framework to use perfromance data of iCE in certain lines.

Time Management: I changed the algorithm for time allocation to not use all available time on the last move before TC.

What do you get

I make 3 versions of iCE available

• ice3-x64-modern - This is the release you probably want to use. It makes use of some HW instructions found on recent CPU.
• ice3-x64 - This is the fall back release if your HW doesn't support the instructions used in the modern compile
• ice3-x32 - As the name suggests, if you still on a 32 bit platform like Windows XP use this one

The versions along with new books can be found at my download site

http://www.fam-petzke.de/cp_download_en.shtml

How to use

iCE is only a chess engine so it integrates into a graphical interface and communicates with it via a protocol. All interfaces that support the UCI (Universal Chess Interface) are usable. Among the available interfaces are

• Shredder Classic GUI
• Fritz GUI
• Arena

The above interface are tested in at least some version, but others should work as well. Pick your favorite choice.

iCE 3 playing in the Shredder GUI

Short Algebraic Notation Madness

Chess games collections are usually stored in PGN and the moves are given in SAN (Short Algebraic Notation). This is meant to make it more readable for a human reader but for a human writer it is sometimes hard to follow the complicated rules especially if he writes the score sheet while playing a game.

For me as a programmer the existence of SAN is also really annoying. LAN (long algebraic notation) would make life much easier. The problem with SAN is the handling of move ambiguity. As usually the source square of a move is not given it must be calculated using the current layout of the board (which piece of the given type can travel to the target square).

So in order to translate SAN into a binary move object with (source and target square) a corresponding board class is needed which implements operations like get me all squares a bishop can travel to from source sq x. What makes it even more difficult is the rules for handling cases when more than one piece can travel to a certain square. Then file or rank of the source square are given, sometimes even both.

But not enough. If two pieces can reach the target square from a source square then the source file or rank indicator rule is not applied if one of the pieces is pinned and cannot move.

A lot of code is needed to handle all the special SAN cases and I estimate that a a fair number of club level written score sheets are not correct either.

So why am I complaining. My just published new books contain some errors as I was not handling the "two pieces can reach the target square but one of them is pinned to the king" case correctly. I fixed my book code and I'm in the process of rebuilding the books now.

So an update is coming soon.