Author: Sune Fischer
Date: 17:06:02 09/19/03
Go up one level in this thread
On September 19, 2003 at 19:46:38, Uri Blass wrote: >On September 19, 2003 at 17:42:47, Sune Fischer wrote: > >>On September 18, 2003 at 10:02:33, Edward Seid wrote: >> >>>I'm learning how to program by reading Deitel's Visual Basic.NET How to Program. >>> I'm eager to try out my new skills on a chess-related project. >>> >>>The Pawn Game - as presented by GM Lev Alburt in Comprehensive Chess Course, Vol >>>1 >>> >>>[D]8/pppppppp/8/8/8/8/PPPPPPPP/8 w - - 0 0 >>> >>>The game is won by: >>>1- capturing all of the opponent's pawns >>>2- reaching the last rank first >>>3- 'stalemating' the opponent, while still having at least one move for yourself >> >>I tried a simple unoptimzed search, just returning matescore for reaching 7th >>rank. It's not going as deep as I expected, of course you would not expect to >>get the same kind of hitrate as with pawn tables (no color or depth or bounds >>dependency in pawn tables): >> >>1 -3 5 1 1.a3 >>1 0 10 9 1.a4 >>2 0 10 33 1.a4 h5 >>3 0 12 121 1.a4 g5 2.g4 >>4 0 13 1056 1.a4 g5 2.g4 a5 >>5 0 15 2529 1.a4 g5 2.e4 g4 3.h4 >>6 0 22 14205 1.a4 f5 2.f4 a5 3.d4 h5 >>7 0 26 33039 1.a4 f5 2.h4 a5 3.c4 c5 4.f4 >>8 0 51 135649 1.a4 f5 2.f4 d5 3.d4 a5 4.h4 h5 >>9 0 107 360649 1.a4 f5 2.f4 c5 3.h3 a5 4.h4 h5 5.c4 >>10 0 339 1303780 1.a4 f5 2.d4 a5 3.c4 g5 4.e3 e6 5.c5 g4 >>11 0 689 2716466 1.a4 f5 2.c4 g5 3.d4 f4 4.e4 g4 5.b4 h6 6.h4 >>12 0 2241 8928849 1.a4 d5 2.d4 h5 3.h4 a5 4.f4 f5 5.b3 b6 6.c4 c5 >>13 0 6084 23078374 1.a4 a5 2.c4 h5 3.f4 f5 4.h4 c5 5.d3 e6 6.e3 d5 7.d4 >>14 0 16715 64599238 1.a4 f5 2.d4 a5 3.h4 c6 4.e3 b5 5.b3 h5 6.c4 bxa4 >>15 0 37273 146539781 1.a4 f5 2.e3 g5 3.f4 h6 4.b4 c6 5.d4 b5 6.axb5 cxb5 >> >>This is without nullmove or specially tuned eval or move ordering of any kind. >>Optimizing for it will of course give a few more plies, but double depth seems >>out of reach. >> >>-S. > >I do not think that you are right. >The branching factor is going to get smaller when you search deeper Why should that be the case? I would not expect such a thing to happen until you start hitting the solving of the game limit. You mostly get many transposition in blocked pawn type positions, in this position there are no blocked pawns at all, so it's going to take a while for the transpositions to really fire. There is also another effect, the TTable gets overfilled at some point and efficiency starts to drop, even with a good scheme you get more and more outdated entries. >and >evaluating passed pawns as winning if they are more advanced than the opponent >pawns may significantly help. Yes, if you do it right you might even be able to cut branches directly at that point (not sure, but there must be some obvious cases which would be theoreticly sound). The question is if this represents a significant amount of the nodes. Perhaps trying to solve an even simpler game: "win by creating a passed pawn" could answer this question. I think that game would be pretty hard too. >I also guess that you should generate pushing moves 2 steps forward first and >moves that lose a pawn only last. The move ordering is the standard move ordering I use for normal search, so it's not that far from optimal (I hope not!:). Again I don't care much about fiddling to get 3-5 more plies, to go from 15 to 80 plies I need something revolutionary. -S. >Uri
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.