Author: Vincent Diepeveen
Date: 07:48:40 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 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? Of course 2 times repetition is sufficient. Did you boundscheck your program already? I had in past many boundary bugs there which were not detected under any OS (HP-UX,SUNOS,LINUX,WIN$) as they referenced to existing memory. Usually weird behaviour in programs where you don't forward prune on alfa (either in qsearch or normal search) nor forward prune in normal search (except for nullmove) is only because of bugs inside the program! >>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 :) Oh well 0 or whatever score is your draw score. >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.