Author: Vincent Diepeveen
Date: 07:44:18 01/09/01
Go up one level in this thread
On January 08, 2001 at 17:19:32, Severi Salminen wrote: >>>>i see you have 'futile moves' also. If you throw futility pruning out, >>>>then nullmove should work brilliant positionally spoken. >>> >>>I tried, but the behaviour was the same. But then I removed my very stupid >>>3-fold repetition algorithm (it is only adding different bitboards of a position >>>to get a "key") and I got results with no fail highs or lows. I must find >>>another way to find repetitions... >> >>aha perhaps there is the bug then! > >Actually no. Forget what I said above. The first modification was that I >returned 0 if a position was reached 2 times instead of 3. This was the case >when search results were different. Then I removed the whole sh#t and I got this >odd failhig/low phenomenon again. The reason is nullmove (and nothing else) and >at least according to Bob this kind of behaviour is unavoidable so I don't I do not have this weird fail high fail low problem a lot of times. I had it when i forward pruned bigtime in DIEP or when i didn't store extensions in hashtable. Also systems like junior uses caused it bigtime in diep (normal move is worth 2 ply, good move 1 ply) as long as i allowed alfa and beta to influence what a good move was (and therefore would be extended, though you can also store this into hashtable). If you do things like threat or mate extensions you must store it in hashtable or you get the weird fail high fail low because of inconsequent way of searching! Basically nullmove is nothing more as a way of giving the opponent twice the move which means you detect threats real quick. Perhaps an idea is to simply try to search without nullmove the last 3 ply and see what that gives for kind of effects? So keeping nullmove on the top plies? Another interesting possibility: perhaps your repetition keeps on working after nullmove. Is nullmove implemented such that you don't try to get repetition from positions before nullmove? >worry >it again. The funny thing is that with the "2" version my engine found the >desired a5! very quickly but without repetitions it insists on Kb3... >>do you store repetitions in hashtable? > >No. I just generated this "hashkey" (it didn't probably work) and stored it to >an array every time I entered a new position. Associated with this key was a >counter and when it reached 3 I returned 0. I don't have hashtables implemented >yet so that is the next thing to do. And with hash the repetitions should be >easier to include. BTW should one count 2-fold repetitions instead of 3-fold? >With 2 you would get the same result and prune more nodes? > >>simplest solution is to never give a cutoff from hash if >>it is score 0.00, that's what i do and it always worked. > >Sounds reasonable. 0.00 means (or should mean) draw after all :) > >Severi
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.