PVS & Embla

[Henk]

Huh. And what were you using before PVS. How can you use LMR if you don't use PVS. Or maybe you were using negascout or you were not using LMR.

[Rebel]

Huh. And what were you using before PVS. How can you use LMR if you don't use PVS. Or maybe you were using negascout or you were not using LMR.

LMR is independent of whatever search type.

[AlvaroBegue]

Huh. And what were you using before PVS. How can you use LMR if you don't use PVS. Or maybe you were using negascout or you were not using LMR.

LMR is independent of whatever search type.

To me LMR means that you use a reduced depth for the null-window searches of PVS, and then full depth for the re-exploration, if needed. I am not sure what LMR means in a program that doesn't use PVS. Could you post some pseudo-code?

Thanks!

EDIT: Hmmm... I think this is the first time I remember agreeing with Henk on anything. I hope this is an isolated incident.

[Rebel]

Then you haven't understood the logic behind LMR.

[Evert]

To me LMR means that you use a reduced depth for the null-window searches of PVS, and then full depth for the re-exploration, if needed. I am not sure what LMR means in a program that doesn't use PVS.

You reduce "late" moves, since it's increasingly likely that this node is an ALL node so none of the moves are going to raise alpha. Pretty much what it says on the tin.
It's basically the inverse of PV-extensions.

[flok]

I'm using 4.9.2, 6.3 and 6.4.

[flok]

no
It's just that I have not updated the trunk on github.

[flok]

Code: Select all

Rank Name       Elo    +    - games score oppo. draws 
   1 dorpsgek    71    4    4 97005   61%   -12   17% 
   2 trunk       24    5    5 16220   44%    71   19% 
   3 nmopt       -1    5    5 16112   41%    71   18% 
   4 nolmr      -22    5    5 16178   38%    71   16% 
   5 pvs2b2     -23    5    5 16198   38%    71   17% 
   6 lmrpvs     -24    5    5 16162   38%    71   17% 
   7 bounds     -25    5    5 16135   38%    71   16%

dorpsgek is a reference program not written by me

trunk is the starting point. it does lmr.

nmopt is trunk with the null move optimalization suggested in this thread

nolmr is trunk with lmr disabled.

pvs2b2 is trunk without lmr and with pvs

lmrpvs is trunk with lmr AND pvs

bounds is
if (score > alpha)
instead of
if (score > alpha && score < beta)

[Evert]

bounds is
if (score > alpha)
instead of
if (score > alpha && score < beta)

Note that this only ever affects PV nodes (other nodes you search with a null-window, so score>alpha implies score>=beta). All it does is stabilise the search when you get an in-window result. It should not have a major impact (and for fail-hard, it has no impact at all).

[abulmo2]

Try this way:

Code: Select all

				if (bSearchPV) {
					score = -search(sd, &m, depthLeft - 1 + extension, co, -beta, -alpha, newHash, curBestSiblings, false, &tempPv);
					bSearchPV = false;
				} else {
					score = -search(sd, &m, depthLeft - 1 + extension, co, -alpha - 1, -alpha, newHash, curBestSiblings, false, &tempPv);
					if &#40;score > alpha && score < beta&#41;
						score = -search&#40;sd, &m, depthLeft - 1 + extension, co, -beta, -alpha, newHash, curBestSiblings, false, &tempPv&#41;;
 				&#125;

On your code, bSearchPv is only set to false when score > alpha, I think you should turn it off after the first move has been searched.