Can principal variation search be worth no Elo?

[R. Tomasi]

That's just how it is with chess programming. Lots of ideas that sound really good, don't work, and stuff that works, makes you scratch your head over why it actually does.

To me that is what makes chess programming such fun. You simply can't just copy paste ideas or concepts, it always has to be fitted to your specific engine and what works for others might not immediatly (or at all) work for you.

[algerbrex]

That makes sense, the more I'm thinking about what you said. Unfortunately, right now, reality seems to be trumping theory and I'm getting horrendous time to depth results and the node count explodes. So I need to think a little bit about what I'm doing differently in Blunder, since as you said, most of the time I should be getting close to the PV the first couple of tries.

That's just how it is with chess programming. Lots of ideas that sound really good, don't work, and stuff that works, makes you scratch your head over why it actually does.

I think when I first added PVS it didn't make a huge difference. But then I wasn't really testing each change properly (maybe sometimes I played fifty or a hundred games, but nothing serious). So it could be that initially PVS was not a measurable improvement, but then I slowly developed my engine to be better while depending on the PVS, so now I cannot remove PVS without losing Elo. I don't know why that is so, but unfortunately I neither have a plan nor the time to thoroughly test if PVS is truly necessary.

Search explosions when the PV changes is actually an issue for Nalwald (my engine). As long as the PV doesn't change, the search is really fast, but as soon as the current PV is refuted, the search can take 10 times or more. This doesn't necessarily prevent an engine to be quite good, but it is something worth thinking about before adding (aggressive or less aggressive) PVS.

Thanks, Jost, I'm starting to realize that's much of what chess programming really is all about.

I just know it's going to bug me not understanding why PVS isn't an Elo gain, but I suppose for now I'll keep it in and just keep working, as it clearly does improve the search statistics and it's not an Elo loss.

I'll keep the aggressiveness of the PVS in mind too, as I've noticed that my engine is also very sensitive to changes in the PV while searching.

[algerbrex]

That's just how it is with chess programming. Lots of ideas that sound really good, don't work, and stuff that works, makes you scratch your head over why it actually does.

To me that is what makes chess programming such fun. You simply can't just copy paste ideas or concepts, it always has to be fitted to your specific engine and what works for others might not immediatly (or at all) work for you.

I suppose that is true. It'd be pretty boring if everyone cloned or copy'd and paste'd.

It does become pretty frustrating sometimes though

[mvanthoor]

Maybe it's a combination of factors? In the above position, Rustic's current development version searches 60 million nodes at depth 9. (Including PVS and transposition table.) Your engine searches only 7.4 mln (without PVS) and 5.5 mln (with PVS) nodes. What other enhancements do you have at this point?

It is expensive for PVS, having to re-search; the transposition table mitigates this expense. Could it be that the TT is not working correctly, making your PVS re-search more expensive than it needs to be? Seeing that your time to depth drops from just over 3 seconds down to 2.2 for depth 9, it's unlikely; but with a time to depth speedup of almost 30%, the engine -should- have been measurably stronger.

[R. Tomasi]

Concerning agressiveness of PVS: I always considered PVS to be a feature that can either be implemented or not. If there is a way to do it to a higher degree or not (as in more agressive or not), I would love to know how to do that.

[Henk]

I only use PVS to implement LMR which can't deal with quiet moves. But chess is about statistics. Giving only stress to introverted thinkers who want to understand why.

[j.t.]

Concerning aggressiveness of PVS: I always considered PVS to be a feature that can either be implemented or not. If there is a way to do it to a higher degree or not (as in more aggressive or not), I would love to know how to do that.

For example, you could do a null window whenever you have an alpha value (which is not -infinity). That's what I mean with "very aggressive". But you also could only do null window searches whenever you apply some depth reduction (LMR or futility reduction, etc.) but never when you're searching with full depth. So that would be less aggressive. Or maybe you don't do null window if the hash table says that the current move is the previous best move (and maybe only if it also says that the node is not an all node).
I'm not sure if "aggressiveness" is the right word to describe this, but that's what I used .

[Chan Rasjid]

One optimization of alpha-beta that I've never quite been able to get working has been principal variation search. I understand the concept and how to implement it, but I've never quite been able to get an Elo gain from it.

By all other signs, it seems to be working well. I'm getting a pretty nice reduction in nodes searched and time to depth. For example for the following position:
...
It seems I either have a nasty bug hiding somewhere in my program, or I'm unaware of certain cases where PVS isn't a win.

I have the following PVS data:

Code: Select all

zero(all/nodes 54.0%, pvs/zero 3.2%, resrc/zero (1916, 15.9%)

In a typical search for a move, 54% of all nodes(full/qsearch) are searched with a null window(width = 1). The 3.2% is when the inherited (alpha, beta) has width greater then 1; only 15.9% of 1916 nodes need a research - almost insignificant since we search about 1 Mnps with an i5.

If your analysis shows PVS getting the same bestmove in a shorter time of search, it cannot be that there is no elo gain; the logic means your engine can only be stronger - other bugs aside.

[Chan Rasjid]

Concerning agressiveness of PVS: I always considered PVS to be a feature that can either be implemented or not. If there is a way to do it to a higher degree or not (as in more agressive or not), I would love to know how to do that.

I doubt there is any way to do PVS with greater or lesser aggresiveness. I think what have been suggested here covered all aspects of PVS search.

[edit] Someone mentioned doing a null window for reduced depth LMR; this may be considered "common sense" as we expect the move to fail low; this is what I do in my engine.

[j.t.]

I doubt there is any way to do PVS with greater or lesser aggressiveness. I think what have been suggested here covered all aspects of PVS search.

[edit] Someone mentioned doing a null window for reduced depth LMR; this may be considered "common sense" as we expect the move to fail low; this is what I do in my engine.

My point was not that you should do null window searches for LMR. My point was that you can vary the conditions for when you use null window searches. Using null windows can cause issues, as the result may not be as accurate as if you are using a full window. So in some cases it might make sense to search a move with a full window, even if we think that it is more likely that it will fail low.