Author: James Swafford
Date: 13:25:59 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. You will re-re-debug it soon. :-) > >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? > >Is this a bug ( or feature ), and most likely due to move ordering? >If so, why apparent only after ply 20. I don't think it's a bug, but merely a case in which the killer move was simply wrong. If you think about it, the whole point of the killer move is to get a cheap cutoff by trying a move that was known to produce a cheap cutoff in some other level of the search. If you try the killer, but it doesn't produce the cutoff you were hoping for, and you would've otherwise ended up searching that move *after* the move that actually does produce a cutoff (if there is one), then you lost. If none of the moves in your list produce a cutoff, then it doesn't matter anyway. Can you avoid this? I don't think so. It doesn't make sense to me that you can avoid searching your killer move because it is unlikely to yield good results. How can you possibly know that? > >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? Hmm... is your data structure on the verge of overflowing? Maybe you should try dividing it every so often, or shifting the bits back a couple notches if it becomes ridiculous. How are you updating the history array? With depth, depth*2, depth*depth? > >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. They could be used in move generation. If you know a bishop attacks F3, you can almost always move there, barring some check issues. They may also be helpful in your evaluation, if you want to add such terms as bishop/rook/queen mobility. You could just do a pop count of the 64 bit word representing a pieces attacked squares. I think the possibilities are endless, but you'll pay a heavy price for them. Be prepared to do a lot of testing. :-) -- James > >William >wbryant@ix.netcom.com
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.