Author: Vincent Diepeveen
Date: 07:35:12 09/18/03
Go up one level in this thread
On September 18, 2003 at 10:27:33, Vincent Diepeveen wrote:
small search note:
this is a peanut to solve with hashtables. Without Knuth's lemma
applies which more or less says:
sqrt(10) ^ 32 = 10^16 = 10 000 000 000 000 000 nodes to search.
Good luck with that.
With good transpositiontable this is a peanut.
>On September 18, 2003 at 10:02:33, Edward Seid wrote:
>
>A very illusional game thanks to the rules. Trivially with the normal chess
>rules this is a much easier game to keep a draw than without :)
>
>If white goes e4, then black answers e5.
>If white goes a3 then black goes a6 in principle.
>
>In short the only option white has is to start with a pawn to the 3d rank one
>day.
>
>Instead very clever pruning methods involving a passer that's unstoppable and
>further than any pawn of the opponent, will reduce search space significantly.
>
>A good winning attempt for white is illustrated by a well known trick where 3
>pawns at a4,b4,c4 win always from pawns at a6 b6 c6 as you can create a passer.
>
>So that is the only trick white can go for.
>
>Starting with for example 1.a4,a5 2.c3,c6 3.b4
>
>now white can capture on a5 winning a move and after winning that move it can
>win another tempo by playing a6 bxa6 a5!, but black cannot play b5 creating
>symmetry.
>
>So i would go 3..b6 there
>
>Now c4 is never possible as you after axb4 can already evaluate that as a loss
>for white.
>
>b5 is never possible for white and bxa6 doesn't solve a thing forever.
>
>4.d4 is answerred by d5.
>
>So playing for semi-symmetry for black is already very effective.
>
>So the first guess that this would be a simple draw for black is not exactly
>true, but at second glance a few simple rules will produce great killermoves for
>black.
>
>A good evaluation function and move ordering can do miracles in this game to
>find out it is a draw.
>
>>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
>>
>>The game is drawn if:
>>1- both sides' pawns are blocked so that neither side can make any moves
>>
>>The programming exercise I've assigned to myself it to try to solve this game
>>using brute-force minimax. My question to you... can this game be solved on
>>today's typical desktop computer using brute-force?
>>
>>I've been thinking about this and have made the following observations:
>>1- while classical chess has a branching factor of around 30, the Pawn Game
>>branching factor is 16 in the initial position, and around 8 in the
>>'middlegame', and goes down with each capture.
>>2- the longest 'game' is certainly less than 81 ply, and is probably around
>>60-65 (81 ply is calculated by the impossible scenario of each side taking 40
>>ply each to march all pawns to the 7th rank + 1 ply to promote)
>>
>>I'm not planning to use anything fancy like hashtables or board rotation. I'd
>>be happy if I'm successful in coding a 10x12 board representation (practice for
>>writing a classical chess engine in the future), a valid pawn move generator,
>>and a correct implementation of the minimax algorithm.
>>
>>I'm very curious what the solution to this game is. Is it a win/loss/draw for
>>White? Of the 16 possible White moves, which ones win/lose/draw? How long is
>>the longest game? How long is the shortest game? What is the distribution of
>>wins amongst the 3 methods of winning?
>>
>>Any thoughts or suggestions are appreciated.
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.