lmr in PV

[lkaufman]

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?

[kranium]

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?

for IvanHoe LMR at PV node code
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

[kranium]

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...

[kranium]

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

[lkaufman]

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.

[Michael Sherwin]

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.

It is not about ELO. It is about long and pretty displayed pv lines. ELO may only be +3 for LMR in the pv.

[mcostalba]

Why is it that most recent strong programs do LMR in PV with success

Does Komodo do LMR in PV ?

Don said here he has experimenting a lot with LMR so probably he knows better then most what works and what doesn't.

[Mincho Georgiev]

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.

It is not about ELO. It is about long and pretty displayed pv lines. ELO may only be +3 for LMR in the 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.

[lkaufman]

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?

[bob]

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 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.

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..."