Author: martin fierz
Date: 01:59:29 02/12/04
Go up one level in this thread
On February 11, 2004 at 18:37:48, Dann Corbit wrote: >On February 11, 2004 at 18:29:53, martin fierz wrote: > >>On February 11, 2004 at 18:13:25, Dann Corbit wrote: >> >>>On February 11, 2004 at 18:01:44, martin fierz wrote: >>>[snip] >>>>hi dann, >>>> >>>>i am quite aware that a normal hashtable works as you say - store a key and a >>>>score. but really, i think that is a much too simplistic view of pawn structure. >>>>pawns interact with pieces in complex ways, and i basically would like to store >>>>the information i think important about pawns in the pawn hashtable, to retrieve >>>>them quickly later. i can also imagine storing a "baseline score" for the given >>>>pawn configuration. but i really want interactions with pieces too, and as i >>>>can't hash scores for that, i'd have to save intermediate computations (such as >>>>connected passers, or potential levers etc) in the pawn hashtable, and then use >>>>them for the interaction terms. >>> >>>I bet it will be more expensive to store all that stuff in the hash table and >>>try to reuse it than to recalulate it. >> >>one hashlookup will cost something like the average memory latency for >>non-cached stuff. that's probably around 50-100 processor cycles. if there are >>more than 100 processor cycles in what i store, i should be fine. >> >>>The best thing about the pawn hash table is that the kings and the pawns move >>>slowly. You don't see a ton of rapid change and so a small table gives a lot of >>>hits. If you want to store things about rooks backing pawns and other things of >>>that nature, I think the table will change quickly. What will you have? An >>>ordinary hash table entry. So why bother with it? >> >>nope, that's not the idea. i want to store pawn stuff only, of course. but >>instead of keeping a score, i would store, for example, a passed pawn bitboard; >>or a bitboard with all bits set behind passed pawns. then a simple & with the >>rook bitboard gives me supported passed pawns. you can imagine more complex >>stuff to do, like you could look at the pawn structure and produce a bitboard of >>squares where you think your king is safe and where not. then again, a simple & >>gives you the answer. > >I guess what I am saying is that the benefit of a pawn hash will be lost if you >do too much work. After all, all of the above calculations will be stored in >the regular hash. So you will not redo them if you have seen the position >before. And if something changes, you will have to recalculate. no, you are completely misunderstanding the idea. i want to store *intermediate* calculations in my pawn hash, which are not scores at all, but simply pawn-related stuff that i can use all over my evaluation. instead of computing all that pawn-related stuff at every node. since these are only related to pawns, i don't have to recalculate anything if the pawn structure doesn't change. as an example, take the task of finding isolated pawns in a bitboard. i don't know how to do this efficiently. my code to do this is extremely ugly and slow. if i simply store the isolated-pawn-bitboard in the pawn hashtable, i can retrieve it after a lookup, and, depending on other things of the board, evaluate it. or i could simply store the number of isolated pawns in the pawn hash. then in the search, i do a lookup, and evaluate the isolated pawns. for example, my chess understanding tells me that isolated pawns are bad when there is little material on the board, so i would add some code like this pawnstructure = lookup(pawnhashsignature) isol_eval = ISOLATED*(pawnstructure->b_isolated - pawnstructure->w_isolated); isol_eval *= f(material_remaining); this is where our views differ: you would not have the third line in your code. you would simply evaluate isolated pawns without looking at the pieces, and add isol_eval to your total pawn score, and then use that without adjusting for pieces. i believe "my" approach is better :-) as you can see from other posts, tord is using this idea with good results, and bob also has such things in crafty (although not very extensive). cheers martin > >Why not store that stuff in your position itself? (e.g. the passed pawn >bitmap). > >Putting it in a hash table does not make sense to me. > >Besides, a pawn may be obstructed/not obstructed by something other than a pawn. > Or it could lose its backing. So if that happens, you will need to do a recalc >of that stuff anyway so it would go in the regular hash. > >What will you be saving over storing in the regular hash table? > >>>But it would be nice to experiment both ways and find out what works better. >> >>of course :-) >> >>>Personally, I would start simple and add things. If the thing I added made it >>>slower, I would >>>#if 0 /* Here is a bad idea that I tried: */ >>>// old code >>>#endif >>>around it. >> >>i do that all the time too :-) >> >>cheers >> martin
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.