Author: Robert Hyatt
Date: 08:59:03 01/13/04
Go up one level in this thread
On January 13, 2004 at 10:28:48, Tord Romstad wrote: >On January 13, 2004 at 09:33:20, Robert Hyatt wrote: > >>On January 13, 2004 at 05:23:24, Tord Romstad wrote: >> >>>On January 12, 2004 at 20:21:45, Robert Hyatt wrote: >>> >>>>You can hash _everything_ about pawns, just so your scores have _only_ >>>>information about pawns in them. >>> >>>But scores of any kind are *never* computed only on the basis of the >>>locations of pawns. >> >>Sure they are. When I say "score" I mean something that is used to >>compute a score. Some things can be scored directly without regard to >>pieces. Weak pawns. Isolated pawns. Etc. If you want those scores to >>depend on pieces, that is fine. Just score the pawn part, hash that score >>part, and also save the flags that tell you that you have pawn scoring that >>needs piece values added in. Then if you get a pawn hash, you get a partial >>score, plus flags telling you what is passed, what is a candidate passer, >>where you have a majority, where you have weak pawns, and then you use those >>flags later, but you avoid the cost of computing the flags... > >OK, in some of these cases it might be possible to store a *very* rough >approximation of the score in the pawn hash table. But is it really worth >it? IMHO, the answer is clearly "no". I don't agree with "clearly no". Some of the pawn stuff is simply stand-alone as I mentioned. I have one 32 bit int that contains all the static pawn-only scoring I can do. For things that feed into a second-order or third-order evaluation term later, I just store the raw data. IE two 8bit masks to identify passed pawns for each side, one 8bit mask to identify open files, etc... This is repeated for the fairly expensive blocked pawn and weak pawn analysis. I want to do _everything_ here I can as it is basically free when it is hashed. The things I can't do here I simply have to defer to later and absorb the cost. > You inflate the size of your >pawn hash table entries, and the performance win is probably too small >to even be noticed. All the time consuming stuff is going to involve >the placement of the pieces anyway. Besides, the readability of your >evaluation is much better if all your pawn structure evaluation is >found at one location in the code. A computation which starts in the >pawn hash table code and continues in the main evaluation function is >not easy to follow. I don't do that. I start the stuff in EvaluatePawns(). I finish most of it in EvaluatePassedPawns() for example, except for the EvaluateKingSafety() that needs the pawn shelter info... But in any case, I don't see how the main evaluation function will be easier or harder to follow. I use the pawn structure information all over the place, whether I have some already-computed pawn structure scoring or not... > >The only major advantage I can see of having some kind of approximate >scores in the pawn hash table is that having an upper and lower bound >for the pawn structure eval for both sides could be helpful if you want >to use some kind of lazy eval. > >>> That's why it doesn't make sense to store any scores >>>in the pawn hash table. The proper way to use a pawn hash table is to >>>store some of the pawn structure related information you need to >>>compute scores. >> >>Again, it depends. I look at both the king and queen-side pawn shelters for >>the king, and add up "defects for each side. I store these two values in the >>pawn hash entry and later use them to compute king safety scores when I factor >>in material on the board, and how many pieces are close to a king that is >>exposed. But _some_ of the scoring is piece independent. IE doubled pawns >>have nothing to do with whether you have all your pieces or none. Ditto for >>the base isolated pawn score. > >I disagree entirely, especially regarding isolated pawns. Whether a >central isolated pawn is an advantage or a disadvantage depends almost >entirely on the placement of the pieces for both sides. I don't see how >it is even possible to give an approximate score without first having >computed other, time-consuming evaluation components like mobility, >space and king safety. "isolated" == "weak". I don't treat isolated any differently than a weak pawn. Notice I said "base isolated pawn score". That doesn't mean "complete isolated pawn score". > >In my engine, I do the pawn structure evaluation in two passes. The first >pass is done in the beginning of the evaluation function, and is entirely >qualitative. It identifies passed pawns, isolated pawns, weak squares, >pawn chains and similar stuff, classifies the central pawn structure, >and so on. All this information is stored in the pawn hash table. > >The second pass is done near the end of the evaluation function, when >everything else (material, piece placement, mobility, space, king safety, >coordination, etc.) is computed and evaluated. This second pass is >quantitative, and serves to compute the pawn structure evaluation. >Because virtually everything depends to a great extent on the other >components of the evaluation function, nothing is hashed. That's up to you of course. But how do you use pieces to evaluate doubled pawns? Or pawn levers (or the lack thereof)? There are _several_ pawn things you can evaluate easily without looking at pieces at all. There are also several that require piece information. The former I score when I do the initial analysis, the later I compute at the point where I have the needed piece information and use the information from the pawn hash if it is applicable. > >Tord
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.