Author: rasjid chan
Date: 08:11:02 03/24/04
Go up one level in this thread
On March 24, 2004 at 07:25:09, Peter Fendrich 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 > >Well, not really. We have different programs but you're right I forgot to >mention the move ordering part. >I don't sort moves at all. I generate them in stages and play them before the >next stage is generated. The stages are hashmove, good captures and so on... >In the last stage (if no cutoff was produced before) I generate all of the >remaining moves and pick the 3-5 (depending on prev. history) "best" moves in >order but without sorting. After that I just take the moves in the order they >occur in the list. >This is what I've tested with ETC: > - In the stage picking the 3-5 moves I go through the moves > and probe the hashtab using the hashkey they would produce. > - If a child FH is found handle it and take the next move. > - If a child FL is found the current node is finished. > - If the probe announce a hash hit inside the A/B window, > assign that value to the move and act accordingly > (in some cases finish the current node) > - Otherwise go on as before > >I haven't seen any win at all even if the tree shrinks. On the contrary it is a >loser for me... > >/Peter I have yet to test genuine ETC and if Tord tested that it worked (a clear winner), I have reasons to GUESS it has a good chance to work ... FOR SOME TYPE OF IMPLEMENTAIONS. Pseudo ETC already shows great promise for me and paying good dividends simply because probing etc... before actually making a move is cheap in my case. I think it MAY NOT pay dividends in your program. I recently made some changes to my move-ordering which I considered important and correct and the impact seems significant. My raw suspision is hashmove, good catures, etc is NOT ENOUGH for ETC; it may need to be complemented by a CLEARLY SELF-SUFFICIENTLY GOOD MOVE ORERING before it works. If I get you correct, your approach shortcut on move-ordering instead of doing more move-ordering analysis with attack tables, etc. that Tord may be doing, an entirely different approach that may not be compatible with ETC. Another thing. I'm not sure we need to test all moves. I happen to be doing lazy eval() before makemove so this itself prunes likely fail-low moves and if coupled with a good analysed-type move-order that pushes likely good moves front, it may have a good return... speculation at the moment. Rasjid
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.