Author: Vincent Diepeveen
Date: 05:36:06 06/29/99
Go up one level in this thread
On June 29, 1999 at 02:08:27, Peter McKenzie wrote: >On June 28, 1999 at 18:19:59, Vincent Diepeveen wrote: > ><snip> >Thanks for an interesting post Vincent > >> CONCLUSIONS >> >>Parallellism is the future. > >Yes, this does seem to be a valid conclusion. Only one (Shredder) of the top 5 >programs (Shredder, Ferret, Fritz, CilkChess, Junior) was running on a single >CPU. > >>Not a single program will in the future be able to play without EGTB >>in search. > >This is perhaps overstating the issue slightly, but I agree that programs >playing withoug EGTB certainly have a disadvantage. This disadvantage will only >grow as more and more EGTBs are conquered and compressed. > >I don't think LambChop suffered from not having EGTB, but if I compete next time >I think I'll make sure I have them! > >>Winning the endgame for most programs is gonna get very tough. >>Near to no program plays very well in the middlegame. It's about the plan. > >Something of an exaggeration of course... > >>When a program has the right plan and a way better position, then >>you can about resign. >>Bad tested programs are dinosaurs. They get massacred, > >Yes! I think that quality testing is one of the most important parts of >developing a chess program. This testing must involve a large number of >carefully analysed games (either by autoplayer, winboard/xboard, fritz >interface, millenium interface or on the chess servers). > >I personally prefer the test servers because the humans give you more intereting >games and are good at finding a program's weaknesses. > >>as a single big problem in a program will, because of the huge search depths, >>immediately backtrack to the root and get at your board. > >Yes, deep searchers can dig their own graves sometimes :-) > >>Programs without a lot of knowledge don't know how to progress, or simply allow >>or force opponents to place their pieces better. >> >>Quality is more important than quantity. I guess Lambchop clearly proved that. > >I'm not sure I proved that, but I feel my approach has been vindicated somewhat. >LambChop was being outsearched by every opponent except Eugene. Sometimes it >was being outsearched by 2, 3 or even more ply in the middlegame! This hurt in >some games, but in others it didn't seem to matter. Before paderborn started i talked to a lot of 'computerchessexperts', from which a large number plays anonymeously or less anonymeously sometimes at icc server with several commercial programs (the king, shredder, fritz, junior and many others). They all said one thing the same: "lambchop is gonna finish last, see how bad it plays at icc". I totally disagreed here with them. At icc most dudes are busy scoring points and just look to their rating. If i then look to how lambchop did in paderborn, then i think you earned a big deal of respect! A 6/7 versus 9/10 ply match at the internet chess makes a program rather chanceless at the internet chess server. Not seldom i see simple 100% scores for the program outsearching at blitz its opponent with 3 ply. However as it's already obvious last few years and in paderborn this was again repeated: a 9/10 ply versus 12/13 ply game is something completely different. >It will be interesting to see the tournament report by Don Beal, as he was >collecting detailed information about every program. Well i'm not so sure of that. We've already heart all the commercial talks before i bet. The classical description which i recently also quote for DIEP: "Using alfabeta with nullmove and a quiescencesearch and some forward pruning" >> >> FUTURE WORK >> > >For the future I plan to continue in pretty much the same way with an emphasis >on gradually improving the evaluation function, and making the search more >effective. I'd also like to try out some pruning ideas, but these are pretty >vague right now. Right. I'm right now busy making search more effective, because without pruning my program hardly gets 9 ply at 3 minutes a move at a PII450 here. With some pruning i directly get 2 plies more, which tactical kicks butt! Some tactical problems like many of the ECM, bs2830 and such are simply unfindable by a program that doesn't search deeply and is very slow. Let's take for example this position: r1b1k2r/p2n1ppp/1p2p3/3p2B1/P2P4/1Nn1P3/5PPP/R3KB1R w KQkq - Analysis Eric de Haan and Vincent Diepeveen, f3!! black timeleft=27:46.40.00 r = b = k = - r ... 1 ... o - = n = o o o ... 2 ... - o - = o = - = ... 3 ... = - = o = - B - ... 4 ... O = - O - = - = ... 5 ... = N n - O - = - ... 6 ... - = - = - O O O ... 7 ... R - = - K B = R ... 8 ... white timeleft=27:46.40.00 white to move clean Clearing all Hashtables... anal Analysis mode is on process 0: engineflags = 0 00:00 3 (0) 1 -0.64 a4-a5 00:00 4 (0) 1 -0.53 Nb3-d2 00:00 8 (0) 1 -0.42 g2-g3 00:00 9 (0) 1 -0.38 g2-g4 00:00 22 (0) 1 -0.26 Bf1-b5 00:00 70 (0) 2 -0.69 Bf1-b5 Bc8-b7 00:00 240 (0) 3 -0.34 Bf1-b5 Bc8-b7 Ke1-d2 00:00 1631 (0) 4 -0.97 Bf1-b5 Nc3xb5 a4xb5 a7-a5 ++ g2-g3 00:00 2567 (0) 4 -0.95 g2-g3 Bc8-b7 Bf1-b5 Ra8-c8 ++ h2-h4 00:00 3541 (0) 4 -0.94 h2-h4 Bc8-b7 a4-a5 O-O ++ f1-d3 00:00 3941 (0) 4 -0.94 Bf1-d3 Bc8-b7 Ke1-d2 Ra8-c8 ++ a1-c1 00:00 4844 (0) 4 -0.76 Ra1-c1 Nc3xa4 Bf1-b5 h7-h6 00:00 7646 (0) 5 -0.40 Ra1-c1 Nc3-e4 h2-h4 Bc8-b7 Bf1-b5 00:00 16437 (0) 6 -0.65 Ra1-c1 Nc3-e4 h2-h4 h7-h6 Bg5-f4 Bc8-b7 00:01 35128 (0) 7 -0.46 Ra1-c1 Nc3-e4 h2-h4 f7-f6 Bg5-f4 e6-e5 Bf4-h2 00:02 63632 (0) 8 -0.53 Ra1-c1 Nc3-e4 h2-h4 Nd7-f6 Bf1-b5 Bc8-d7 Rc1-c7 Bd7xb5 a 4xb5 00:08 196760 (0) 9 -0.46 Ra1-c1 Nc3-e4 h2-h4 Nd7-f8 Bf1-d3 Bc8-d7 Bd3xe4 d5xe4 a 4-a5 00:27 634088 (0) 10 -0.42 Ra1-c1 Nc3-e4 Bg5-f4 g7-g5 Bf4-c7 Bc8-b7 f2-f3 Ne4-f6 Bc7-d6 Ra8-c8 Rc1xc8 00:44 1068682 (0) 11 -0.38 Ra1-c1 Nc3-e4 Bg5-f4 g7-g5 Bf4-c7 Ke8-e7 f2-f3 Ne4-d6 Bf1-d3 Bc8-b7 Ke1-e2 01:45 2498836 (0) 12 -0.45 Ra1-c1 Nc3xa4 Bf1-b5 Na4-b2 Rc1-c2 Nb2-c4 Bb5-c6 Ra8- b8 Bg5-f4 e6-e5 Bf4xe5 Nc4xe5 03:57 5459481 (0) 13 -0.45 Ra1-c1 Nc3xa4 Bf1-b5 Na4-b2 Rc1-c2 Nb2-c4 Bb5-c6 Ra8- Now finding f3 is not so tough, but finding the right score here is tough. After f3 the knight at c3 obviously gets hung, but programs need a certain amount of moves to find this: f3 lb7 kd2 rc8 bd3 h6 bh4 g5 bg3 nullmove rhc1 and then the knight at c3 is hung. so that's 10 ply + (1+R) = 11+R where r is the reduction factor used for nullmove. Now i remember very well analyzing this position with my teammember Eric de Haan. He lost a game after his opponent played a dubious looking move. So in a cafe that evening we started analyzing: r n b q k = - r d2-d4 1 d7-d5 o o = - = o o o c2-c4 2 c7-c6 - = o = o n - = Nb1-c3 3 Ng8-f6 = - = o = - B - Ng1-f3 4 e7-e6 - b O O - = - = Bc1-g5 5 Bf8-b4 = - N - = N = - ... 6 ... O O - = O O O O ... 7 ... R - = Q K B = R ... 8 ... r = b = k = - r e2-e3 6 Nb8-d7 o - = n = o o o Qd1-c2 7 Qd8-a5 - o - = o = - = Nf3-d2 8 b7-b6 = - = o = - B - c4xd5 9 c6xd5 O = - O - = - = a2-a4 10 Nf6-e4 = N n - O - = - Nd2-b3 11 Bb4xc3 - = - = - O O O b2xc3 12 Qa5xc3 R - = - K B = R Qc2xc3 13 Ne4xc3 The move played by his opponent was 8..b6?! In the game Eric couldn't refute that however. Now i proposed the move 9.cxd5,cxd5 and 10.a4! This a4 move was something he hadn't thought of. The idea was to catch the queen at a5, as b6 closed its retreat. Then Eric proposed Ne4 after which white would lose a pawn after trying to catch the queen with Nb3. the whole exchange was played within seconds and then it was obvious that the knight was hung at c3. Ok, so now we had spent 5 minutes all together in this cafe analyzing and i had seen a line which is move 9..13 after that i said: "knight is hung at c3 after f3". Then we spent half an hour analyzing how bad other moves than 9..cxd5 were. Now i must see the first program that after 9. ... cxd5 directly sees that this line completely loses for black. Things like this make me think however about the need in the future to search in a very selective way. If i then after 13..Nxc3 see my program struggle to just get to 13 ply then i'm already getting a big nightmare. >>Since last Tuesday 22th i'm slowly working on DIEP now. >>I'm right now working at the search. Experimenting a lot >>with forward pruning versus brute force search. >>I simply kicked out all forward pruning. Only nullmove and alfabeta is what i >>use. Experimenting with last ply pruning now though a little. >>It scores shit at testsets. Positionally its however just as fast as >>the very selective version i used in paderborn. >> >>After some toying the next few weeks with this i will work after that >>at my endgame evaluation and fix the knight versus bishop parameters. >> >>For the next months and further my graphical windows >>version must be made ready for commercial usage. Plan to release again >>after this summer. >> >>After that i plan to learn diep how to play the kings indian defence with >>black. I already started that project a year ago, but some defences seem >>quite hard for programs to understand... >> >>Greetings, >>Vincent
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.