Author: rasjid chan
Date: 21:26:37 03/24/04
Go up one level in this thread
On March 24, 2004 at 20:16:26, Tom Likens wrote: I think this is sufficiently clear as what ETC is, so I think the extention don't cause problems in some implementations. Like Uri said, why make the move if we don't need to, provided some cannot clear the extention thing without moving.. rarely... Linearly obvious is nullmove before ETC... Rasjid >On March 24, 2004 at 16:59:57, Dieter Buerssner wrote: > >>On March 24, 2004 at 14:26:04, Tom Likens wrote: >> >>>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. >> >>I don't get it. How could you track the extensions that were triggered by a >move in the hash? We are speaking about the situation (current position) is >>already after that move. > >I'll try to explain what I was referring to in my previous post. Hopefully, >I won't mess it up too badly (although I make no guarantees). According to >my reading of Plaat and Schaeffer's original ETC forumlation the order things >occur in is roughly: > >1. When first entering a node, check the transposition table for a match. > If found then handle it (return up the tree etc.), otherwise... >2. Generate all the moves for this node >3. Make the first (next) move in the move list >4. Check this new position for a hash match (this is the ETC part) >5. If we find a match then handle it and return back up the tree, > if appropriate >6. Goto 3 and repeat until all moves are exhausted > >Most implementations that I know of, don't actually perform step 3 but instead >simply update the hash key without making the move. But we still need to >recreate the extensions for this move in order to determine if the draft is >OK (and hence if the match is valid). Since we have the move in hand, most >extensions can be recreated without too much effort (pawn pushes to the 7th, >recapture extension etc.) We can also store if either king is in check in the >hash table entry and if we assume that the current move (that we *haven't* >played) would have placed the king in check then we can correctly apply the >out-of-check extension. > >ETC should probably be applied after the null move search so that the threat >extension gets handled properly. If I've missed anything obvious please >don't hesitate to point it out. I'm considering experimenting with this >and would like to not waste my time implementing a flawed version of it. > >--tom > >>You could of course easily store extensions that were triggered >>by the suggested hash move in the HT. But that is one move too far. You could >>put in the move, by which you reached the current position, but this is somehow >>in contradiction to the whole idea of *transposition* tables. >> >>I see no other solution, than carefully trying to do the same adjustments to >>depth for each move (ideally by the same code) than the normal search algorithm >>would have done, at the time, where you probe the HT in the ETC code. >> >>Regards, >>Dieter
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.