Author: Sune Fischer
Date: 06:48:06 08/08/03
Go up one level in this thread
On August 08, 2003 at 09:30:25, Russell Reagan wrote: >On August 08, 2003 at 08:58:58, Sune Fischer wrote: > >>Well you already seemed to have understood it :) >>The problem is, that in a typical position you have ~40 moves. >> >>Now it is a waste of time to generate all 40 moves, then do move ordering on 40 >>moves, only to fail high on the first one you search. >> >>So, the idea is to generate high probablity cutoff moves and search those first. >>Not only do you save time in generation but also time on ordering them. > >I guess doing it as you say isn't the most efficient, but I don't see that it is >drastically inefficient either. For instance, even if you generate all moves and >sort all moves (and even if you do what you say and try to avoid >movegen/sorting), you are getting an exponential speed up from better move >ordering by backward pruning for a (more or less) constant time investment. Luckily you don't have to sort the whole list, just find the best move and try that. But even this is O(n) operations, requires at least a single stride through the move list, that's 40 compares per node. >Maybe it is more important than I imagine. How much weaker do you think, say, >Chess Tiger would be if it generated and sorted the entire move list instead of >doing it as you say? I don't know, as you say it's just a constant speed deficit, nothing exponential about it, but it can still be significant. Christophe has to answer on behalf of CT, I'm not qualified :) -S.
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.