Author: Robert Hyatt
Date: 16:13:38 11/27/00
Go up one level in this thread
On November 27, 2000 at 15:12:04, Scott Gasch wrote: >On November 27, 2000 at 14:17:15, Robert Hyatt wrote: >>I don't think your losing captures before killers is a good idea. My order: >> >>1. hash move (also includes PV move since it is passed thru hash) >>2. winning captures >>3. even captures (trades) >>4. 2 killer moves (before generating non-captures) >>5. 4 history moves (after generating non-captures) >>6. rest of moves in order generated, which would put the losing captures >> first since I generate captures first. > >I have often wondered if it makes sense to generate moves in stages. For >example, I currently generate all captures followed by all non-captures (if a >capture from the first stage did not cause a beta cutoff). I like this because >it's less work done if, for example, first move considered causes a cutoff. > >But if I am going to change the order of the possibly losing captures (MVV/LVA) >then I wonder if it makes sense to preserve the generate in stages model and >extend it to: > >1. generate winning captures >2. generate even captures >3. generate all others (normal moves and losing captures) > >Imagine there is an even capture on the board... this move will be generated in >1. and discarded only to be re-generated in step 2. This is a duplication of >work. Likewise with a losing capture -- it is generated three times in this >scheme... > >Another other alternative, I guess, is to generate all the moves available in a >position at the same time. However I dislike this because if the first move is >going to refute an opponent move and cause a beta cutoff, the other N-1 moves >were generated for naught. > >Maybe the best way to do this would be to incrementally generate -- have the >capture code come up with all the captures, then try the winning/even ones >leaving the losers in the move stack... then have the normal generator add in >the rest of the moves on this ply. Still, it seems like it could be done >better. > >On the same subject, what do you think about trying killer moves (beta cutoffs >at the same depth in other branches) if they are legal before _any_ generation >takes place -- just after the hash/PV move? This could save a trip to the >generator if they cutoff again. > Since I don't put captures in the killer move list, it wouldn't work for me at all. I don't put captures there because they are generally not repeatable. IE a capture that works good here doesn't work good there, because the most common useful capture is the one that rips the last piece moved... >Also, do you give a bonus to a "winning" (MVV/LVA) capture that appears to kill >the piece last moved by the opponent (i.e. if the last move (ply - 1) ended at >D4, any "winning" capture that ends on D4 in this ply gets searched before >others?) > >Thanks a lot, >Scott No. I make no distinction on which piece I capture. But I use SEE to order the captures from largest gain to smallest... This is more accurate than capturing the last piece moved...
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.