Author: Mike Adams
Date: 05:04:37 09/20/00
Go up one level in this thread
Thanks for the input.
I will definitely add that pulsar should not call null move while in check.
Pulsar has that information because i recently added a check extension to help
it deal with checks. It had been having problems in that area.
As far as the double calls of nullmove goes pulsar does have that
information correct null is passed in the nullmove call at 0 and in the regular
call at 1. I just cut that part out of the code without thinking though it might
have been clearer if i left it in.
As far as enpassant goes i think you are correct it wont matter. It should
be getting 0 values for enpassant but i need to rewrite my enpassant slightly.
when i first wrote the program i used an array for all enpassant possiblitities
generated in the move generator. There could be up to 8. What happened was the
next level saw mulitple enpassant possiblities intead of one or none and i was
getting all sorts of illegal moves. I corrected it to only one value passed but
its still in the array when i really only need an int. So pulsar is basicly
doing int myenpassant[64]; then adding to it when necesary no more than one
move and in the null move call its an empty array. Other than being sloppy
programming is that a problem. I'm guessing not because if it was i would be
getting illegal moves. Even if the default values in array are not 0 they
probably arent the same as the values neccesary to be their to try an enpassant
capture.
I'm less concerned with tactical weaknesses in null move, though maybe i
should be and with the acception of check which i can easily change, as to why
when i call nullmove in search though i get beta cutoffs, quite a few, qsearch
calls tend to increase relative to calls to search. This balooning of qsearch
takes away most of the gains of nullmove so basicly my program searches the same
number of nodes with and without nullmove. Sometimes it actually searches more
often i think it searches only slightly less. I don't understand this since the
qsearch call is identical to the one in search. The only variables relative to
qsearch are the 4 i listed and i've checked them all 5 times. those being that
i get alpha, beta, depth=0 important because qsearch checks every capture at
depth=0 but not <0, and side so it know who is to move. And i think if i got
alpha beta or side wrong i'd have much more serious problems than little gain
the program would probably collaspe.
I want to go over how i count calls to search and qsearch tommorow to make
sure i'm counting correctly and i will post fen positions with how many calls
pulsar takes for certain postions at depth 4 and depth 5 with and without
nullmove so people can have some data to look at. Maybe its the positions i'm
choosing i dont know really what i should expect but i've heard nullmove for
many programs enables them to search another depth and would like this to happen
though right now its not even close.
This page took 0.03 seconds to execute
Last modified: Thu, 07 Jul 11 08:48:38 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.