Author: Tord Romstad
Date: 13:44:12 03/24/04
Go up one level in this thread
On March 24, 2004 at 14:26:04, Tom Likens wrote: >On March 24, 2004 at 05:39:20, Tord Romstad wrote: > >>On March 24, 2004 at 05:17:56, Peter Fendrich wrote: >> >>>Uri didn't invent ETC if that's what you imply! >>> >>>Given your story about costly move/unmove functions it's possible that ETC gives >>>you some savings. Without ETC you will hit the cutoff anyway in the child node >>>and with smaller unmove costs ETC is not that effective IMHO. >> >>It seems to me that you miss part of the idea of ETC. You are right that >>you will get the cutoff in the child node even without ETC, but in which >>child node? If your move ordering is not perfect, there is a risk that >>you will have to search many moves before you get the cutoff. When you >>use ETC, you check the hash values for *all* child nodes before you >>start searching, which can sometimes save a lot of nodes. >> >>To me, ETC has always been a clear win. The last time I made any >>experiments, it reduced my tree size by about 10% at high search depths. >>I am fairly sure it is a technique which works better with MTD(f) than >>with more conventional search algorithms, though. >> >>Tord > >How do you handle extensions? Currently, most of my extensions are >set after the engine moves and since the extensions affect the draft >(which in turn affects the validity of the hash match) it seems like this is >a problem. This might be workable (in my current scheme) if I started >tracking the extensions that were triggered by a move in the hash >table. You are right, this is a problem. My "solution" is to ignore the problem and hope it isn't too important in practice. Tord
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.