Author: Dann Corbit
Date: 15:37:48 02/11/04
Go up one level in this thread
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. 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.