WAC test

[bob]

but since I was already excluding unsafe checks, excluding unsafe evasions didn't help me at all...

No, I don't think you have understood. For each check you can have multpile evasions at the next ply.

Say you are doing a safe check and at the child node you have 5 evasions to try. The idea is to try just a sub-set (say the first 2) and then discard the other 3.

This is the idea of Joona.

I understood the idea of "excluding unsafe evasions." My point was, it is likely, that in my case, since I don't include unsafe checks in the first place, following all evasions lets me prove a mate exists or does not. If you exclude unsafe evasions, you don't have that proof. Whether that is the real explanation or not I do not know. All I can say is that when I did this SEE() stuff last year, which included using SEE to avoid extending unsafe checks and allowing unsafe checks to actually be reduced via LMR, and then using it in the q-search for the same thing, it helped when I excluded unsafe checks in the q-search. But when I excluded unsafe evasions (SEE < 0) I didn't see any significant change on cluster testing. Yes, it would shrink the tree on some positions, like WAC 141 or some other nasty mate positions that produces a large q-search. But overall it did not help one bit, and I don't keep that which doesn't help, in general.

[zamar]

following all evasions lets me prove a mate exists or does not. If you exclude unsafe evasions, you don't have that proof.

If you order safe evasions before unsafe, you can prune unsafe evasions only if safe evasion returned non-mate score. This is the requirement for all move count based pruning in SF.

[hgm]

It doesn't matter if you fail low because you are checkmated or just because you are a centi-Pawn short of alpha...

How do you define "safe" evasion? I understand you use SEE, but on which square? Is this only for inter-positions and capturing the checker? Or do you also classify withdrawals as unsafe in case of a skewer? And if capturing the checker has a SEE of -2 (losing R vs B), and thus is a bad capture, but you are currently +3 above beta, would you count that as safe?

[Evert]

I know what happens. my engine prefer Ba2 followed by Nxe5, which is materially equal. it's normal given my stupid eval. So I need to work on the eval a little bit too

In the FEN string you posted Ba2 is listed as a correct answer.

[zamar]

It doesn't matter if you fail low because you are checkmated or just because you are a centi-Pawn short of alpha...

In a way you are right, but it shouldn't be forgotten that fail-soft has some advantages over fail-hard (if for example we need to do a research)

How do you define "safe" evasion? I understand you use SEE, but on which square? Is this only for inter-positions and capturing the checker?
Or do you also classify withdrawals as unsafe in case of a skewer?

In this case (if I can remember correctly) it was only for neg. SEE interpositions.

Of course there are always scenarios where for example neg. SEE interposition is the way out, but these are rear. And if one's position is so overwhelming (fx. beta+300cp), there are probably many more ways to win, so very very likely we find another winning line and the only negative thing was extra nodes we needed to examine.

[bob]

I am not sure that the PV condition makes a lot of sense.

You're probably right! Generally speaking introducing such path dependant conditions is theoretically unsound when used with a htable. So all these pv conditions should be tested, and unless they actually prove usefull, they should be avoided.
I've found however that extending recaptures by 1/2 ply at non PV nodes and 1 ply at PV nodes performs a little (but significantly) better in practice. Probably because:
- on the one hand you have a PV condition which doesn't make sense in theory
- on the other hand extending all recaptures by 1 ply is far too costly and explodes the search tree
- so in the end the result is an overall positive.
I'll try to remove each pv condition and test to see if it is actually useful.

For the record, the _only_ extension I currently use is "getting out of check". I tested a ton of alternatives a couple or three years back, and each time came back to the same conclusion. Each costs more than it returns. Some were very marginal losses, some gave zero Elo. The only beneficial extension I found and kept was the getting ouf of check extension.

On the other hand I have not tested 1/2 ply extension of recaptures, regardless of the PV-ness of the node.
I'll go ahead and test that, although my testing method is currently the 300 wac positions, which is very biaised towards sacrificial attacks, and doesn't represent "average" chess game positions.

Do _not_ tune search extensions on WAC. You will end up over-extending and play worse in real games. Because Wac is all about tactics and extensions.

[lucasart]

I am not sure that the PV condition makes a lot of sense.

You're probably right! Generally speaking introducing such path dependant conditions is theoretically unsound when used with a htable. So all these pv conditions should be tested, and unless they actually prove usefull, they should be avoided.
I've found however that extending recaptures by 1/2 ply at non PV nodes and 1 ply at PV nodes performs a little (but significantly) better in practice. Probably because:
- on the one hand you have a PV condition which doesn't make sense in theory
- on the other hand extending all recaptures by 1 ply is far too costly and explodes the search tree
- so in the end the result is an overall positive.
I'll try to remove each pv condition and test to see if it is actually useful.

For the record, the _only_ extension I currently use is "getting out of check". I tested a ton of alternatives a couple or three years back, and each time came back to the same conclusion. Each costs more than it returns. Some were very marginal losses, some gave zero Elo. The only beneficial extension I found and kept was the getting ouf of check extension.

On the other hand I have not tested 1/2 ply extension of recaptures, regardless of the PV-ness of the node.
I'll go ahead and test that, although my testing method is currently the 300 wac positions, which is very biaised towards sacrificial attacks, and doesn't represent "average" chess game positions.

Do _not_ tune search extensions on WAC. You will end up over-extending and play worse in real games. Because Wac is all about tactics and extensions.

Agreed. However it's not what I'm doing. I already have an idea of my extensions and using WAC to fix bugs. And fixing bugs only I achieved a decent WAC score, but WAC score is not a goal in itself.

Here are my search extensions, what do you think ? the half ply idea is from SF

Code: Select all

static int extension(bool is_pv, bool forced, bool in_check, bool is_recapture, bool is_7th_rank)
{
	if (forced)
		return OnePly;
	else if (in_check || is_recapture || is_7th_rank)
		return is_pv ? OnePly : OnePly/2;
	else
		return 0;
}

[bob]

I am not sure that the PV condition makes a lot of sense.

You're probably right! Generally speaking introducing such path dependant conditions is theoretically unsound when used with a htable. So all these pv conditions should be tested, and unless they actually prove usefull, they should be avoided.
I've found however that extending recaptures by 1/2 ply at non PV nodes and 1 ply at PV nodes performs a little (but significantly) better in practice. Probably because:
- on the one hand you have a PV condition which doesn't make sense in theory
- on the other hand extending all recaptures by 1 ply is far too costly and explodes the search tree
- so in the end the result is an overall positive.
I'll try to remove each pv condition and test to see if it is actually useful.

For the record, the _only_ extension I currently use is "getting out of check". I tested a ton of alternatives a couple or three years back, and each time came back to the same conclusion. Each costs more than it returns. Some were very marginal losses, some gave zero Elo. The only beneficial extension I found and kept was the getting ouf of check extension.

On the other hand I have not tested 1/2 ply extension of recaptures, regardless of the PV-ness of the node.
I'll go ahead and test that, although my testing method is currently the 300 wac positions, which is very biaised towards sacrificial attacks, and doesn't represent "average" chess game positions.

Do _not_ tune search extensions on WAC. You will end up over-extending and play worse in real games. Because Wac is all about tactics and extensions.

Agreed. However it's not what I'm doing. I already have an idea of my extensions and using WAC to fix bugs. And fixing bugs only I achieved a decent WAC score, but WAC score is not a goal in itself.

Here are my search extensions, what do you think ? the half ply idea is from SF

Code: Select all

static int extension(bool is_pv, bool forced, bool in_check, bool is_recapture, bool is_7th_rank)
{
	if (forced)
		return OnePly;
	else if (in_check || is_recapture || is_7th_rank)
		return is_pv ? OnePly : OnePly/2;
	else
		return 0;
}

I tried all sorts of variations on that idea, but discovered that the "check" extension was the only one that produced any positive gain in Crafty. I removed all others. I also found that 1.0 was the right extension for checks, and then got rid of fractional plies as well to simplify the code a bit...

[lucasart]

I tried all sorts of variations on that idea, but discovered that the "check" extension was the only one that produced any positive gain in Crafty. I removed all others. I also found that 1.0 was the right extension for checks, and then got rid of fractional plies as well to simplify the code a bit...

I am currently testing my extensions against only exenting by one ply forced moves and when we are in check.
I'm just running 10 games in 1'+1". I'm curious to see what happens

[bob]

I tried all sorts of variations on that idea, but discovered that the "check" extension was the only one that produced any positive gain in Crafty. I removed all others. I also found that 1.0 was the right extension for checks, and then got rid of fractional plies as well to simplify the code a bit...

I am currently testing my extensions against only exenting by one ply forced moves and when we are in check.
I'm just running 10 games in 1'+1". I'm curious to see what happens

How does "10 games" test _anything_? You can run that 10 times and get 10 different results...