Is SEE really worthwhile?

[bob]

I recall a thread some time back where the relative merits of MVV/LVA and SEE move-scoring was debated without a definitive conclusion being reached. I tried both schemes, and MVV/LVA seemed to work better, though I know others have reached the opposite conclusion.

Are you asking if sorting with see score is worth it or if using see to find out if a capture is good or not is worth it ?
Knowing that a 'bad' capture like QxP is indeed winning is priceless and this capture must be searched first.

The other place SEE is often used is in qsearch, when determining whether to skip searching a particular sequence of captures, presumably to help avoid qsearch explosions. However in these cases, it seems obvious you could end up missing a sacrifice leading ultimately to a won game (e.g. unstoppable pawn). This is because the end-position of the skipped capture sequence is not evaluated.

There is no such thing as winning sacrifice in qsearch because you do not search quiet move so you can not refute anything in qsearch (and we can not make threats like pawn/knight fork, etc).

When I add SEE into my qsearch I only get a small speed improvement, maybe 5-10%. If SEE was worth an extra ply of search at any reasonable time control, it would be a different matter, but as it doesn't seem to, I can't really see the practical benefit!

See() uses more cpu, does your node count is reduced by only 10% ?
I'll try to find real numbers, this number is very suspect.

HJ.

10% sounds right if you do not fully use SEE. If you use it to discard losing captures, the result is closer to a 55% overall tree size reduction, this has been tested both over lots of test positions and lots of test games...

What is % of Q nodes over the total? it should be quite high to remove a proportion of them and end up with a tree 55% smaller. All that reduction will come from Q-nodes not visited, and I doubt SEE cutoffs remove them all. Do SEE cutoffs really remove most of the Q-nodes?

Miguel

55% seems to much,

In crafty, 70% of nodes are Q nodes.

And that ignores the ones that are tossed out by material pruning using SEE...

[bob]

Does anyone use SEE to eliminate bad captures from the main search? I haven't heard of that, and it seems very risky, but so is null move, whose risk no one seems to mind...

Too dangerous. You might try reducing their depth, but tossing them out will cause you to overlook all sacrifices...

[mambofish]

I'm wondering if one can use SEE not only to prune, but also to cutoff? eg:

Code: Select all

int SEE_MARGIN = 200;
if (depth == 0 && !in_check && (mv < MASK_CAPTURE)) {
	int see_score = SEE.evaluateExchanges(mv);
	if (see_score - SEE_MARGIN < 0) continue;
	if (see_score + SEE_MARGIN > beta) return see_score;
}

Given a reasonable enough margin, is this safe?

[Dann Corbit]

I'm wondering if one can use SEE not only to prune, but also to cutoff? eg:

Code: Select all

int SEE_MARGIN = 200;
if (depth == 0 && !in_check && (mv < MASK_CAPTURE)) {
	int see_score = SEE.evaluateExchanges(mv);
	if (see_score - SEE_MARGIN < 0) continue;
	if (see_score + SEE_MARGIN > beta) return see_score;
}

Given a reasonable enough margin, is this safe?

Don't forget:
the best move isn't always a capture.

[bob]

I'm wondering if one can use SEE not only to prune, but also to cutoff? eg:

Code: Select all

int SEE_MARGIN = 200;
if (depth == 0 && !in_check && (mv < MASK_CAPTURE)) {
	int see_score = SEE.evaluateExchanges(mv);
	if (see_score - SEE_MARGIN < 0) continue;
	if (see_score + SEE_MARGIN > beta) return see_score;
}

Given a reasonable enough margin, is this safe?

In the qsearch, my margin is zero. If the SEE score is < 0, I ignore the move. If it is >= 0, the move is included and the score is used to sort the captures before searching the first one...

I think even exchanges are still important to search because of overloaded pieces that are doing two things at once, and the first even capture / recapture exposes a hanging piece that needs to be detected...

[mambofish]

Don't forget:
The best move isn't always a capture

This is true, but in qsearch, unless the player is in check, the only moves I admit are captures. There are no non-capture moves to prefer

[mambofish]

In the qsearch, my margin is zero. If the SEE score is < 0, I ignore the move. If it is >= 0, the move is included and the score is used to sort the captures before searching the first one...

I haven't got round to using SEE to scoring the qsearch movelist - still using MVV/LVA.

I generate and score moves at the same time when creating the movelist for a given ply. But if I changed the scoring mechanism for depth = 0 captures to be the SEE evaluation as you suggest, then I assume I could do something like this in qsearch:

Code: Select all

while (mv = movelist.next()) {
   if (!incheck && mv.isCapture() && mv.score() < 0)
      continue;
}

Is this the sort of thing you mean?

[bob]

In the qsearch, my margin is zero. If the SEE score is < 0, I ignore the move. If it is >= 0, the move is included and the score is used to sort the captures before searching the first one...

I haven't got round to using SEE to scoring the qsearch movelist - still using MVV/LVA.

I generate and score moves at the same time when creating the movelist for a given ply. But if I changed the scoring mechanism for depth = 0 captures to be the SEE evaluation as you suggest, then I assume I could do something like this in qsearch:

Code: Select all

while (mv = movelist.next()) {
   if (!incheck && mv.isCapture() && mv.score() < 0)
      continue;
}

Is this the sort of thing you mean?

Except I don't do checks. But yes. And you can avoid SEE in obvious cases like RxQ. That wins material no matter what so you don't need to do a SEE analysis on it...