Author: Roberto Waldteufel
Date: 20:27:38 06/20/98
Go up one level in this thread
On June 20, 1998 at 09:35:00, Robert Hyatt wrote: >On June 19, 1998 at 23:11:36, Roberto Waldteufel wrote: > >> >>Thanks for your comments. I am the first to accept that terminal node evaluation >>is more accurate that preprocessing, but it is also much slower. If I moved all >>my preprocessing to the leaves, I think I would indeed lose at least one ply in >>depth, maybe even more. Although my method might sometimes not recognise that a >>passed pawn at a leaf was in fact passed, it will never mistakenly think a pawn >>is passed when in fact it is not. What I do is to look at the pawn structure at >>the root, and, for White and Black separately, I calculate all the squares on >>which a friendly pawn would be passed (regardless of whether a pawn actually >>occupies the square or ever could occupy it). As the search expands deeper, >>these sets of squares can grow larger, but can never get smaller, so it is safe >>to credit pawns that are on the precalculated squares by the time a leaf node is >>reached. >>The danger, of couse is that I might fail to see a passed pawn on a square that >>is not in my initial list of squares, but I have found this to be rare enough >>not to cause a great problem. As always, the trade-off between speed and >>accuracy must be carefully weighed up, but I think there is still a good case >>for doing some of the evaluation at the root to increase speed and thereby >>search deeper. If I later decide, as you suggest, that I want to be more precise >>about the passed pawns I currently don't see, I would still use my preprocessor, >>so that then at the leaf I would only have to test a few of the pawns for being >>passed (ie those not on the precalculated squares) instead of all of them. >> >>Best wishes >> >>Roberto > > >two things. > >1. This shoule *not* be a compute-intensive task. If you aren't yet hashing >your pawn structure scoring, you should, because whether a pawn is passed or not >is a static piece of information that is independent of other pieces. If you >hash this, you will find that you find over 99% of your pawn structure >evaluations are not needed because after you compute them one time, you will not >re-compute this again, just use the hashed value. > >2. finding that a pawn is passed is trivial. You could easily add a 64 bit >word that contains a 1 for each white pawn, and then do the same for black. If >you update this after each move, asking "is a pawn on "SQ" passed" takes one >64 bit operation, anding the opponent's pawns with a mask that shows where he >must have pawns in order for your pawn on SQ to *not* be passed. Hi Bob, Thanks for your reply. I have to admit that I do not at present hash my pawn structure because my evaluation is so crude that it does very little calculation in this respect, but it is something I hope to add as the evaluation gets smarter. I do give bonuses for passed pawns - the more advanced, the bigger the bonus - but the set of squares upon which pawns of a given side - say White - would be passed can only get bigger, never smaller, as more moves by either side are made. Thus any square on which a hypothetical White pawn would be passed in the root position will retain this property throughout the search. At present I fudge this by ignoring pawns that have become passed without being on one of these squares (due to capture of enemy pawn, for example), but I could test for this at the terminal nodes, or better still hash it as you say. The passed pawns that have become passed by moving to one of the squares identified at the root require no attention at all in the terminal evaluation because the bonuses were all worked out by the preprocessor and incrementally updated as the moves were made/unmade during the search. Do you not think that this idea has some (albeit small) merit even with a hashed pawn structure score? In those 1% of cases when the pawn structure is not found in the table, the amount of processing could be reduced a little by only testing pawns that are not on squares that would make them passed at the root. The point I was really trying to make was not so much about passed pawns per se, but rather that when you can identify a permanent feature of the position that cannot possibly alter during search (eg a White pawn on c5 would be a passed pawn), then it is safe to use preprocessing to save time in the terminal evaluation. This is sometimes the case with other factors besides pawns. For example, those same squares on which pawns would be passed at the root are also squares on which a friendly piece could never be driven away by an enemy pawn, which increases the value of posting a piece on the square, especially if it is a central square or a square close to the enemy king. Here again, I take account of such piece placings by adjusting the piece-square value tables in the preprocessing stage. Of course not everything can be preprocessed, but it seems to me that there are savings to be had by the judicious use of preprocessing on permanent or semi-permanent features. Best Wishes, Roberto
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.