Flat Evaluation Function, Which Searching Strategy?

[LiquidNitrogenOverclocker]

Many of the "intelligent" evaluation functions are guided by a minimal window PVS. The idea being, scores that are equal to the "best move" can likewise be passed over as the search is iterating.

But what if your evaluation function was very flat (say material only)? You would not want to use a minimal window PVS because the first move generated by your move list that did not drop material would most likely become a part of your principal variation.

You might see a PV line such as 1. a4 a5 2. b3 b6 3. c4 c5 etc.

If you did have such a flat evaluation function, which searching strategy would be recommended in its place?

[MattieShoes]

I don't understand why PVS would be bad there. If you have a material-only eval, then isn't that exactly what you want? You'd get the same results with normal Alpha-Beta or even full width.

[Bo Persson]

Many of the "intelligent" evaluation functions are guided by a minimal window PVS. The idea being, scores that are equal to the "best move" can likewise be passed over as the search is iterating.

But what if your evaluation function was very flat (say material only)? You would not want to use a minimal window PVS because the first move generated by your move list that did not drop material would most likely become a part of your principal variation.

You might see a PV line such as 1. a4 a5 2. b3 b6 3. c4 c5 etc.

If you did have such a flat evaluation function, which searching strategy would be recommended in its place?

Is the positions have the same score they are equally good, right?

You could change your move generator to generate "interesting" moves first.

Next you will HAVE to add some positional scores, if you see that material equivalence isn't all that counts.

[jwes]

Many of the "intelligent" evaluation functions are guided by a minimal window PVS. The idea being, scores that are equal to the "best move" can likewise be passed over as the search is iterating.

But what if your evaluation function was very flat (say material only)? You would not want to use a minimal window PVS because the first move generated by your move list that did not drop material would most likely become a part of your principal variation.

You might see a PV line such as 1. a4 a5 2. b3 b6 3. c4 c5 etc.

If you did have such a flat evaluation function, which searching strategy would be recommended in its place?

You are saying that you want chess knowledge that is not in the evaluation to guide the search. Why not just add this knowledge to the evaluation?

[metax]

PVS does not change the PV if a new move is equal to the first - but neither does alpha-beta. So if your move ordering is not 'intelligent' you'd always get PVs like 1.a4 a5 etc with a material-only evaluation.

[LiquidNitrogenOverclocker]

PVS does not change the PV if a new move is equal to the first - but neither does alpha-beta. So if your move ordering is not 'intelligent' you'd always get PVs like 1.a4 a5 etc with a material-only evaluation.

The problem is, the PVS does not explore the nodes. If using a primitive Alpha Beta only, it will explore other nodes and the node count is much higher. But Alpha Beta explores "too many" nodes, and PVS far too few.

Eventually, the Alpha Beta will return a decent PV, but the time-to-depth is terrible. The PVS does almost the opposite, doing a very deep search with very few nodes at all, but returning a ridiculous line of play.

That's why I thought maybe there was something better "in the middle".

[jwes]

PVS does not change the PV if a new move is equal to the first - but neither does alpha-beta. So if your move ordering is not 'intelligent' you'd always get PVs like 1.a4 a5 etc with a material-only evaluation.

The problem is, the PVS does not explore the nodes. If using a primitive Alpha Beta only, it will explore other nodes and the node count is much higher. But Alpha Beta explores "too many" nodes, and PVS far too few.

Eventually, the Alpha Beta will return a decent PV, but the time-to-depth is terrible. The PVS does almost the opposite, doing a very deep search with very few nodes at all, but returning a ridiculous line of play.

That's why I thought maybe there was something better "in the middle".

It sounds very much like you have a bug in your PVS implementation.

[LiquidNitrogenOverclocker]

I think maybe the search needs to progress a bit before turning on the PVS. The PVS works best with good move ordering, and there just isn't any at the start of the search.

I think maybe the next step is just to copy/paste some of the alpha-beta C code that was written by somebody and make sure I am not doing something wrong. Trying to do a search trace by hand is very frustrating.