multi pv

[hgm]

This is weird. A 17-ply search from the initial position, imited to searching only e2 must logically be the same (except for the sign, if the engine reports own POV rather than white POV) as a 16-ply search after playing e2. How else could the engine implement an e2-only search other than playing e2, running a search, and taking e2 back? It must search identicaly the same tree, node for node.

When searching multiple moves (as in a normal, unrestricted search) you coud have such effects, because then the search from the original position would, between iterations, also do low-failing searches for all other moves, which could affect hash content.

Side-to-move bonus is normally applied in the leaves, so that should be the same too. Contempt should ony play a role when one of the lines indeed leads to a repetition draw, that would be avoided when thinking for the other side.

Asymmetric evaluation could explain it. But it would be very strange to use that during analysis.

[govert]

. How else could the engine implement an e2-only search other than playing e2

By pruning all the other legal moves at the root?

[hgm]

So how would pruning moves at the root affect the search of e2? It will still make e2, search, and unmake it, and the pruned moves will not affect hash, killer, history or any other tables.

[govert]

So how would pruning moves at the root affect the search of e2? It will still make e2, search, and unmake it, and the pruned moves will not affect hash, killer, history or any other tables.

Well, I'm not an engine writer, so I'm probably out of my depth, and I definitely do not speak the lingo, but let me try to explain how I read your text and how I'm thinking:

A: Make the move, then search:
Responses to e5 will be in the root(ply 0) during the search

B: Reduce the root to only e5, search
Responses to e5 will technically be at ply 1 during the search.


I would assume that there might be code in the search what would reduce the tree differently depending on the current ply level. ("Reduce more at higher plies" or something)

Maybe move ordering also is different depending on whether you are at the root or not.

The result of this would be that A) and B) would search different trees.

You're more than welcome to point out the error in my understanding if there is one.

[hgm]

I don't think an-one would reduce differently at different ply levels. Usually you take that decision based on distance to the leaves.

But you have a point: he might not be doing exactly the same thing in the root as he does in an interior tree-node. (E.g. have different move ordering.) This would lead to such inconsistent behavior.

IMO that would be a mistake in the design of the engine. If your usual root action is better, you should do the same thing in the first PV node, as you are in exacty the same situation. If it is worse, you should not even have done it in the root...

[Martin Brown]

An engine in single PV mode typically uses 30-40% of the time on that PV and the remaining time for all other moves. If you let it calulate 4 PVs, each of those would take about that time. That means the time needed to reach the same depth for all will approximately double.

Broadly speaking this seems to be true. perhaps even a bit on the optimisitic side 3 lines of multipv seems to be ~2x slower here. I tried Shredder10 with a test position 39 moves possible.

NPV vs Times to reach ply 16 were:
1 5m
2 8m
3 12m
4 15m
8 40m
16 57m
32 34m

The first 6 PV lines were all plausible continuations the next dozen were weak and the last few were crazy material losing moves. I was a bit surprised that displaying the dross moves in multiPV mode appeared to speed things up again. No moves resolved to mate in N.

So requesting 4 PVs is equivalent to reducing the search time by 2, which reduces strength by 70 Elo.

That is just very general; if you want t know exact numbers for a specific engines, just try it out. Run in singe-PV and four-PV mode, and look how much time it takes to reach a certain depth.

What would be useful is to be able to specify a window on lines to be followed in multiPV mode based on a window offset from the PV score. For example within 50cp. The advantage of seeing the top 3 or 4 lines is that humans can see ideas in the nominally weaker displayed lines.

[hgm]

Well, this is how multi-PV mode works in Fairy-Max. Rather than specifying a number of lines, you specify a margin (in cP, in the Engine-Settings menu), and for every move that falls with the marging from the best, it will print an exact score and PV.