Author: Sergei S. Markoff
Date: 03:01:43 10/02/03
Go up one level in this thread
Hello! >>The "for the >>same reason" seems wrong, since all you are looking at is the refutation move. >>Note that the _best_ move is not needed to produce a cutoff, just "a good enough >>move". It's a methaphysics (: What we can really found in practically playing program? If we're using SEE (like Crafty and SmarThink also) we will produce most perspective captures first. Captures is ordering by SEE and also transp/ref table. But in most cases in trans/ref table we can found "LOWER" or "HIGHER" results. That's why if the best capture that was produced by SEE leads to cut-off than _this_ move will be in trans/ref. That's why practically "same threat extension" in most cases founds the largest consequent threats. Also you can found that in a lot of cases in node there are not more than one winning capture/promotion. >This problem can be reduced (though of course not completely eliminated) >by a minor modification to the move ordering. In my implementation, I >search moves with the same target as the refutation move from two plies >earlier directly after the move from the hash table (this move ordering >trick is only done at nodes where the move leading to the node was a null >move, of course). > >So far, it seems to work rather well, at least in my program. Well. It's the other idea to use threat data - to produce better move-ordering in threat nodes. I tried something before but still not included it to public version. Best wishes, Sergei
This page took 0.02 seconds to execute
Last modified: Thu, 07 Jul 11 08:48:38 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.