if your IID search fails low, do you re-search with -infinity,beta? Or do you move on with no best move?
I tried the re-search, and it helps in some cases, but it trashes the Fine hash test position for me, which I would like to retain bragging rights for...
IID re-search if fail low
Moderator: Ras
-
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL
Re: IID re-search if fail low
The reason for doing an IID in the first place is to get a best move to search in a critical position. I would lower alpha and re-search since you _still_ need a best move.AndrewShort wrote:if your IID search fails low, do you re-search with -infinity,beta? Or do you move on with no best move?
Not sure why it would hurt there at all since it is (in my case) a positoin where IID is not really useful... You could always try a different hash size anyway, since that usually changes the results significantly...
I tried the re-search, and it helps in some cases, but it trashes the Fine hash test position for me, which I would like to retain bragging rights for...
Re: IID re-search if fail low
I should try the re-search with -infinity, alpha instead of -infinity, beta..., since I know from the fail low that alpha is an upper bound. If due to search instability I then fail high, I still get a best move out of it. Something to try...
Re: IID re-search if fail low
I agree, it's puzzling, because with so many hash hits, iid should not come into play very much. I need to look into it...Not sure why it would hurt there at all since it is (in my case) a positoin where IID is not really useful... You could always try a different hash size anyway, since that usually changes the results significantly...
-
- Posts: 1822
- Joined: Thu Mar 09, 2006 11:54 pm
- Location: The Netherlands
Re: IID re-search if fail low
On average Hashhit (lower,upper or truebound cutoff) in Diep is 4 to 5%.AndrewShort wrote:I agree, it's puzzling, because with so many hash hits, iid should not come into play very much. I need to look into it...Not sure why it would hurt there at all since it is (in my case) a positoin where IID is not really useful... You could always try a different hash size anyway, since that usually changes the results significantly...
So 95% of the nodes, regardless whether your hashtable has a best move for it, you will need to search.
If you assume that searching with a different window means you search the exact same tree, that is a total misunderstanding of what a search space is.
The more efficient you search your tree, the more complicated it is to lose nodes to doing searches with a different search window.
Cost can easily go up to factor 6 of searching with a different window using a bigtime reduced depth.
IID with the same window has as advantage that you potentially search the same search space, meaning it is worth doing it sometimes. IID with a different window for sure has a big overhead.
Additionally most are agressive forward pruning, so doing a search of say 2 to 3 ply far above beta (if you search underneath beta in position P, then at P+1 it is above beta), most already forward prune bigtime everything that is a lot above beta or a lot underneath alpha.
In short claiming the cost is little is also not sufficient if that cost gets kept artificial low because of a direct forward pruning that happens after it.
Without that forward pruning i'm quite sure cost is quite huge. Probably at least 2 ply you lose (factor 6 or so). So it really needs to improve your move ordering bigtime in order to benefit you (winning 2 ply is not easy).
Vincent