LMR other conditions

[mjlef]

Bob mentions giving up on using history margins to make LMR decisions. I too see varying results and am less certain if they help or not. Some conditions that have helped in some testing are not tio reduce checks, if a passed pawn is moving, captures or promotions (right now I LMR non-queen promotions, but this is untested), killers...

One idea I have started experimenting with was not reducing moves of specific pieces. In a sample test match, it was best not to reduce moves of pawns (probably this could be improved by not reducing losing moves of pawns unless they did something to king safety, but I have not run a test yet). Next is effecitveness was not reducing knight moves. Bishops queens and kings came out near the bottom of the list with rook moves in the middle, about the same as not using piece type.

My speculations: pawn moves change lots of things, and maybe should not be reduced. Plus in most positions there are not a lot of them anyway. Maybe some refinements: reduce if the SEE sasy a non capture pawn move is lost, reduce if the pawn is not advancing much (perhaps do not reduce pawns to the 5th and 6th... 7th I do not reduce since it will be a passed pawn).

For knights, a knight move changes many attacks. All the from knight square attacks vanish and all new to square attacks are created. A knight move is probably going to be a lot more turbulant than a bishop move (with a bishop, only the cross direction changes attacks).

If anyone does some tests, let me know what you find.

Mark

[hgm]

I did not reduce Pawn moves in microMax purely for technical reasons, but it turned out to work quite well. Thus I tried the same think in Joker, but I got mixed results. Most of the LMR testing I do in Joker seems to give very mixed results, what seems better at one time control is often worse at another. So now I am back to only exempting passer pushes and captures from reduction. It is also not clear if it is a good idea to reduce bad captures.

[mjlef]

I also cannot decide if it is good to reduce "bad" captures. Although I got an initial great gain from this, more games have narrowed the improvement to the point that I just am not sure. I envy Bob's cluster. It would be nice to have many thousands of games to test each idea.

[hgm]

Well, if you need many thousands of games to test an idea, the improvement it might give is rather marginal at best...

My theory was that captures, even bad ones, have a higher probability to come up with something good, as the opponent has not much choice in the reply: he has to recapture, or you made progress already. My philosophy for LMR is not to reduce moves that are somehow forcing for the opponent, and don't give him time to solve existing trouble. Because in that case you might cash in on that existing trouble later (and need the depth to see it), in a way that perhaps is improved by the interjected move.

But of course, if the interjected moves burn too much, it becomes increasingly unlikely that you will be able to earn it back later. So perhaps the optimum is to limit the non-reduction of bad captures to those not losing too much, such as the exchange or a light piece.

[davehore]

I have tried a few similar ideas:

Avoid reducing central (D & E file) pawn advances - seemed to work ok.

Avoid reducing non-losing piece moves into the centre (say C4-F8 from white's point of view) - Could not get it to work.

Avoid reducing any move near the opponent king - Could not get this to work either.

Dave

[cwb]

A basic question might also be which history information to use - shall it be driven by good or bad moves?

I currently use cutoff moves and moves that raise alpha, and one table for each depth in the tree, which worked better than a global one when i tested it.

But maybe doing it like Ed and using fail lows and using large history values instead is better. This has the advantage of not giving false positives for rarely tried moves/ new moves, but I haven't tried it.

[bob]

I did not reduce Pawn moves in microMax purely for technical reasons, but it turned out to work quite well. Thus I tried the same think in Joker, but I got mixed results. Most of the LMR testing I do in Joker seems to give very mixed results, what seems better at one time control is often worse at another. So now I am back to only exempting passer pushes and captures from reduction. It is also not clear if it is a good idea to reduce bad captures.

I think not reducing pawn moves is relatively safe, because once the pawn moves, it can't "undo itself". Pieces, on the other hand, can bounce back and forth between two squares and allowing that just wastes lots of time.

I think even piece moves can be restricted. I've been playing with this sporadically, including things like centralizing doesn't get reduced, retreating does, etc... Similar ideas for attacking the opponent's king-field.

[Michael Sherwin]

Untill I added LMR there were no history tables in RomiChess as they were useless for move ordering (compared to what was being used). But, using tables based on just fs, ts was not good. So I tried side, fs, ts which was better. However, even better is what I use now, which is, fig (WP, WN, ..., BK), fs, ts. This last way seems to reduce to an acceptable level the randomness inherent in history tables. Also dividing any slot in half when it reaches a count of 200 was helpful. That way the last 100 entries will always have a larger effect.

Now I have added a second history table of fig, ts that is used to help tune the eval after each iteration. A small elo boost, but, a nice change to the playing style.

I am trying the following as well. Divide the fig, ts entry for the current root move to get a small 0-4 point bonus then do the same for the responce moves to each root move. Put these values into two variables called whiteEvalBonus and blackEvalBonus. Then in the eval the line, score += (whiteEvalBonus - blackEvalBonus). Also results seem to indicate a small gain.

And last, a search extention based on the fig, ts table if the entry is over a certain threshold. Extends those lines that the eval thinks is helped by the fig, ts table.

So, is any of this really any good? I do not know, but, it may be premature to scrap the idea of the history table at this time.

[bob]

the thing I have never liked about history tables, is that they contain _global_ data. That is, a fail high way over _there_ in the tree, influences the move ordering or reductions way over _here_ even though the two parts of the tree are so far apart they have little in common. Killer moves suffer from the same thing, except that we only keep two and they get overwritten over _here_ quickly which loses the killers from way over _there_ that are not applicable here.

Unfortunately history data applies everywhere, and in these 2B node trees, the numbers get to where they mean very little anywhere in the tree, they are such an average...

[frankp]

I still find the history table reduces the tree size for a fixed endpoint - but maybe random numbers would......