Positional gain in LazyEval

[Sentinel]

A question inspired by BB report where Rybka uses it, and Ippo don't. So why use positional gain in LazyEval conditions?
Depending on implementation of LazyEval, not more than 20% of speed can be saved even when majority of all evals are lazy. That's 20 elo max. When any kind of reasonable margin (like min. 100 centipawns) is used, potential speed gain drops to under 10%. So why bother to make some calculations with positional gain, which takes half of those 10%, and have a lot of errors (especially in the beginning of the game, where I presume Rybka has statistically tuned values, instead of Ippos zeros) when actual eval is larger than lazy + positional gain, which would additionally hurt performance?
I really don't see how the balance can be positive in using positional gain in lazy eval conditions.

[BB+]

So why use positional gain in LazyEval conditions?

Maybe I am mis-stating this, as upon looking more closely I don't think Rybka actually uses posgain in lazy conditions per se. Rybka has more than one type of posgain (something like "time-lagged" posgain, it looks like, involving an interpolation with the current poseval and the table value, in weights 1:3), and updates these on lazy moves. [I have never been able to determine how these secondary types of posgain ever actually get used (other than being updated consistently), so I tend to be a bit cavalier in my thoughts/words about them].

The modifications to the lazy condition in Rybka seem to be just whether the previous eval (in the move stack) was also lazy, and whether the move is a capture. The modification for each is rather small (10-15cp), and I don't think that they matter much overall. OTOH, when a move is lazy, you still have to guess/compute a "poseval" for it (for future use), and seems to be done via one of these other posgain-like devices. So the effect of secondary posgain stuff on laziness is only in the prediction of the poseval of the lazy move.

[Sentinel]

The modifications to the lazy condition in Rybka seem to be just whether the previous eval (in the move stack) was also lazy, and whether the move is a capture. The modification for each is rather small (10-15cp), and I don't think that they matter much overall. OTOH, when a move is lazy, you still have to guess/compute a "poseval" for it (for future use), and seems to be done via one of these other posgain-like devices. So the effect of secondary posgain stuff on laziness is only in the prediction of the poseval of the lazy move.

Ippo have 16 by default and does it only for previous lazy (not for capture). It's logical, the estimation of poseval becomes more and more unreliable the more guesses you make, so you have to compensate for it.
However, I played with numbers there, and potential gain/loss is unmeasurable (it's under any realistic error margin, certainly less than 3 elo).

[BB+]

Ippo have 16 by default and does it only for previous lazy (not for capture).

My recollection was that it was 16 per move in IPPOLIT, and so with 5 straight lazy evals, it would be 80. Rybka only uses the direct previous. As you say, it makes no difference on strength. In fact, make the lazy margins rather extreme, say 25 and 50 instead of 150 and 300 in IvanHoe, and while it might reach a little larger depth, I don't think the ELO difference is much either way.

[mcostalba]

IMHO lazy eval is a "bad thing" (tm)

It is inelegant, complicates the code flow, handicaps the TT data flow (you cannot save lazy value in TT) and overall it is far from clear is a good idea in ELO terms. Actually in SF we have removed it and we are happy with this.

To my eyes it seems more of a big hack then a natural and good looking feature.

[Edmund]

IMHO lazy eval is a "bad thing" (tm)

It is inelegant, complicates the code flow, handicaps the TT data flow (you cannot save lazy value in TT) and overall it is far from clear is a good idea in ELO terms. Actually in SF we have removed it and we are happy with this.

To my eyes it seems more of a big hack then a natural and good looking feature.

Lazy eval is about bounds, so if you are a queen down there is no need to calculate things like king safety, mobility etc. In the TT you can very well also save this bound.

[mcostalba]

Lazy eval is about bounds, so if you are a queen down there is no need to calculate things like king safety, mobility etc. In the TT you can very well also save this bound.

Therer are much better ways to deal with positions where you are a queen down. The reason why lazy eval is bad it is very well described by your post: makes the responsability of the search and of the evaluation blurring and intermixed, while instead it is important, also as a design guideline to have a clear idea of what is the search and what is the evaluation and do keep things separated as long as possible.

Regarding your second point, did you tried (read "seriously tested") saving lazy eval in TT against don't do it, or you are expressing your personal opinion ?

BTW I did

[Edmund]

Regarding your second point, did you tried (read "seriously tested") saving lazy eval in TT against don't do it, or you are expressing your personal opinion ?

BTW I did

In Glass there is no distinction between Lazy eval and normal eval scores regarding the TT. But I must admit I never tested that. An important aspect also is, whether the TT is used in the Quies search. In Glass it is not, which means that only leaf-nodes can benefit from the exact scores returned from the TT, which in the best case saves one additional call of evaluation. I don't see much potential for improvement there. Anyway I am always open for enlightenment - if I want to test this change, how many games do I have to schedule for this, iow what is the expected elo-gain.

regards,
Edmund

[Pawel Koziol]

For the record, LE in Glass includes

- material and pcsq, incrementally updated
- weak pawn eval (retrieved from pawn hash, but hashing doesn't gain much)
- material imbalance eval
- passed pawn eval (which is much more basic than in Stockfish)

outside we have mobility, King safety and some positional patterns.

The tests we have done regarding lazy eval in Glass include

- a couple of attempts at lowering the margin (anything lower than 300cp failed for me, I have never tested increasing it)
- adding material imbalance eval there (for a small gain)
- I decided to spare a couple of hours for testing Glass without LE today, and the beginning is disastrous for the non-LE version, but we shall see

[Sentinel]

- I decided to spare a couple of hours for testing Glass without LE today, and the beginning is disastrous for the non-LE version, but we shall see

That can only be if your full eval is really heavy, so you lose more than 20% of speed. The thing is you don't loose any strength, just the speed.
What's the nps difference btw (between versions w and w/o LE)?