Author: Inmann Werner
Date: 06:44:25 12/01/99
Go up one level in this thread
On December 01, 1999 at 09:13:15, Jeremiah Penery wrote: >On December 01, 1999 at 09:02:29, Jeremiah Penery wrote: > >>On December 01, 1999 at 07:50:34, Inmann Werner wrote: > >>>and the hash entry is only used for stopping the search, >>>if the found value is lower than alpha. >> >>But at a fail-high, EVERY MOVE for the next ply failed low - they will ALL be >>less than alpha. > >I thought more about this. :) > >When this happens some random place in the tree, it probably isn't too bad. You >may not have to ever re-search these positions, because they're pointless >branches. That was my thought!!!! >The place where it really hurts is when you get a fail-high at the >root, because that means you have to research everything from depth=2 and >beyond, since all the ply 2 moves failed low. This will definitely affect the >PV, and the speed. But that always must be done!?!? Research the whole crap again with an open window(-matescore,+matescore). But here, my hashentry will not be used, cause the value is not lower alpha. Where is the problem here? >Previously, did you store a hash entry for each position for ply 2 moves, since >they all failed low, or did you just put a random move in and mark it fail-low? >I'm a bit confused - You didn't use the fail-low for move-ordering in the hash >table, but isn't the first thing you do for move ordering to probe the hash >table? You will find that this node is a fail-low node, and then you will >search the other nodes first, or...? I'm thinking that it was somehow affecting >move ordering, even if it was unintended. I am also confused :-( But it turns to get interesting :-) From a give position, i search all moves. When this is done, I put the best move of all in the hashtable. At fail low, this is a little bit random. Also i give a flag that says "fail low" to the hashtable. At move Generation, I make a look in the hashtable, if there is a move present for the position and give the move "rank 1" (try first). If there is a move with "fail low flag", I say, no move is in the hashtable, so make normal sorting, as if no hash present. So, IMHO, move ordering is not directly affected. At hash-probing, when i find a "fail low", i look, if the evaluation of the position stored is lower alpha. If yes, I return the value to alpha-beta and there the search does not go deeper. (It is again a fail low) Maybe here is the problem: I once searched the position with a fixed alpha-beta window and got a fail low and stored the value. Now i come back to this position with an other alpha-beta window. The stored value is lower than alpha, so I use it. (the problem!) Can this be incorrect? Can with this new alpha-beta window come out a value in the search, which is not a fail low, cause some beta-cutoffs are handled another way deeper in the search? Werner
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.