Author: Robert Hyatt
Date: 19:04:41 06/10/99
Go up one level in this thread
On June 10, 1999 at 11:30:59, William Bryant wrote: >Good luck to all moderator candidates. And now for something completely >different ... :) > >A couple of questions. > >I re - de -bugged my search after adding the killer heuristic and noted >that it does better in most positions - _but_ - some positions seem to do much >worse. I suspect this continues to be a move ordering issue. > >For example, >on the endgame position FINE 70, >without the killer heuristic it fails high on ply 26 finding Kb1 in about 3 1/2 >minutes, but with the killer heuristic, at about ply 20 or 21 there is a >noticable slow down in time to achieve the next ply. > >Are there some positions or phases in the game where the killer moves are not >needed and should be avoided? > not at all... but notice that this is called 'the killer heuristic'... where 'heuristic' means "rule of thumb". And "rules of thumb" aren't perfect. IE overall killer will shrink the tree (if you don't use history). But for some cases, killer might make you search more nodes... just so you gain more than you lose, it is effective. >Is this a bug ( or feature ), and most likely due to move ordering? >If so, why apparent only after ply 20. because at some point you begin to "smell" the solution early. It takes 26 plies with really good move ordering. The worse your ordering, the sooner you find the right solution... (fine 70) Once you get a 'sniff' you start searching more to find other ways for the opponent to avoid losing the pawn, but this takes time... > >I noted that on this position the history heuristic begins to add up to some >larger numbers. Is there a point where the history table should be reset or >reduced within a search rather than only at the start of each search? just don't let it overflow. I don't use the number Jonathan mentioned, I use ply*ply, which doesn't add up as quickly. If it overflows, you have trouble. And I don't clear them at the start of a search, but I do 'age' them by shifting right N bits (Don't remember what N is but you can find it in Crafty's source)... otherwise they will overflow and break... > >Lastly, I'm thinking of adding attack tables to speed up the search. At >present, I think they would be helpful in identifying all the squares that a >pawn or piece can attack when placed at a particular location which would speed >up the InCheck() function. Where else would these tables be helpful? Since I >plan to use 64 bit long long values and logical 'and' those with a square mask, >this will return a boolean value about whether the piece attacks. Can they be >used in move generation? Other locations? Any comments, pointers, or referances >to articles or source code would be appreciated. > >William >wbryant@ix.netcom.com whether this wins or loses is a good question. We did it in cray blitz, but we had vector hardware that made such easy to calculate. I don't do this in crafty, rather I compute it as needed...
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.