Author: Vincent Diepeveen
Date: 19:15:37 01/19/01
Go up one level in this thread
On January 19, 2001 at 21:46:10, Will Singleton wrote: >On January 19, 2001 at 20:19:43, Vincent Diepeveen wrote: > >>On January 19, 2001 at 19:47:20, Will Singleton wrote: >> >>>I was looking at my code today, and I noticed that I don't store or retrieve >>>check positions in and from the hash table. I have always had a bad habit of >>>not documenting my code, which stems from my origins as a hobby programmer. I >>>always figure I'll remember what x+ (temp-1) means, how could I forget? >>> >>>Anyway, do others store checking positions? If so, what happens if you disable >>>it? I'm asking because I had some weird results when I tried it. >>> >>>Will >> >>Yes i always store them and retrieve them and look whether >>i can get a cheap transposition. >> >>If that doesn't work for you, how about extending non-alfa or non-beta >>dependant? >> >>So simply either always or never extend them or only based upon the >>position and not the score? >> >>In that way you can sure that there is little difference between >>using stored scores. > >Vincent, I must say I have always appreciated your dialog here and on ICC. I do >not always understand what you have to say, and I must confess, this is one of >those cases. I'm sure it's my fault, but I have no idea what you just said. >Could you elaborate? > >Will Your basic problem probably is next: a position X with searchdepth left n is stored now. However a move i which is by accident best move in this position or a move which influenced this position is now extended by 1 ply. move i is extended because it had criteria which had alfa or beta in its condition. Some time later we get again to position X with sdl=n but it doesn't get a transposition for some reason. Now we have a different alfa and beta score so move i is not extended. So we search a different search tree and get a completely different score back for position X. the above doesn't happen however so much when compared to next example: suppose we have a position X sdl=n, and we do NOT extend move i. We store it into hashtable. After a while usually a very short while by some kind of transposition we get into position X again sdl=n. We get a transposition now HOWEVER with the current alfa and beta values we would have had an extension for move i which would have given a different score for position X. In both cases your search acts weird seemingly. Things like futility pruning (of course not with a positional margin as big as the biggest positional margin otherwise you can't call it forward pruning) will make the above behaviour even worse, yes in fact it's exactly acting like it. Idem for lazy evaluation, and all kind of pruning types that prune on alfa. Especially pruning on alfa in qsearch is very dangerous with the above examples. Of course it reduces node counts but it's dangerous. Last ply pruning with like 3 pawns positionally already saves me 15 to 30% node count easily, but for some weird reasons my program plays positionally a lot less as i would expect it to do then :) Anyway. extensions based upon alfa and beta just like forward pruning especially on alfa is going to cause the weird behaviour. This all thanks to the hashtable. Greetings, Vincent
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.