lmr in PV
Moderators: hgm, Rebel, chrisw
-
- Posts: 5960
- Joined: Sun Jan 10, 2010 6:15 am
- Location: Maryland USA
lmr in PV
Why is it that most recent strong programs do LMR in PV with success (Stockfish even having increased the reductions in the new version), but Rybka and all the programs said to be derived from Robolito do not do LMR in PV? I'm sure it doesn't work in those programs or they would be doing it, but what is there about them that makes LMR in PV unsuitable? Perhaps one of the authors of these Robo-related programs can say why he does not use LMR in PV when everyone else finds it helpful?
-
- Posts: 2129
- Joined: Thu May 29, 2008 10:43 am
Re: lmr in PV
for IvanHoe LMR at PV node codelkaufman wrote:Why is it that most recent strong programs do LMR in PV with success (Stockfish even having increased the reductions in the new version), but Rybka and all the programs said to be derived from Robolito do not do LMR in PV? I'm sure it doesn't work in those programs or they would be doing it, but what is there about them that makes LMR in PV unsuitable? Perhaps one of the authors of these Robo-related programs can say why he does not use LMR in PV when everyone else finds it helpful?
see any version of IvanHoe pv_node.c
near the end of function
int MyPV (typePOS* POSITION, int ALPHA, int BETA, int depth, int check, type_zog_node *parent)
EXTEND = 0;
if (check)
EXTEND = 1;
if (see && (POS1->cp || move_is_check || PassedPawnPush(to, FOURTH_RANK(to))))
EXTEND = 1;
#if 0
if ((((int)(POS1->OppKdanger)) - ((int)((POS1 - 1)->OppKdanger))) > 5)
EXTEND = 1;
if ((((int)(POS1->OppKdanger)) - ((int)((POS1 - 1)->OppKdanger))) > 10)
EXTEND = 2;
#endif
if (PassedPawnPush(to, SIXTH_RANK(to)))
EXTEND = 2;
if (see && POS1->cp && POS1->cp != EnumOppP)
EXTEND = 2;
if (POS1->cp && (POS1->material & 0xff) == 0 && POS1->cp != EnumOppP)
EXTEND = 6; /* HACK */
if (NextMove->trans_move != move)
SINGULAR = 0;
if (!EXTEND && cnt >= 3 && NextMove->phase == ORDINARY_MOVES && MARGIN < 100 && depth >= 10)
LMR = BSR(1 + cnt) - 1;
else
LMR = 0;
new_depth = depth - 2 + MAX(EXTEND, SINGULAR) - LMR;
see win32bits.h or win64bits.h for the bit scan reverse function definition
-
- Posts: 2129
- Joined: Thu May 29, 2008 10:43 am
Re: lmr in PV
the example above is from 999948...
correction: on further inspection, i have indeed found an earlier version (999963) that does not use it...there may be more.
I'll take a look at the change history...
correction: on further inspection, i have indeed found an earlier version (999963) that does not use it...there may be more.
I'll take a look at the change history...
-
- Posts: 2129
- Joined: Thu May 29, 2008 10:43 am
Re: lmr in PV
Nope... nothing mentioned concerning LMR in the change log
Certainly doesn't seem to be helping...the last IvanHoe seems to be weaker than previous releases...
(although I have not tested like some have)
they seem to be more interested in features (comrades hash, robbobases, etc.) and claim they are not "ELO hunting"
re: Strongest Ivanhoe Today ?
RobertoPescatore Aug 21, 2010 1:10 am
"I do not infer why you have care to which IvanHoe is as strongest. The point of us, is like Igor says, more for Revolution than just computer chess. If we just toned IvanHoe super in ELO, you can betcha that the Capitalists would just copy the right parts into theirs, or new teams would emerge but Capitalist Controllers like Chess Base would then buy them out. So we need to make multiple others strong too and then they will be surrounded with no escape valve. You can't fix a battle by aiming at a slender."
if you post the question to the authors on wikispaces, they will likely answer, and you get it from the horses mouth.
Norm
Certainly doesn't seem to be helping...the last IvanHoe seems to be weaker than previous releases...
(although I have not tested like some have)
they seem to be more interested in features (comrades hash, robbobases, etc.) and claim they are not "ELO hunting"
re: Strongest Ivanhoe Today ?
RobertoPescatore Aug 21, 2010 1:10 am
"I do not infer why you have care to which IvanHoe is as strongest. The point of us, is like Igor says, more for Revolution than just computer chess. If we just toned IvanHoe super in ELO, you can betcha that the Capitalists would just copy the right parts into theirs, or new teams would emerge but Capitalist Controllers like Chess Base would then buy them out. So we need to make multiple others strong too and then they will be surrounded with no escape valve. You can't fix a battle by aiming at a slender."
if you post the question to the authors on wikispaces, they will likely answer, and you get it from the horses mouth.
Norm
-
- Posts: 5960
- Joined: Sun Jan 10, 2010 6:15 am
- Location: Maryland USA
Re: lmr in PV
Thanks. I based my conclusion only on Rybka, Robo, Ippo, and Fire. I didn't realize that Ivanhoe was that different from Fire for example. Still, I wonder why the others all rejected LMR in PV when it is standard in all the unrelated top programs.
-
- Posts: 3196
- Joined: Fri May 26, 2006 3:00 am
- Location: WY, USA
- Full name: Michael Sherwin
Re: lmr in PV
It is not about ELO. It is about long and pretty displayed pv lines. ELO may only be +3 for LMR in the pv.lkaufman wrote:Thanks. I based my conclusion only on Rybka, Robo, Ippo, and Fire. I didn't realize that Ivanhoe was that different from Fire for example. Still, I wonder why the others all rejected LMR in PV when it is standard in all the unrelated top programs.
If you are on a sidewalk and the covid goes beep beep
Just step aside or you might have a bit of heat
Covid covid runs through the town all day
Can the people ever change their ways
Sherwin the covid's after you
Sherwin if it catches you you're through
Just step aside or you might have a bit of heat
Covid covid runs through the town all day
Can the people ever change their ways
Sherwin the covid's after you
Sherwin if it catches you you're through
-
- Posts: 2684
- Joined: Sat Jun 14, 2008 9:17 pm
Re: lmr in PV
Does Komodo do LMR in PV ?lkaufman wrote:Why is it that most recent strong programs do LMR in PV with success
Don said here he has experimenting a lot with LMR so probably he knows better then most what works and what doesn't.
-
- Posts: 454
- Joined: Sat Apr 04, 2009 6:44 pm
- Location: Bulgaria
Re: lmr in PV
Following that logic, you may remove TT cutoffs at pv nodes as well, which is another -3 ELO pts down at least to me.Michael Sherwin wrote:It is not about ELO. It is about long and pretty displayed pv lines. ELO may only be +3 for LMR in the pv.lkaufman wrote:Thanks. I based my conclusion only on Rybka, Robo, Ippo, and Fire. I didn't realize that Ivanhoe was that different from Fire for example. Still, I wonder why the others all rejected LMR in PV when it is standard in all the unrelated top programs.
-
- Posts: 5960
- Joined: Sun Jan 10, 2010 6:15 am
- Location: Maryland USA
Re: lmr in PV
Yes, we do lmr in PV in Komodo. Yes, we know what works in Komodo, the question is what there is about Rybka, Robo and related programs that makes them reject LMR in PV while SF, Komodo and many others use it?
-
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL
Re: lmr in PV
I have tried these kinds of tests exhaustively. I have, from the get-go, done LMR everywhere. IMHO, the idea of not doing reductions when alpha != beta - 1 is simply flawed. Those are not the only positions where you can find your PV. Moves fail high regularly, yet they started with alpha = beta - 1 and had to fail high over the reductions.lkaufman wrote:Why is it that most recent strong programs do LMR in PV with success (Stockfish even having increased the reductions in the new version), but Rybka and all the programs said to be derived from Robolito do not do LMR in PV? I'm sure it doesn't work in those programs or they would be doing it, but what is there about them that makes LMR in PV unsuitable? Perhaps one of the authors of these Robo-related programs can say why he does not use LMR in PV when everyone else finds it helpful?
I believe that the basic reduction idea is all about putting faith in your move ordering, believing that the probability of a fail-high drops as you work your way thru the move list. If that is true, it is true whether alpha == beta - 1 or not. I dislike the idea of an asymmetric search that will be unstable at times. If you fail high when you reduce, and then back up and come back to this position later with alpha != beta -1 and you don't reduce, you can get a different result. Those fail-high/fail-low cases are not good for performance. Particularly for a parallel search.
Some extend differently on PV/non-PV nodes, reduce differently, perhaps even order differently. I see no theoretical justification, however, after watching tree-search research for 40+ years. I suspect it is more a case of "he did it and I am copying his idea without giving it any thought or test time..."