Author: Stuart Cracraft
Date: 06:57:44 09/25/04
Go up one level in this thread
On September 25, 2004 at 06:35:57, martin fierz wrote: >well, as promised here are questions 4-7 of a zillion. perhaps i should also add >that the train ride from zurich to brissago takes about 3 hours and that i have >a centrino laptop, so i need some input :-) > >nullmove questions! > >1) do you save "don't nullmove" in your hashtable? if yes, how much does it help >you? isn't this a tinytiny improvement, since if you do nullmove, and it fails, >you have to research a much larger tree? >you would be saving "don't nullmove" if your nullmove fails, right? I don't save dont-nullmove in the hash table. My test for null move is fast. However, in thinking about your question, since I don't use the null move result to resize alpha since I am doing a null window search, I should say that if I don't cause a beta cutoff with nullmove, I *should* store dont-nullmove in the hash table to avoid having to do the null move, eh? >2) related: do you save matethreat in your hashtable? is this not another >tinytiny improvement? > I don't because mate threat never improved my program's play at all. It dropped the play result on Win-at-Chess by some. >3) some people advocate not to nullmove if the side to move has few (mostly 0, >perhaps also 1?) pieces. i realize that zugzwang is a problem for nullmove, but >is it a real problem as far as games go? isn't it possible that in pawn endgames >doing a nullmove would lead to a few embarassing losses, but help overall? I don't base it on pieces but on total remaining material. The standard value is a rook. So, if the side to move has a rook or more, I nullmove. My program does not maintain piecelists or locations. I scan the board every time for everything I need. I know people will cringe at that, but it's good enough for 250/300. When I go to bitboard for evaluation I will be maintaining piecelists in the 64-bit words. All the support is in there now, I just have to add the maintenance of those in makemove/unmakemove and then the use of them in the end-point evaluation and for things like null move, i.e. your pieces>0, etc. > >4) i never thought much about verified 0-move pruning. but a post i read last >week made me think: i always thought i could do the following: > >if(pieces > 0) > if nullmove-fails-high > return value; >if(pieces == 0) // do a verification search > if nullmove-fails-high > verify result with a normal search with reduced depth. > if verification-search-fails-high > return value; > >now there was this post saying that this won't work because you have to disable >the nullmove in your entire verification search. i don't understand why that >would be? can somebody explain? Verified null move didn't help me but that is because I am doing 1 second searches. I think it would help more for longer searches. > >cheers > martin
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.