Author: Roberto Waldteufel
Date: 18:20:50 11/03/98
Go up one level in this thread
On November 03, 1998 at 10:37:59, Ernst A. Heinz wrote: >On November 02, 1998 at 16:31:56, Robert Hyatt wrote: > >>On November 02, 1998 at 10:13:52, Ernst A. Heinz wrote: >> >>>On November 02, 1998 at 08:32:48, Robert Hyatt wrote: >>>> >>>> [...] >>>> >>>>how many entries? IE I never paid attention to this hash number when we ran >>>>on a 16gb machine because we used such rediculously large hash tables. But if >>>>you can get such a large hit percentage with pawns+kings, then the original >idea >>>>of pawns+kings+rooks ought to be pretty close, because even the king can walk >>>>a long way in a 12 ply search... >>>> >>>>however I generally run with 10mb pawn hash, which is something like 500K >>>>entries, and don't ever see this number under 99% (integer truncation)... I'd >>>>think it has to be bigger to stick at 99% with kings factored in...??? >>> >>>No, at least not according to my tests. In "DarkThought" it works just fine >>>starting with 512K entries and does not decrease badly if you scale the numbers >>>of entries back to 128K. Please note that we do not factor in both Kings at >>>once but rather distinguish between Black and White. Still, we only keep a >>>single hash table for our complete King+Pawn hashing because of performance >>>considerations (albeit with different keys and locks for Black and White). I >>>think that lazy evaluation and capture-only quiescence enable us to factor the >>>King in without much degradation of the hit rate (we hardly ever evaluate any >>>non-quiescence nodes). Of course, it is also crucial to factor the Kings out >>>as soon as they start to wander far around the board. >>> >>>Unfortunately, the addition of any other piece to the hashing drops the hit >>>rate to 50%--75% just as the original poster reported. I have not yet found >>>the cute trick that let's me raise this rate ... :-( >>> >>>=Ernst= >> >>It would still seem that this should be worse... because you have the same >>pawn structure hashed multiple times with different king positions, and now >>you have the same pawn structure hashed once with each side's king position, >>which seems like you hash each pawn structure *twice*??? > >No. > >We hash black King safety (bK + P lock), white King safety (wK + P lock), and >general Pawn structure (stored together with wK + P). This leads to multiple >analyses of the general Pawn structure for different locations of the white >King. Fortunately, this does not heavily affect our hit rates. > >On the 33 "Test Your Positional Play" middle-game positions with many pieces >still on the board for both sides our K+P hit rates averaged 97%-98% for hash >tables with 512K entries and 95% with 64K entries. So, we do not really get 99% >but very close to it and well above 90%. However, in some positions our hit >rates drop considerably (worst case in the above test: 85%) which may be due >to the fact that we factor the King in. > >>I'm not sure I follow? Two separate hash keys dynamically updated? Pawn >>hash with king hash folded in at probe time? Two stores, once for each king >>position, but with the same pawn structure stuff??? > >We update only the Pawn hash-key, of course. We factor the (white) King out >by virtually fixing it at "a1" as soon as we deem King safety unnecessary. > >=Ernst= As a matter of interest, what is your threshold for deciding whether king safety is relavent? And do you scale your king safety according the material of the opponent, or do you use a boolean yes/no decision without scaling? I think Chess 4.x used a scaled king safety function, but I think that must be slower because of the need to multiply. How do you measure king safety? I use various penalties for open or half open files adjacent to the king, and also a count of the pieces attacking the squares adjacent to the king. If there are fewer defenders than attackers (summed for all squares adjacent to the king) then I award a penalty proportional to the difference. This is cheap to calculate because I maintain incrementally updated atkto bitboards for all the squares, and I have found it a very useful discriminator, causing the program to play quite aggressively. The bonus is of the order of a third of a pawn, so sometimes the program will even willingly sacrifice material for a strong kingside attack, which is very satisfying to watch, although sometimes it's sacrifices are not quite sound (though usually then still quite dangerous!). But I still think that there are probably more things that ought to be taken into account if they can be calculated with suitable speed and accuracy. Best wishes, Roberto
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.