PVS & Embla
Moderators: hgm, Rebel, chrisw
-
- Posts: 7220
- Joined: Mon May 27, 2013 10:31 am
Re: PVS & Embla
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.
-
- Posts: 6995
- Joined: Thu Aug 18, 2011 12:04 pm
Re: PVS & Embla
LMR is independent of whatever search type.Henk wrote: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.
-
- Posts: 931
- Joined: Tue Mar 09, 2010 3:46 pm
- Location: New York
- Full name: Álvaro Begué (RuyDos)
Re: PVS & Embla
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?Rebel wrote:LMR is independent of whatever search type.Henk wrote: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.
Thanks!
EDIT: Hmmm... I think this is the first time I remember agreeing with Henk on anything. I hope this is an isolated incident.
-
- Posts: 6995
- Joined: Thu Aug 18, 2011 12:04 pm
Re: PVS & Embla
Then you haven't understood the logic behind LMR.
-
- Posts: 2929
- Joined: Sat Jan 22, 2011 12:42 am
- Location: NL
Re: PVS & Embla
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.AlvaroBegue wrote: 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.
It's basically the inverse of PV-extensions.
Re: PVS & Embla
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%
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)
-
- Posts: 2929
- Joined: Sat Jan 22, 2011 12:42 am
- Location: NL
Re: PVS & Embla
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).flok wrote: bounds is
if (score > alpha)
instead of
if (score > alpha && score < beta)
-
- Posts: 433
- Joined: Fri Dec 16, 2016 11:04 am
- Location: France
- Full name: Richard Delorme
Re: PVS & Embla
Try this way:
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.
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 (score > alpha && score < beta)
score = -search(sd, &m, depthLeft - 1 + extension, co, -beta, -alpha, newHash, curBestSiblings, false, &tempPv);
}
Richard Delorme