Author: Tord Romstad
Date: 07:28:48 01/13/04
Go up one level in this thread
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". 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. 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. 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. 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.