Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Uri's ETC

Author: Peter Fendrich

Date: 08:25:01 03/24/04

Go up one level in this thread


On March 24, 2004 at 11:11:02, rasjid chan wrote:

>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

Of courcse you should try it. My and Tord's approaches are completely different
and the different experiences of ETC are not surprising at all.

I think my ordering is not bad but of course it could be better. The reason to
stop after 3-5 moves (plus the maybe 5 moves that was made before) is that if no
FH appeared until then the whole node is probably a FL node and the order of
moves is not important or at least much less important.
/Peter







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.