Author: Robert Hyatt
Date: 12:04:34 02/27/06
Go up one level in this thread
On February 27, 2006 at 12:23:31, h.g.muller wrote: >On February 27, 2006 at 07:02:19, Alessandro Scotti wrote: > >>In Kiwi I used to have a "pawn race" evaluator that took into account passed >>pawns, the square rule and so on, but later had to remove it completely because >>of positions like this: >> >>[D] 8/p7/8/PP2k2p/8/8/8/K7 w - - 0 1 >> > >In my program from the mid-eighties, which had to go by without hash tables >because those day's memory sizes did not allow them, I evaluated such positions >dynamically (through search) in QS. The rule was that in a Pawns ending you were >not allowed to break off the search after a Pawn move. I considered this >situation logically equivalent to a recapture, and awarded the fact that the >opponent had a Pawn that could apparently move in the evaluation as if the Pawn >already was a Queen. (The "guilty-unless-proven-innocent principle".) >Furthermore, QS always considered Pawn moves of a Pawn that moved on ply n-2, >just as normally you continue to consider recaptures to the same square. Just >like recaptures eventually must run out, such Pawn moves do as well, because >either the pawn bumps into something that blocks it, is captured (QS always >considered capturing the piece that last moved), or promotes. > >Of course in the face of the queening threat that was expressed in the static >evaluation, the opponent would have to be given some moves to prove the >innocence. So I allowed only King moves that reduced the distance between King >and the square in front of the Pawn. (I could have allowed only the one move >that reduced this distance most, to completely avoid branching is such a QS >'tree' unless captures/recaptures became possible. But in practice the number of >paths a King could take to 'fetch' the Pawn, if that was possible at all, never >exploded much.) Without anything in the way this counted out automatically the >quadrant rule. > >In situations like the diagram above the line 1. b6, a7xb6 (recap) 2. a6xb6 >(recap), Kxx (hunt) 3. b7 (race), Kxx (hunt) 4. b8Q as well as 1. b6, Kxx (hunt) >2. b6xa7 (race, cont. capt.), Kxx (hunt) 3. a8Q would be fully covered in QS. >Except perhaps the first move (depending on what went on previously), so that a >one-ply search would see the promotion. > >This gave a much more stable search, because lines of play for which the current >eval was unclear, and that could end up either a Queen up or a Pawn down >(depending on subtleties as in the diagram), were first resolved in a deep but >narrow search before alternatives were considered. For such promotion races >iterative deepening proved pointless, that would be similar to controlling tree >size by first adding slider moves that do one step along each ray, and in the >second iteration add the two-step moves, etcetera. As long as you don't know if >there is an undefended Queen or a defended Pawn at the end of the ray, you have >no idea where the score is going, and it is useless to compare it to other moves >that are resolved. We are close to posting some very old source for my programs. I had a printout of blitz 6.9, which played in 1978 at the washington DC ACM event. And a printout of a version of Cray Blitz that played in 1989 I believe although I will have to try to figure out version numbers and correlate with dates to get this part right. Tracy R. has scanned these things in, and run 'em through an OCR program to produce ascii (FORTRAN) files. I'm now trying to get the easier blitz 6.9 source to compile and run. OCR does strange things with oh and zero, and one and ell, so it is taking some time. But hopefully we will eventually be able to post the source for a working 1978 chess program. Interestingly, this version of blitz had the pawn-race code, as I originally wrote that around 1972 or so and have used it ever since. It was rewritten in Crafty since bitmaps make it much easier to do, but I found in the early 70's that this was critical when playing in human tournaments as we used to do. More when this is ready for public release. Just remember it is 1978 code, no null-move, just check extensions (and a few other special cases). I'm not sure if this has the old parallel search code in it, as we did use parallel search in 1978 on the dual-cpu univac box we played on in DC that year. Be interesting to read over this stuff (still commented similar to crafty so it is not hard to read even though I have not touched FORTRAN in 10 years now) to remember the "good old days". :) Bob
This page took 0.01 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.