Author: Roberto Waldteufel
Date: 16:31:58 11/04/98
Go up one level in this thread
On November 04, 1998 at 10:27:38, Robert Hyatt wrote: >On November 03, 1998 at 21:20:50, Roberto Waldteufel wrote: > >> >>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 > > >You *must* scale... you can't just suddenly decide to turn something off or >on, because you introduce a discontinuity in your evaluation. I have a few >of these right now because I have been testing some new eval code, and as >expected, right around the discontinuity I saw some gross problems, like >sacrificing a pawn just to "jump over the gap" and turn something off. Once >I was sure I wanted to turn something off or on, I then used a "Scale()" >function I have to gradually turn it on or off so this doesn't happen. > >But in any case, if you turn something on or off suddenly, it will definitely >cost you in the right circumstances... One example is rook on the 7th. This >is much stronger in the endgame than in the middlegame. To test the idea I >just turned it on at some point, which doubled the score. And it worked very >well, except right around the material threshold where it got turned on. There >it would act "funny." I now "scale" the rook-on-7th bonus from something very >small in the opening to something substantial in the simple endgames... (and I >still suddenly turn it off if the king leaves the back rank and there are no >pawns on the 7th to attack, as the rook suddenly becomes quite worthless on the >7th then...) Hi Bob, I think I read somewhere that this sort of problem is called the blemish effect. I have only rarely observed observed blunders due to this in relation to king safety, but my "turn on/off" decision for each king is based solely on the pieces (not pawns) of the opponent, so it would only drop material to improve this score for itself if either: a) This entailed making the enemy very unsafe, eg an exchange sac on f6 for example (but king would have to be made very exposed for this pay off), or b) By sacrificing some material it could swap of lots of pieces in a position where its own king is unsafe. In both cases the sacrifice is at least *plausible*, in (a) it may lead to entertaining speculative sacrifices for king-attacks, and in (b) it is often indeed the best approach, eg returning a gambit pawn to alleviate a strong enemy attack against the king position. I typically award quite large bonuses and penalties for exposed kings, which accentuates these effects. In fact, I may well have it valued too highly, but it produces some interesting and entertaining results. When it makes an aggressive sacrifice and wins, it is very satisfying, and even if the sac is refuted, the game is at least an interesting tactical battle. It seems to work particularly well against human opponents. By using only opposing pieces to decide if a particular king's safety is relavent, I think I am not far from the real situation in a game. I mean, suppose you are playing a game and you are, lets say, a pawn up, and what's more your extra pawn is passed and on the a-file, but it is not very far advanced. However, your castled king on the kingside is being attacked vigorously by the opponent with, say, a queen and a couple of minor pieces. If you can force the exchange of queens, you are probably winning, but if not you may get mated, or at least perpetualled, before your passed pawn gets going. So surely if a program is looking at the line that forces the exchange of queens, it is correct to suddenly turn off the bonus as the enemy queen is captured, reflecting a big change of fortunes in the game? I suppose this would have quite a big effect on a scaling as well, though. But I think perhaps king safety material threshold is more of a yes-no type situation than is the case for a rook in the seventh rank, which is of course also related to king safety in the middlegame. A rook in the 7th is generally dangerous at most stages of a game, but an exposed king is of no consquence at all one the pieces are sufficiently thinned out. 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.