LMR questions

[lucasart]

Thought I should share some of my experimental results:
* PV condition: I have found that not reducing PV nodeas and reducing non PV nodes is harmful. This was to be expected, since any PV condition is theoretically unsound. However, I'm amazed to see how many programs do thias. Even Fruit ! So I reduce PV and non PV nodes exactly the same way
* My extensions are:
- forced move (1 legal move)
- in check
- pawn moving to the 7th rank with a non negative SEE (1)
* A move is reduced if:
- it is not extended
- it's not a killer move
- it's not a bad capture or a bad quiet move. bad capture = capture or promotion with < 0 SEE. bad quiet move = not(capt or prom) and (negative history score, or null history and negative SEE)
- the move number is > X
* testing suggest that the best value is X = 1 !

I'd be curious to know, what everyone thinks of that, and whether your experience concurs with my empirical results

(1) once I've finished, I'll try moving this condition to a non reduction rather than an extension.

matches my cluster testing perfectly. Only thing different for me is I extend checks and nothing else...

Glad we agree

Next step is to test:
(1) remove the 7th rank pawn erxtension, and make it a non reduction rather than an extension.

I may find that this extension is usefull, although it may not be in Crafty, since my eval is still very basic, especially in the endgame (where it's just PSQ and siome basic passed pawn stuff)

Also I still think that extending a forced move can only be a good thing: it doesn't increase the branching factor, and it just "makes sense". Do you not do this in Crafty ?

[JVMerlino]

Thought I should share some of my experimental results:
* PV condition: I have found that not reducing PV nodeas and reducing non PV nodes is harmful. This was to be expected, since any PV condition is theoretically unsound. However, I'm amazed to see how many programs do thias. Even Fruit ! So I reduce PV and non PV nodes exactly the same way
* My extensions are:
- forced move (1 legal move)
- in check
- pawn moving to the 7th rank with a non negative SEE (1)
* A move is reduced if:
- it is not extended
- it's not a killer move
- it's not a bad capture or a bad quiet move. bad capture = capture or promotion with < 0 SEE. bad quiet move = not(capt or prom) and (negative history score, or null history and negative SEE)
- the move number is > X
* testing suggest that the best value is X = 1 !

I'd be curious to know, what everyone thinks of that, and whether your experience concurs with my empirical results

(1) once I've finished, I'll try moving this condition to a non reduction rather than an extension.

How much do you reduce? Do you use partial reductions combined with some maximum reduction? Or just reduce by some value if any of the conditions above are met?

jm

[lucasart]

Thought I should share some of my experimental results:
* PV condition: I have found that not reducing PV nodeas and reducing non PV nodes is harmful. This was to be expected, since any PV condition is theoretically unsound. However, I'm amazed to see how many programs do thias. Even Fruit ! So I reduce PV and non PV nodes exactly the same way
* My extensions are:
- forced move (1 legal move)
- in check
- pawn moving to the 7th rank with a non negative SEE (1)
* A move is reduced if:
- it is not extended
- it's not a killer move
- it's not a bad capture or a bad quiet move. bad capture = capture or promotion with < 0 SEE. bad quiet move = not(capt or prom) and (negative history score, or null history and negative SEE)
- the move number is > X
* testing suggest that the best value is X = 1 !

I'd be curious to know, what everyone thinks of that, and whether your experience concurs with my empirical results

(1) once I've finished, I'll try moving this condition to a non reduction rather than an extension.

How much do you reduce? Do you use partial reductions combined with some maximum reduction? Or just reduce by some value if any of the conditions above are met?

jm

all my reduction and extensions are always by one play. i don't do half or quarter depth.

[JVMerlino]

Thought I should share some of my experimental results:
* PV condition: I have found that not reducing PV nodeas and reducing non PV nodes is harmful. This was to be expected, since any PV condition is theoretically unsound. However, I'm amazed to see how many programs do thias. Even Fruit ! So I reduce PV and non PV nodes exactly the same way
* My extensions are:
- forced move (1 legal move)
- in check
- pawn moving to the 7th rank with a non negative SEE (1)
* A move is reduced if:
- it is not extended
- it's not a killer move
- it's not a bad capture or a bad quiet move. bad capture = capture or promotion with < 0 SEE. bad quiet move = not(capt or prom) and (negative history score, or null history and negative SEE)
- the move number is > X
* testing suggest that the best value is X = 1 !

I'd be curious to know, what everyone thinks of that, and whether your experience concurs with my empirical results

(1) once I've finished, I'll try moving this condition to a non reduction rather than an extension.

How much do you reduce? Do you use partial reductions combined with some maximum reduction? Or just reduce by some value if any of the conditions above are met?

jm

all my reduction and extensions are always by one play. i don't do half or quarter depth.

Ok. Nothing more aggressive then. Thanks very much!

jm

[lucasart]

matches my cluster testing perfectly. Only thing different for me is I extend checks and nothing else...

Have you ever tried these in Crafty:

1/ extending pawn moves to the 7-th rank, *with* a non-negative SEE ?
2/ extending pawn moves to the 7-th rank, *with* a non-negative SEE *and* when the side to move has no queen ?

My testing seems to be saying (although it's not finished yet) that:

1/ is as good as not doing the extension: neither better nor worse. this is probably because:
- as a positive of course you don't overlook some promotion threats
- as a negative you generally make the tree larger, especially in the middle game where these promoting lines are unlikely to be forceful

2/ haven't tested that yet. I can imagine that it:
- keeps the positive of 1/ almost entirely
- mitigates the negative, as it only does the extension when it's likely to be relevant, ie in the "endgame"

[bob]

Thought I should share some of my experimental results:
* PV condition: I have found that not reducing PV nodeas and reducing non PV nodes is harmful. This was to be expected, since any PV condition is theoretically unsound. However, I'm amazed to see how many programs do thias. Even Fruit ! So I reduce PV and non PV nodes exactly the same way
* My extensions are:
- forced move (1 legal move)
- in check
- pawn moving to the 7th rank with a non negative SEE (1)
* A move is reduced if:
- it is not extended
- it's not a killer move
- it's not a bad capture or a bad quiet move. bad capture = capture or promotion with < 0 SEE. bad quiet move = not(capt or prom) and (negative history score, or null history and negative SEE)
- the move number is > X
* testing suggest that the best value is X = 1 !

I'd be curious to know, what everyone thinks of that, and whether your experience concurs with my empirical results

(1) once I've finished, I'll try moving this condition to a non reduction rather than an extension.

matches my cluster testing perfectly. Only thing different for me is I extend checks and nothing else...

Glad we agree

Next step is to test:
(1) remove the 7th rank pawn erxtension, and make it a non reduction rather than an extension.

I may find that this extension is usefull, although it may not be in Crafty, since my eval is still very basic, especially in the endgame (where it's just PSQ and siome basic passed pawn stuff)

Also I still think that extending a forced move can only be a good thing: it doesn't increase the branching factor, and it just "makes sense". Do you not do this in Crafty ?

I extend ONLY checking moves, nothing else. BTW ANY extension increases the effective branching factor, because you force some branches of the tree to go one ply deeper, which makes the tree larger...

Often, what "makes sense" doesn't pass the actual testing / validation step. Care to guess why I stopped extending passed pawn pushes, recaptures, and one-legal-reply-to-check moves? Because I removed them, one at a time, and watched my testing Elo climb each and every time I took one out. When I took out the check extension, however, the Elo went the other direction and dropped about 20 Elo or so...

[bob]

matches my cluster testing perfectly. Only thing different for me is I extend checks and nothing else...

Have you ever tried these in Crafty:

1/ extending pawn moves to the 7-th rank, *with* a non-negative SEE ?
2/ extending pawn moves to the 7-th rank, *with* a non-negative SEE *and* when the side to move has no queen ?

And many others. In fact, today, I only extend checks with SEE >= 0. if SEE <= 0 I will actually REDUCE a check. I've tried just about every passed pawn extension one can think of. We do have some code to avoid reducing certain safe passed pawn pushes to an advanced rank, but nada for extensions of them.

My testing seems to be saying (although it's not finished yet) that:

1/ is as good as not doing the extension: neither better nor worse. this is probably because:
- as a positive of course you don't overlook some promotion threats
- as a negative you generally make the tree larger, especially in the middle game where these promoting lines are unlikely to be forceful

2/ haven't tested that yet. I can imagine that it:
- keeps the positive of 1/ almost entirely
- mitigates the negative, as it only does the extension when it's likely to be relevant, ie in the "endgame"

[lucasart]

In fact, today, I only extend checks with SEE >= 0. if SEE <= 0 I will actually REDUCE a check.

ah now that's interesting. my check extension is not based on the move being a check, but the current position being in check. I figured that iI was growing the tree a lot by not reducing some "stupid" replies to a check, but I wasn't sure how to decide a priori which could be stupid or not.
Deciding the extension on the checking move itself allows this SEE condition. That's definitely a good idea, that I shall try.

thank you!

[ZirconiumX]

Being a noob - this is just something I noticed.

In fact, today, I only extend checks with SEE >= 0. if SEE <= 0 I will actually REDUCE a check.

If you have a move with SEE = 0 you are effectively leaving a node alone (depth 5 + 1 - 1 = 5).

Why don't you just check whether SEE > 0 or < 0?

Just a thought.

BTW my LMR conditions are based on Tord's article on LMR.

Matthew:out

[Evert]

If you have a move with SEE = 0 you are effectively leaving a node alone (depth 5 + 1 - 1 = 5).

Why don't you just check whether SEE > 0 or < 0?

I'm guessing Bob meant he only extends checks with SEE>=0 and reduces ones with SEE<0.