Author: Ross Boyd
Date: 17:25:23 09/02/04
Go up one level in this thread
On September 02, 2004 at 19:06:06, GeoffW wrote:
>>Hi Geoff,
>>
>>I think one possibility is this...
>>
>>I don't increment 'ply' when null-moving... (i decrement remaining depth, of
>>course)
>>
>>That may explain why Crafty works with +1 and TRACE works with +2.
>>
>>In fact, that may point out a capital search bug in TRACE. My nullmoves
>>'corrupt' the true value of ply. Not good. And it explains some odd search
>>behaviours. Also, I cannot test if (ply & 1) to see if the side to move is a
>>particular colour. I will fix this in the next week or so and see if it helps.
>>Oooooohhh.... I have a good feeling about this...
>>
>>Ross
>
>Hi Ross
>
>Yes, that does look like the explanation as to why there is a difference of +1
>
>I was interested to see what effect the correction would have so I quickly put a
>ply++ and ply-- around the null move search call.
>Not sure what your code will do but mine went Splat !!
>Thats going to be a fun one to debug, no idea what is causing it at the moment,
>hope your works better than mine. I will be interested to know how it worked for
>you ?
>
> Regards Geoff
Hi Geoff,
I implemented it last night and the results are pleasing. Now, it works with +1
AND +2... it finds some repetition draws earlier too. The search seems more
robust.
The bugs to look for to make it work...
1) Make sure your makemove fills in hist_dat[] with previous ply's values.
You will need to do a short nullmakemove which backs up the previous ply's
values.
2) REMEMBER to set first_move[ply+1] = first_move[ply], ie. zero moves in the
move stack at this ply... (this catches me all the time)
3) #define NULLMOVE as some impossible move integer.
4) Add this test at the appropriate place in takeback() (after resetting the
globals and before updating the board ...since there is nothing to update)
if (hist_dat[hply].m.u == NULLMOVE)
return;
5) Its probably a good idea to increment 'fifty' before nullmoving.
6) It pays for me to xor in a zobrist HASHNULLMOVE value to avoid 'corrupting'
the hashtable with nullmove garbage scores.
7) Finally, your takeback no longer needs an explicit test for which color moved
last. Now you just need a good old "side ^= 1;"
That's about it...
Oh, when you do repetition detection, now you only need to compare hashkeys with
every 2nd ply instead of every ply. Hurrah!
Have fun!
Ross
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.