That seems wrong. You REALLY want to check the time for 16383 out of 16384 positions?Kempelen wrote:I have found an issue when not counting nodes at the top of the search.
Usually people put a time-control at the top of the search like:
Code: Select all
#define CONTROL 16383 search { if (nodes & CONTROL) { see if time reached..... } ...
16383 = 3FFF (16). If you and that with nodes, you get a non-zero value almost every time...
Maybe you meant !(nodes & CONTROL)???
if you increment the nodes variable at makemove, it could happen that if you do a prunning this check could not happen at that particular situation, so you will have to wait for the next 16383 iteration to do the time-check, an again, if that particular node is a prunning without visiting a real tree node, again the time check is not executed. Same in a row could happen...., more for aggresive prunning engines.
This could seen as no important, as 16383 node loop run quick fast, but it could be of importance in very fast games (and of course the value for CONTROL is important also)
I dont know if make-prunning-unmoke node counter people take this into account and how they deal with it, or if they consider this as no important.