TalkChess.com

lithander wrote: ↑Thu Mar 04, 2021 6:32 pm It may be a stupid question but do you count every node evaluated in QSearch or stop counting as soon as you reach depth 0 and start QSearch?

mvanthoor wrote: ↑Thu Mar 04, 2021 6:57 pm In my case, as I said, I count every node that is being searched; thus, every node that generates a move list.

(I could add a node increment where the evaluation is called as well, because that is also work... but I haven't yet.) Obviously I don't know what is done in Dumber, because I didn't check it yet

hgm wrote: ↑Thu Mar 04, 2021 7:43 pm One usually does count QS nodes. None of my engines actually does have a separate routine for QS. The most common way is to count every call to Search/QSearch. (So also those that return after very little work, such as a hash or stand-pat cutoff.) But if you have separate QS, that is called through an if(depth <= 0) early in Search, make sure you would not count it as two nodes.

hgm wrote: ↑Fri Mar 05, 2021 2:00 pm Indeed. But I assume that you can simply increment at the top of QSearch(), and place the increment of the counter in Search() just after the call to QSearch(). I don't suppose there are reasons to return from Search() before you have made this test.

hgm wrote: ↑Fri Mar 05, 2021 2:43 pm I would not worry about wether aborted nodes are counted in a 'time is up' situation. The purpose of the node count is mainly to judge the speed in a running search. I put that test always after the UnMake(), btw, because then it automatically prevents something is done with the returned (corrupted) score. Whether a few nodes more are searched after timeout by going deeper into the recursion is insignificant; I only test for timeout every thousand nodes or so anyway.

The repetition test is more of an issue. I usually do that in the parent, though. Even before MakeMove(). So for me they would never be counted. Draws by insufficient material and such would only occur in some end-games. I wouldn't worry much whether these were counted or not either.

hgm wrote: ↑Fri Mar 05, 2021 3:04 pm Not that many positions will be repetitions, so it will definitely not make a significant difference. But doing it in the child definitely would make unneeded moves just to unmake them immediately afterwards, and that must always be slower. There is zero upside.

In Joker I even do the TT probe in the parent; I also don't need anything but the hash key for that, and if I get a TT cut-off, why waste time on make/unmake? This happens much more frequently than repetitions. Downside is that I need to pass the hash move to the child. Futility pruning of course does the stand-pat on behalf of the child (but based on an estimated evaluation, so it cannot do it when it is a close call, and the full evaluation would need the move to be made first).

for m in move_loop {
	// do move loop stuff
	
	let evaluation = if !draw() {
		-alpha_beta(d -1, -b, -a)
	} else {
		DRAW
	}
}

if draw() {
	return DRAW;
}

for m in move_loop {
	// do move loop things
	let evaluation = -alpha_beta(d -1 , -b, -a);
}