About UCI multipv

[Kempelen]

Hello,

I am having problem implementing multipv. Maybe my english is not good to undestand this, but can someone explain me what it is in bold:

* multipv
this for the multi pv mode.
for the best move/pv add "multipv 1" in the string when you send the pv.
in k-best mode always send all k variants in k strings together.

Also If I find multipv 3 better than 2 for current depth, must I sort all pv by score and send them again, or can I send them as they are found... must I change the multipv number for a variant at any place?

if not, does the gui usually sort them?

Can someone put me an example please?

Thanks in advance
Fermin

[hgm]

if not, does the gui usually sort them?

Well, this obviously depends on the GUI. WinBoard will sort them by score, within each depth.

[mcostalba]

Also If I find multipv 3 better than 2 for current depth, must I sort all pv by score and send them again, or can I send them as they are found

From your question I'd guess you still have to implement multipv otherwise you probably had found that the sorting is intrinsic to multipv implementation because when you find a new, better line, you have to replace the worst multipv with the new line, so a sorting seems mandatory anyway.

[hgm]

Indeed, isn't it awful? A WinBoard engine can simply send the PVs as it finds them. No reason to store any old ones to resend them, and thus no reason to sort anything to see which one you should throw away! The GUI takes care of all that.

[Ferdy]

Hello,

I am having problem implementing multipv. Maybe my english is not good to undestand this, but can someone explain me what it is in bold:

* multipv
this for the multi pv mode.
for the best move/pv add "multipv 1" in the string when you send the pv.
in k-best mode always send all k variants in k strings together.

Also If I find multipv 3 better than 2 for current depth, must I sort all pv by score and send them again, or can I send them as they are found... must I change the multipv number for a variant at any place?

if not, does the gui usually sort them?

Can someone put me an example please?

Thanks in advance
Fermin

* multipv
this for the multi pv mode.
for the best move/pv add "multipv 1" in the string when you send the pv.
in k-best mode always send all k variants in k strings together.

My understanding is, say k is 4 then send like
multipv 1 depth 1 score cp 4 pv e2e4
multipv 2 depth 1 score cp 5 pv g1f3
multipv 3 depth 1 score cp 6 pv d2d4
multipv 4 depth 1 score cp 1 pv b1c3
Together would mean that you have to send this successively.

The way I do it is something like,
1. Say we are at depth 1, search a root move, if I get a move save the move, and score.
2. Search the root again but this time ignore the move I saved in step 1.
If you get a move save it again.
3. Search the root again but this time ignore the moves saved in steps 1 and 2. Once you get the move save it again.
4. Do the same above when searching the 4th best move.
5. Once you completed the requested k best move, you are now ready to send your multi pv. You may sort the pv lines based on score before sending.
I tried Fritz 13, and you can send the pv even without sorting, Fritz 13 will sort it for you. Arena 3 will not sort.
6. Next increase the depth to 2 and do the typical steps in 1 to 5.
7. Next at depth 3 and so on.

In my case I sort the saved pv based on the score before sending.

[hgm]

Most engines don't wait until they have a complete set of k moves at a certain depth, though, before sending. They send as soon as they have found a single new move. And when they have only n<k moves of this depth at that point, they will then send the k-n best other moves of the previous depth with it.

In Fairy-Max (which is WB) multi-PV is controlled by a score margin rather than a number. (After all, what interest would a second move be when it blunders away a Queen, because there wasonly one way to recapture it?) When a move scores > alpha in the root, I increase alpha not to the score, but to score-MARGIN, emit the PV., and continue searching the other moves as always. That is really all. Guaranteed to find all moves that score within MARGIN from the best. (And sometimes even more, when the PV of the previous iteration is overturned.)

[Dave_N]

I didn't consider sorting MPV's based on values until I read this.

to command a UCI engine to use multi-pv the instruction is sent like this

setoption name MultiPv value k

where k is the number of PV's you want to use. The best way to test that is to test the program in the console.

I think a very interesting option for unsorted PV's would be to have Multi-PV mode with different parameter settings ... I would search over

Standard
Aggressive
Defensive
Materialistic

for example...
I don't know if this is possible to implement in Stockfish with a minor modification ?

[Don]

Indeed, isn't it awful? A WinBoard engine can simply send the PVs as it finds them. No reason to store any old ones to resend them, and thus no reason to sort anything to see which one you should throw away! The GUI takes care of all that.

HG,

You never miss an opportunity for a sales pitch for winboard - but it is really getting old. We cannot have a discussion about anything without having to listen to you take another jab at UCI and promote winboard. Enough already.

Don

[Steve Maughan]

...You never miss an opportunity for a sales pitch for winboard - but it is really getting old. We cannot have a discussion about anything without having to listen to you take another jab at UCI and promote winboard. Enough already.

+1

[hgm]

You never miss an opportunity for a sales pitch for winboard - but it is really getting old. We cannot have a discussion about anything without having to listen to you take another jab at UCI and promote winboard. Enough already.

One should never tire of educating people. That you know this, doesn't mean others do. New people visit the forum every week. I did not repy to a post of you...

Besides, WinBoard bashing through ridiculous fabrications is still a frequently exercised hobby in this forum. Why shouldn't I balance that a bit by saying things that are true for a change? As the saying goes: offending is usually the best defense.

But I think you missed the major point, however: someone claims something that deserved correcting. Sorting is not 'intrinsic to multipv implementation'. It is an artifact of the clumsy way multi-PV is handled in UCI.

Of course I understand that this burst the bubble of those who imagine that everything in UCI is much simpler, and like to keep up that myth. Too bad for them.