Author: martin fierz
Date: 04:13:49 02/12/04
Go up one level in this thread
On February 12, 2004 at 05:32:02, Tord Romstad wrote: >On February 12, 2004 at 04:40:34, martin fierz wrote: > >>On February 12, 2004 at 04:23:54, Tord Romstad wrote: >> >>>My entries are much bigger; currently 128 bytes. I store all of the above, >>>as well as information like total number of pawns on black/white >>>squares for each side, total number of blocked pawns on black/white squares, >>>weak squares, open files, pawn storm stuff for use in positions with >>>castling to opposite sides, and a classification of the central pawn >>>structure. >> >>yes, obviously one can store lots of stuff. i also have some code on most of >>your topics above in my engine, but i forgot when i wrote my post :-) >>i can think of many other things too. > >The problem, at least for a weak chess player like me, is to find good >ways to use all the information. When I implemented the pawn hash table, >I had ambitious plans of writing special search and eval code for each >of the most common central pawn structures. For instance, when the >pawn structure is classified as FRENCH, the engine would know something >about the most important thematic moves in the French defence, and >extend (or perhaps just avoid to prune or reduce) these moves. Evaluation >terms specific to one particular central pawn structure could also be >added (rules like "in the SICILIAN_PELIKAN pawn structure, white wants >to exchange the minor pieces, especially black's light-squared bishop"). > >I still haven't written any such code, however. The classification of >the central pawn structure is currently not used at all, except that >I evaluate differently depending on whether the centre is open or closed. >Before I can add something more sophisticated I need to improve my own >chess knowledge. honestly, that sounds like a too ambitious classification scheme - and also far too complicated. pawn structures like SICILIAN_PELIKAN are far too fluid to be nailed down properly IMO (i.e. you will end up detecting it sometimes, sometimes not). i also detect whether the center is closed or blocked or open, like you do. i'd like to extend that a bit more still, but then i'd assume it to be good enough. many of the rules on play in different openings come from "higher-level" general principles; if you implement these, you should cover the special cases. > >> and thanks to your information... >> >>>In my opinion, there is no reason to be afraid of having big pawn hash >>>table entries, because you need very few of them. The pawn structure >>>doesn't change that often. I've found that 256 entries is enough in >>>my engine. Making the table bigger gives only a tiny speedup. >> >>... that even 256 entries are enough, i won't mind putting all that stuff in! >>thanks for sharing. > >You should note that I don't hash the kings, though. If you do, you will >certainly need a much bigger table. i don't hash kings, and i don't plan to. what i can imagine though is to generate information on squares where the kings might feel good/bad depending on pawn structure. that information can be used for king eval later easily. at the moment, in the king eval i take the square where the king actually is, and compute lots of stuff about surrounding pawns, open/semi-open lines around the king etc. i hope i can stuff most of that knowledge into the pawn hashtable and retrieve a value from there which i can modify according to the number of pieces on the board for a starting point in king safety. 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.