Polyglot and Multi-PV

[H.G.Muller]

Current Polyglots do not work conveniently in multi-variation mode with WinBoard. They do send thinking output with lower depth than they previously sent, which is a signal to WinBoard to clear te Engine-Output window. And what is worse, this is always information that was already sent before: there are many duplicate Thinking-Output lines in the multi-PV output, leading to a totally cluttered Engine-Output display when no clearing would take place.

This is not the way how multi-variation mode should work in WB protocol. The engine should send every line it wants displayed only once, and in order of increasing depth. WinBoard will take care of sorting the lines by score within one depth.

So what I need is a Polyglot that removes duplicate output lines, and lines of lower depth than the maximum depth given. I guess this should not be so difficult to implement. In UCI protocol the lines always come in bunches, numbered by the multipv value. In any case Polyglot should immediately discard all lines that have a depth lower than the maximum depth received in the current search. Of the other lines it receives, it should push score and PV on a stack. Every incoming line of higher depth than the current maximum first clears this stack before being pushed on it. Finally every incoming line can be compared against all these stored lines, and if it is a duplicate, it can be discarded. Only if it survives this test, it will be relayed to WinBoard (and pushed on the stack).

Can this patch be included in the Polyglot development lines? I would be willing to write the patch myself, but I lost touch a bit with Polyglot development lately, and am not sure what would be the best version to patch.

[F. Bluemers]

I have tested for this in the past(lower depths send to winboard were indeed a problem),I just ran multipv again with rybka 2n2 and fruit 231 and it works fine:

Code: Select all

502697.216 Adapter->Xboard: 0 +12 201 1934206
502697.216 Adapter->Xboard: 13 +12 201 1934206 d4 Nf6 Nc3 e6 Nf3 Nc6 e3 d5 Bd3 Bd6 Nb5 O-O Nxd6 Qxd6   1%
502697.216 Engine->Adapter: info multipv 2 depth 13 score cp 12 time 2231 nodes 2186437 pv b1c3 g8f6 d2d4 e7e6 g1f3 b8c6 e2e3 d7d5 f1d3 f8d6 c3b5 e8g8 b5d6 d8d6
502697.216 Adapter->Xboard: 13 +12 223 2186437 Nc3 Nf6 d4 e6 Nf3 Nc6 e3 d5 Bd3 Bd6 Nb5 O-O Nxd6 Qxd6   1%
502697.216 Engine->Adapter: info multipv 3 depth 12 score cp 12 time 1419 nodes 1245905 pv g1f3 b8c6 b1c3 g8f6 d2d4 d7d5 e2e3 e7e6 f1d3 f8d6 c3b5 e8g8 b5d6 d8d6
502697.216 Engine->Adapter: info multipv 4 depth 12 score cp 12 time 1497 nodes 1343168 pv e2e3 b8c6 b1c3 g8f6 g1f3 e7e6 d2d4 d7d5 f1d3 f8d6 c3b5 e8g8 b5d6 d8d6
502697.216 Engine->Adapter: info currmove g1f3 currmovenumber 3
502697.325 Engine->Adapter: info multipv 1 depth 13 score cp 12 time 2012 nodes 1934206 pv d2d4 g8f6 b1c3 e7e6 g1f3 b8c6 e2e3 d7d5 f1d3 f8d6 c3b5 e8g8 b5d6 d8d6
502697.325 Adapter->Xboard: 0 +12 201 1934206
502697.325 Adapter->Xboard: 13 +12 201 1934206 d4 Nf6 Nc3 e6 Nf3 Nc6 e3 d5 Bd3 Bd6 Nb5 O-O Nxd6 Qxd6   1%
502697.325 Engine->Adapter: info multipv 2 depth 13 score cp 12 time 2231 nodes 2186437 pv b1c3 g8f6 d2d4 e7e6 g1f3 b8c6 e2e3 d7d5 f1d3 f8d6 c3b5 e8g8 b5d6 d8d6
502697.325 Adapter->Xboard: 13 +12 223 2186437 Nc3 Nf6 d4 e6 Nf3 Nc6 e3 d5 Bd3 Bd6 Nb5 O-O Nxd6 Qxd6   1%
502697.325 Engine->Adapter: info multipv 3 depth 13 score cp 12 time 2340 nodes 2311979 pv g1f3 b8c6 b1c3 g8f6 d2d4 d7d5 e2e3 e7e6 f1d3 f8d6 c3b5 e8g8 b5d6 d8d6
502697.325 Adapter->Xboard: 13 +12 234 2311979 Nf3 Nc6 Nc3 Nf6 d4 d5 e3 e6 Bd3 Bd6 Nb5 O-O Nxd6 Qxd6   1%
502697.325 Engine->Adapter: info multipv 4 depth 12 score cp 12 time 1497 nodes 1343168 pv e2e3 b8c6 b1c3 g8f6 g1f3 e7e6 d2d4 d7d5 f1d3 f8d6 c3b5 e8g8 b5d6 d8d6
502697.325 Engine->Adapter: info currmove e2e3 currmovenumber 4
502697.481 Engine->Adapter: info multipv 1 depth 13 score cp 12 time 2012 nodes 1934206 pv d2d4 g8f6 b1c3 e7e6 g1f3 b8c6 e2e3 d7d5 f1d3 f8d6 c3b5 e8g8 b5d6 d8d6
502697.481 Adapter->Xboard: 0 +12 201 1934206
502697.481 Adapter->Xboard: 13 +12 201 1934206 d4 Nf6 Nc3 e6 Nf3 Nc6 e3 d5 Bd3 Bd6 Nb5 O-O Nxd6 Qxd6   1%
502697.481 Engine->Adapter: info multipv 2 depth 13 score cp 12 time 2231 nodes 2186437 pv b1c3 g8f6 d2d4 e7e6 g1f3 b8c6 e2e3 d7d5 f1d3 f8d6 c3b5 e8g8 b5d6 d8d6
502697.481 Adapter->Xboard: 13 +12 223 2186437 Nc3 Nf6 d4 e6 Nf3 Nc6 e3 d5 Bd3 Bd6 Nb5 O-O Nxd6 Qxd6   1%
502697.481 Engine->Adapter: info multipv 3 depth 13 score cp 12 time 2340 nodes 2311979 pv g1f3 b8c6 b1c3 g8f6 d2d4 d7d5 e2e3 e7e6 f1d3 f8d6 c3b5 e8g8 b5d6 d8d6
502697.481 Adapter->Xboard: 13 +12 234 2311979 Nf3 Nc6 Nc3 Nf6 d4 d5 e3 e6 Bd3 Bd6 Nb5 O-O Nxd6 Qxd6   1%
502697.496 Engine->Adapter: info multipv 4 depth 13 score cp 12 time 2496 nodes 2500287 pv e2e3 b8c6 b1c3 g8f6 g1f3 e7e6 d2d4 d7d5 f1d3 f8d6 c3b5 e8g8 b5d6 d8d6
502697.496 Adapter->Xboard: 13 +12 250 2500287 e3 Nc6 Nc3 Nf6 Nf3 e6 d4 d5 Bd3 Bd6 Nb5 O-O Nxd6 Qxd6   1%
502697.496 Engine->Adapter: info currmove d2d3 currmovenumber 5
502697.496 Engine->Adapter: info currmove e2e4 currmovenumber 6
502697.543 Engine->Adapter: info currmove b1a3 currmovenumber 7
502697.543 Engine->Adapter: info currmove g1h3 currmovenumber 8
502697.559 Engine->Adapter: info currmove b2b3 currmovenumber 9
502697.559 Engine->Adapter: info currmove b2b4 currmovenumber 10
502697.574 Engine->Adapter: info currmove g2g3 currmovenumber 11
502697.574 Engine->Adapter: info currmove g2g4 currmovenumber 12
502697.590 Engine->Adapter: info currmove a2a4 currmovenumber 13
502697.590 Engine->Adapter: info currmove h2h4 currmovenumber 14
502697.590 Engine->Adapter: info currmove c2c4 currmovenumber 15
502697.590 Engine->Adapter: info currmove c2c3 currmovenumber 16
502697.590 Engine->Adapter: info currmove a2a3 currmovenumber 17
502697.590 Engine->Adapter: info currmove f2f4 currmovenumber 18
502697.590 Engine->Adapter: info currmove h2h3 currmovenumber 19
502697.606 Engine->Adapter: info currmove f2f3 currmovenumber 20
502697.606 Engine->Adapter: info depth 13 time 2621 nodes 2636381 nps 1005868 tbhits 0
502697.606 Engine->Adapter: info depth 14
502697.606 Engine->Adapter: info currmove d2d4 currmovenumber 1
502698.027 Engine->Adapter: info time 3042 nodes 3100000 nps 1019066 tbhits 0 cpuload 998
502698.027 Engine->Adapter: info hashfull 16
502698.448 Engine->Adapter: info multipv 1 depth 14 score cp 16 time 3463 nodes 3597195 pv d2d4 g8f6 b1c3 e7e6 g1f3 b8c6 e2e3 d7d5 f1d3 f8d6 c3b5 f6e4 b5d6 c7d6 e1g1 e8g8 d3e4 d5e4
502698.448 Adapter->Xboard: 0 +16 346 3597195
502698.448 Adapter->Xboard: 14 +16 346 3597195 d4 Nf6 Nc3 e6 Nf3 Nc6 e3 d5 Bd3 Bd6 Nb5 Ne4 Nxd6+ cxd6 O-O O-O Bxe4 dxe4   2%
502698.448 Engine->Adapter: info multipv 2 depth 13 score cp 12 time 2231 nodes 2186437 pv b1c3 g8f6 d2d4 e7e6 g1f3 b8c6 e2e3 d7d5 f1d3 f8d6 c3b5 e8g8 b5d6 d8d6
502698.448 Engine->Adapter: info multipv 3 depth 13 score cp 12 time 2340 nodes 2311979 pv g1f3 b8c6 b1c3 g8f6 d2d4 d7d5 e2e3 e7e6 f1d3 f8d6 c3b5 e8g8 b5d6 d8d6
502698.448 Engine->Adapter: info multipv 4 depth 13 score cp 12 time 2496 nodes 2500287 pv e2e3 b8c6 b1c3 g8f6 g1f3 e7e6 d2d4 d7d5 f1d3 f8d6 c3b5 e8g8 b5d6 d8d6
502698.448 Engine->Adapter: info currmove b1c3 currmovenumber 2
502698.760 Engine->Adapter: info multipv 1 depth 14 score cp 16 time 3463 nodes 3597195 pv d2d4 g8f6 b1c3 e7e6 g1f3 b8c6 e2e3 d7d5 f1d3 f8d6 c3b5 f6e4 b5d6 c7d6 e1g1 e8g8 d3e4 d5e4
502698.760 Adapter->Xboard: 0 +16 346 3597195
502698.760 Adapter->Xboard: 14 +16 346 3597195 d4 Nf6 Nc3 e6 Nf3 Nc6 e3 d5 Bd3 Bd6 Nb5 Ne4 Nxd6+ cxd6 O-O O-O Bxe4 dxe4   2%
502698.760 Engine->Adapter: info multipv 2 depth 14 score cp 16 time 3775 nodes 3965550 pv b1c3 g8f6 d2d4 e7e6 g1f3 b8c6 e2e3 d7d5 f1d3 f8d6 c3b5 f6e4 b5d6 c7d6 e1g1 e8g8 d3e4 d5e4
502698.760 Adapter->Xboard: 14 +16 378 3965550 Nc3 Nf6 d4 e6 Nf3 Nc6 e3 d5 Bd3 Bd6 Nb5 Ne4 Nxd6+ cxd6 O-O O-O Bxe4 dxe4   2%
502698.760 Engine->Adapter: info multipv 3 depth 13 score cp 12 time 2340 nodes 2311979 pv g1f3 b8c6 b1c3 g8f6 d2d4 d7d5 e2e3 e7e6 f1d3 f8d6 c3b5 e8g8 b5d6 d8d6
502698.760 Engine->Adapter: info multipv 4 depth 13 score cp 12 time 2496 nodes 2500287 pv e2e3 b8c6 b1c3 g8f6 g1f3 e7e6 d2d4 d7d5 f1d3 f8d6 c3b5 e8g8 b5d6 d8d6
502698.760 Engine->Adapter: info currmove g1f3 currmovenumber 3
502699.010 Xboard->Adapter: .
502699.010 Adapter->Xboard: stat01: 250 2500287 14 17 20 Nf3
502699.041 Engine->Adapter: info time 4056 nodes 4270000 nps 1052761 tbhits 0 cpuload 999
502699.041 Engine->Adapter: info hashfull 22
502699.056 Engine->Adapter: info multipv 1 depth 14 score cp 16 time 3463 nodes 3597195 pv d2d4 g8f6 b1c3 e7e6 g1f3 b8c6 e2e3 d7d5 f1d3 f8d6 c3b5 f6e4 b5d6 c7d6 e1g1 e8g8 d3e4 d5e4
502699.056 Adapter->Xboard: 0 +16 346 3597195
502699.056 Adapter->Xboard: 14 +16 346 3597195 d4 Nf6 Nc3 e6 Nf3 Nc6 e3 d5 Bd3 Bd6 Nb5 Ne4 Nxd6+ cxd6 O-O O-O Bxe4 dxe4   2%
502699.056 Engine->Adapter: info multipv 2 depth 14 score cp 16 time 3775 nodes 3965550 pv b1c3 g8f6 d2d4 e7e6 g1f3 b8c6 e2e3 d7d5 f1d3 f8d6 c3b5 f6e4 b5d6 c7d6 e1g1 e8g8 d3e4 d5e4
502699.056 Adapter->Xboard: 14 +16 378 3965550 Nc3 Nf6 d4 e6 Nf3 Nc6 e3 d5 Bd3 Bd6 Nb5 Ne4 Nxd6+ cxd6 O-O O-O Bxe4 dxe4   2%
502699.056 Engine->Adapter: info multipv 3 depth 14 score cp 16 time 4071 nodes 4291687 pv g1f3 b8c6 b1c3 g8f6 d2d4 d7d5 e2e3 e7e6 f1d3 f8d6 c3b5 f6e4 b5d6 c7d6 e1g1 e8g8 d3e4 d5e4
502699.056 Adapter->Xboard: 14 +16 407 4291687 Nf3 Nc6 Nc3 Nf6 d4 d5 e3 e6 Bd3 Bd6 Nb5 Ne4 Nxd6+ cxd6 O-O O-O Bxe4 dxe4   2%
502699.056 Engine->Adapter: info multipv 4 depth 13 score cp 12 time 2496 nodes 2500287 pv e2e3 b8c6 b1c3 g8f6 g1f3 e7e6 d2d4 d7d5 f1d3 f8d6 c3b5 e8g8 b5d6 d8d6
502699.056 Engine->Adapter: info currmove e2e3 currmovenumber 4
502699.493 Engine->Adapter: info multipv 1 depth 14 score cp 16 time 3463 nodes 3597195 pv d2d4 g8f6 b1c3 e7e6 g1f3 b8c6 e2e3 d7d5 f1d3 f8d6 c3b5 f6e4 b5d6 c7d6 e1g1 e8g8 d3e4 d5e4
502699.493 Adapter->Xboard: 0 +16 346 3597195
502699.493 Adapter->Xboard: 14 +16 346 3597195 d4 Nf6 Nc3 e6 Nf3 Nc6 e3 d5 Bd3 Bd6 Nb5 Ne4 Nxd6+ cxd6 O-O O-O Bxe4 dxe4   2%
502699.493 Engine->Adapter: info multipv 2 depth 14 score cp 16 time 3775 nodes 3965550 pv b1c3 g8f6 d2d4 e7e6 g1f3 b8c6 e2e3 d7d5 f1d3 f8d6 c3b5 f6e4 b5d6 c7d6 e1g1 e8g8 d3e4 d5e4
502699.509 Adapter->Xboard: 14 +16 378 3965550 Nc3 Nf6 d4 e6 Nf3 Nc6 e3 d5 Bd3 Bd6 Nb5 Ne4 Nxd6+ cxd6 O-O O-O Bxe4 dxe4   2%
502699.509 Engine->Adapter: info multipv 3 depth 14 score cp 16 time 4071 nodes 4291687 pv g1f3 b8c6 b1c3 g8f6 d2d4 d7d5 e2e3 e7e6 f1d3 f8d6 c3b5 f6e4 b5d6 c7d6 e1g1 e8g8 d3e4 d5e4
502699.509 Adapter->Xboard: 14 +16 407 4291687 Nf3 Nc6 Nc3 Nf6 d4 d5 e3 e6 Bd3 Bd6 Nb5 Ne4 Nxd6+ cxd6 O-O O-O Bxe4 dxe4   2%
502699.509 Engine->Adapter: info multipv 4 depth 14 score cp 16 time 4508 nodes 4798494 pv e2e3 b8c6 b1c3 g8f6 g1f3 e7e6 d2d4 d7d5 f1d3 f8d6 c3b5 f6e4 b5d6 c7d6 e1g1 e8g8 d3e4 d5e4
502699.509 Adapter->Xboard: 14 +16 451 4798494 e3 Nc6 Nc3 Nf6 Nf3 e6 d4 d5 Bd3 Bd6 Nb5 Ne4 Nxd6+ cxd6 O-O O-O Bxe4 dxe4   2%
502699.509 Engine->Adapter: info currmove d2d3 currmovenumber 5
502699.524 Engine->Adapter: info currmove e2e4 currmovenumber 6
502699.680 Engine->Adapter: info currmove b1a3 currmovenumber 7
502699.712 Engine->Adapter: info currmove g1h3 currmovenumber 8
502699.712 Engine->Adapter: info currmove b2b3 currmovenumber 9
502699.727 Engine->Adapter: info currmove b2b4 currmovenumber 10
502699.743 Engine->Adapter: info currmove g2g3 currmovenumber 11
502699.743 Engine->Adapter: info currmove g2g4 currmovenumber 12
502699.774 Engine->Adapter: info currmove a2a4 currmovenumber 13
502699.790 Engine->Adapter: info currmove h2h4 currmovenumber 14
502699.790 Engine->Adapter: info currmove c2c4 currmovenumber 15
502699.805 Engine->Adapter: info currmove c2c3 currmovenumber 16
502699.805 Engine->Adapter: info currmove a2a3 currmovenumber 17
502699.805 Engine->Adapter: info currmove f2f4 currmovenumber 18
502699.821 Engine->Adapter: info currmove h2h3 currmovenumber 19
502699.821 Engine->Adapter: info currmove f2f3 currmovenumber 20
502699.836 Engine->Adapter: info depth 14 time 4851 nodes 5177926 nps 1067394 tbhits 0
502699.836 Engine->Adapter: info depth 15
502699.836 Engine->Adapter: info currmove d2d4 currmovenumber 1
502700.055 Engine->Adapter: info time 5070 nodes 5420000 nps 1069034 tbhits 0 cpuload 998
502700.055 Engine->Adapter: info hashfull 28
502701.022 Xboard->Adapter: .
502701.022 Adapter->Xboard: stat01: 507 5420000 14 19 20 d4
502701.069 Engine->Adapter: info time 6084 nodes 6590000 nps 1083169 tbhits 0 cpuload 999
502701.069 Engine->Adapter: info hashfull 34
502701.709 Engine->Adapter: info multipv 1 depth 15 score cp 16 time 6724 nodes 7360545 pv d2d4 g8f6 b1c3 e7e6 g1f3 b8c6 e2e3 d7d5 f1d3 f8d6 c3b5 f6e4 b5d6 c7d6 e1g1 e8g8 d3e4 d5e4
502701.709 Adapter->Xboard: 0 +16 672 7360545
502701.709 Adapter->Xboard: 15 +16 672 7360545 d4 Nf6 Nc3 e6 Nf3 Nc6 e3 d5 Bd3 Bd6 Nb5 Ne4 Nxd6+ cxd6 O-O O-O Bxe4 dxe4   3%
502701.709 Engine->Adapter: info multipv 2 depth 14 score cp 16 time 3775 nodes 3965550 pv b1c3 g8f6 d2d4 e7e6 g1f3 b8c6 e2e3 d7d5 f1d3 f8d6 c3b5 f6e4 b5d6 c7d6 e1g1 e8g8 d3e4 d5e4
502701.709 Engine->Adapter: info multipv 3 depth 14 score cp 16 time 4071 nodes 4291687 pv g1f3 b8c6 b1c3 g8f6 d2d4 d7d5 e2e3 e7e6 f1d3 f8d6 c3b5 f6e4 b5d6 c7d6 e1g1 e8g8 d3e4 d5e4
502701.709 Engine->Adapter: info multipv 4 depth 14 score cp 16 time 4508 nodes 4798494 pv e2e3 b8c6 b1c3 g8f6 g1f3 e7e6 d2d4 d7d5 f1d3 f8d6 c3b5 f6e4 b5d6 c7d6 e1g1 e8g8 d3e4 d5e4
502701.709 Engine->Adapter: info currmove b1c3 currmovenumber 2
502702.083 Engine->Adapter: info time 7098 nodes 7770000 nps 1094675 tbhits 0 cpuload 999
502702.083 Engine->Adapter: info hashfull 40
502702.645 Engine->Adapter: info multipv 1 depth 15 score cp 16 time 6724 nodes 7360545 pv d2d4 g8f6 b1c3 e7e6 g1f3 b8c6 e2e3 d7d5 f1d3 f8d6 c3b5 f6e4 b5d6 c7d6 e1g1 e8g8 d3e4 d5e4
502702.645 Adapter->Xboard: 0 +16 672 7360545
502702.645 Adapter->Xboard: 15 +16 672 7360545 d4 Nf6 Nc3 e6 Nf3 Nc6 e3 d5 Bd3 Bd6 Nb5 Ne4 Nxd6+ cxd6 O-O O-O Bxe4 dxe4   4%
502702.645 Engine->Adapter: info multipv 2 depth 15 score cp 16 time 7660 nodes 8418394 pv b1c3 g8f6 d2d4 e7e6 g1f3 b8c6 e2e3 d7d5 f1d3 f8d6 c3b5 f6e4 b5d6 c7d6 e1g1 e8g8 d3e4 d5e4
502702.645 Adapter->Xboard: 15 +16 766 8418394 Nc3 Nf6 d4 e6 Nf3 Nc6 e3 d5 Bd3 Bd6 Nb5 Ne4 Nxd6+ cxd6 O-O O-O Bxe4 dxe4   4%
502702.645 Engine->Adapter: info multipv 3 depth 14 score cp 16 time 4071 nodes 4291687 pv g1f3 b8c6 b1c3 g8f6 d2d4 d7d5 e2e3 e7e6 f1d3 f8d6 c3b5 f6e4 b5d6 c7d6 e1g1 e8g8 d3e4 d5e4
502702.645 Engine->Adapter: info multipv 4 depth 14 score cp 16 time 4508 nodes 4798494 pv e2e3 b8c6 b1c3 g8f6 g1f3 e7e6 d2d4 d7d5 f1d3 f8d6 c3b5 f6e4 b5d6 c7d6 e1g1 e8g8 d3e4 d5e4
502702.645 Engine->Adapter: info currmove g1f3 currmovenumber 3
502703.035 Xboard->Adapter: .
502703.035 Adapter->Xboard: stat01: 451 4798494 15 17 20 Nf3
502703.097 Engine->Adapter: info time 8112 nodes 8940000 nps 1102071 tbhits 0 cpuload 1000
502703.097 Engine->Adapter: info hashfull 46
502703.191 Engine->Adapter: info multipv 1 depth 15 score cp 16 time 6724 nodes 7360545 pv d2d4 g8f6 b1c3 e7e6 g1f3 b8c6 e2e3 d7d5 f1d3 f8d6 c3b5 f6e4 b5d6 c7d6 e1g1 e8g8 d3e4 d5e4
502703.191 Adapter->Xboard: 0 +16 672 7360545
502703.191 Adapter->Xboard: 15 +16 672 7360545 d4 Nf6 Nc3 e6 Nf3 Nc6 e3 d5 Bd3 Bd6 Nb5 Ne4 Nxd6+ cxd6 O-O O-O Bxe4 dxe4   5%
502703.191 Engine->Adapter: info multipv 2 depth 15 score cp 16 time 7660 nodes 8418394 pv b1c3 g8f6 d2d4 e7e6 g1f3 b8c6 e2e3 d7d5 f1d3 f8d6 c3b5 f6e4 b5d6 c7d6 e1g1 e8g8 d3e4 d5e4
502703.191 Adapter->Xboard: 15 +16 766 8418394 Nc3 Nf6 d4 e6 Nf3 Nc6 e3 d5 Bd3 Bd6 Nb5 Ne4 Nxd6+ cxd6 O-O O-O Bxe4 dxe4   5%
502703.191 Engine->Adapter: info multipv 3 depth 15 score cp 16 time 8206 nodes 9052400 pv g1f3 b8c6 b1c3 g8f6 d2d4 d7d5 e2e3 e7e6 f1d3 f8d6 c3b5 f6e4 b5d6 c7d6 e1g1 e8g8 d3e4 d5e4
502703.191 Adapter->Xboard: 15 +16 821 9052400 Nf3 Nc6 Nc3 Nf6 d4 d5 e3 e6 Bd3 Bd6 Nb5 Ne4 Nxd6+ cxd6 O-O O-O Bxe4 dxe4   5%
502703.191 Engine->Adapter: info multipv 4 depth 14 score cp 16 time 4508 nodes 4798494 pv e2e3 b8c6 b1c3 g8f6 g1f3 e7e6 d2d4 d7d5 f1d3 f8d6 c3b5 f6e4 b5d6 c7d6 e1g1 e8g8 d3e4 d5e4
502703.191 Engine->Adapter: info currmove e2e3 currmovenumber 4
502703.924 Engine->Adapter: info multipv 1 depth 15 score cp 16 time 6724 nodes 7360545 pv d2d4 g8f6 b1c3 e7e6 g1f3 b8c6 e2e3 d7d5 f1d3 f8d6 c3b5 f6e4 b5d6 c7d6 e1g1 e8g8 d3e4 d5e4
502703.924 Adapter->Xboard: 0 +16 672 7360545
502703.924 Adapter->Xboard: 15 +16 672 7360545 d4 Nf6 Nc3 e6 Nf3 Nc6 e3 d5 Bd3 Bd6 Nb5 Ne4 Nxd6+ cxd6 O-O O-O Bxe4 dxe4   5%
502703.924 Engine->Adapter: info multipv 2 depth 15 score cp 16 time 7660 nodes 8418394 pv b1c3 g8f6 d2d4 e7e6 g1f3 b8c6 e2e3 d7d5 f1d3 f8d6 c3b5 f6e4 b5d6 c7d6 e1g1 e8g8 d3e4 d5e4
502703.924 Adapter->Xboard: 15 +16 766 8418394 Nc3 Nf6 d4 e6 Nf3 Nc6 e3 d5 Bd3 Bd6 Nb5 Ne4 Nxd6+ cxd6 O-O O-O Bxe4 dxe4   5%
502703.924 Engine->Adapter: info multipv 3 depth 15 score cp 16 time 8206 nodes 9052400 pv g1f3 b8c6 b1c3 g8f6 d2d4 d7d5 e2e3 e7e6 f1d3 f8d6 c3b5 f6e4 b5d6 c7d6 e1g1 e8g8 d3e4 d5e4
502703.924 Adapter->Xboard: 15 +16 821 9052400 Nf3 Nc6 Nc3 Nf6 d4 d5 e3 e6 Bd3 Bd6 Nb5 Ne4 Nxd6+ cxd6 O-O O-O Bxe4 dxe4   5%
502703.924 Engine->Adapter: info multipv 4 depth 15 score cp 16 time 8939 nodes 9897950 pv e2e3 b8c6 b1c3 g8f6 g1f3 e7e6 d2d4 d7d5 f1d3 f8d6 c3b5 f6e4 b5d6 c7d6 e1g1 e8g8 d3e4 d5e4
502703.924 Adapter->Xboard: 15 +16 894 9897950 e3 Nc6 Nc3 Nf6 Nf3 e6 d4 d5 Bd3 Bd6 Nb5 Ne4 Nxd6+ cxd6 O-O O-O Bxe4 dxe4   5%
502703.924 Engine->Adapter: info currmove d2d3 currmovenumber 5
502703.971 Engine->Adapter: info currmove e2e4 currmovenumber 6
502704.111 Engine->Adapter: info time 9126 nodes 10110000 nps 1107824 tbhits 0 cpuload 999
502704.111 Engine->Adapter: info hashfull 52
502705.047 Xboard->Adapter: .
502705.047 Adapter->Xboard: stat01: 913 10110000 15 14 20 e4
502705.125 Engine->Adapter: info time 10140 nodes 11300000 nps 1114398 tbhits 0 cpuload 999
502705.125 Engine->Adapter: info hashfull 59
502706.139 Engine->Adapter: info time 11154 nodes 12450000 nps 1116192 tbhits 0 cpuload 1000
502706.139 Engine->Adapter: info hashfull 66
502707.059 Xboard->Adapter: .
502707.059 Adapter->Xboard: stat01: 1115 12450000 15 14 20 e4
502707.153 Engine->Adapter: info time 12168 nodes 13650000 nps 1121795 tbhits 0 cpuload 1000
502707.153 Engine->Adapter: info hashfull 73
502708.167 Engine->Adapter: info time 13182 nodes 14870000 nps 1128053 tbhits 0 cpuload 1000
502708.167 Engine->Adapter: info hashfull 79
502709.072 Xboard->Adapter: .
502709.072 Adapter->Xboard: stat01: 1318 14870000 15 14 20 e4
502709.181 Engine->Adapter: info time 14196 nodes 16100000 nps 1134122 tbhits 0 cpuload 1000
502709.181 Engine->Adapter: info hashfull 86
502710.195 Engine->Adapter: info time 15210 nodes 17250000 nps 1134122 tbhits 0 cpuload 999
502710.195 Engine->Adapter: info hashfull 93
502710.507 Xboard->Adapter: exit
502710.507 POLYGLOT STOP SEARCH
502710.507 Adapter->Engine: stop
502710.507 POLYGLOT WAIT
502710.507 Xboard->Adapter: quit
502710.507 POLYGLOT *** "quit" from XBoard ***
502710.507 POLYGLOT *** QUIT ***
502710.507 Adapter->Engine: quit
502710.523 Engine->Adapter: info time 15538 nodes 17610000 nps 1133350 tbhits 0 cpuload 999
502710.523 Engine->Adapter: info hashfull 95
502710.523 Engine->Adapter: bestmove d2d4 ponder g8f6
502711.006 closing child


this was with winboard 4.4.0.
Wat engine did you use?

[H.G.Muller]

What I don't like about the above, is that on receiving the first d=14 line, the display is cleared, and the d=13 lines are no longer visible. That is contrary to the idea of the EngineOutput window, where (in single PV mode) you would see the PV at all depths. So when I set multiPV=3, I want to see at the end of a 14-ply search three lines with d=14, three with d=13, three with d=12, etc. (I don't care so much if there were four of d=12 in sted of three, because a new line surfaced there; that also happens in single-PV mode on most engines when they switch PV. You first get the old PV at the new depth with a new score, and then it fails high on another move, and you eventually get a new PV of the same depth with a better score. Similar things can happen in multi-PV mode, and it would be useful to be able to follow that.)

I was using Glaurung 2.2, btw; there I see (with multiPV=5) at the end of a 9-ply search six or seven d=9 lines (some duplicates), and a single d=8 line at the bottom. The rest was cleared. But I also do not like the duplicates. The only excuse for a duplicate would IMO be that is would re-display the single best line after finishing the iteration, with a new time and node count, so that you know the iteration has finished. (Most single-PV engines do that as well.) But it might be more logical to provide that info (the current depth and move that is worked on) with the analysis output of stat01 lines above the display field in the EngineOutput window, even in the single-PV case. XBoard 4.4.1 already did print the depth there.

This behavior occurred both with the Polyglot I downloaded from your website as with Michel's 1.4.46b (which, I think, includes your patch for this).

[H.G.Muller]

This patch does what I want:

Code: Select all

--- uci_old.c      2009-08-23 22:46:56.046817600 +0200
+++ uci.c       2009-11-24 12:54:33.772409600 +0100
@@ -510,7 +510,9 @@
    int n;
    int multipvline=0;
    sint64 ln;
-
+   static int multipvSP = 0;
+   static int multipvScore[256];
+   static move_t multipvMove[256];


    ASSERT(uci_is_ok(uci));
@@ -613,6 +615,7 @@
                 if(Uci->multipv_mode) multipvline=n;

          ASSERT(n>=1);
+         multipvline=n; // no smartassing, just believe what engine says

       } else if (my_string_equal(option,"nodes")) {

@@ -708,10 +711,29 @@
    if(multipvline>1 && uci->depth<uci->best_depth) event &= ~EVENT_PV;
    if ((event & EVENT_PV) != 0) {
       uci->best_score = uci->score;
-         uci->best_depth = uci->depth;
-         if(multipvline==1)uci->depth=-1; //HACK ,clears the engine outpout window,see send_pv in adapter.cpp
       uci->best_sel_depth = uci->sel_depth;
       line_copy(uci->best_pv,uci->pv);
+#if 0
+         uci->best_depth = uci->depth;
+         if(multipvline==1)uci->depth=-1; //HACK ,clears the engine outpout window,see send_pv in adapter.cpp
+#else
+      if(uci->depth < uci->best_depth) event &= ~EVENT_PV; // ignore lines of lower depth
+      else {
+        if(uci->depth > uci->best_depth) multipvSP = 0; // clear stack when westart new depth
+        uci->best_depth = uci->depth;
+        if(multipvline >= 1) {
+          int i;
+          for(i=0; i<multipvSP; i++) {
+            if(uci->score == multipvScore[i] && uci->pv[0] == multipvMove[i]) {
+              return event & ~EVENT_PV; // ignore duplicates
+            }
+          }
+          // line is new, add to stack
+          multipvMove[multipvSP] = uci->pv[0];
+          multipvScore[multipvSP++] = uci->score;
+        }
+      }
+#endif
    }
    return event;
 }


[Michel]

I need to think about this a bit.

In multipv mode the engine periodically sends its N current best lines, independent of depth (when one of the best lines changes). Viewed in this way the duplicates and the clearing of the engine output window are normal (this is how Arena also does it IIRC, presumably other GUI's do the same).

* multipv <num>

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.

If the xboard protocol would interprete multipv in the same way as UCI then polyglot wouldn't have to do anything and WB would have full freedom on how to handle the MultiPV lines. Wouldn't that be more logical?

[F. Bluemers]

As Michel points out,the engine outputs multipv lines1..n with different depths.
It seems natural to just clear the window when multipv=1 is reached.
edit:
Else a possible workaround for the winboard clears could be to set the depth of all multipv1..n lines to the depth of the first line
Then depth would just stand for the engine's iteration depth.

Code: Select all

502695.078 Adapter->Xboard: 3 +20 2 908 Nc3 Nc6 Nf3 Nf6
502695.078 Engine->Adapter: info multipv 2 depth 3 score cp 20 time 15 nodes 1062 pv g1f3 b8c6 b1c3 g8f6
502695.078 Adapter->Xboard: 3 +20 2 1062 Nf3 Nc6 Nc3 Nf6
502695.078 Engine->Adapter: info multipv 3 depth 3 score cp 15 time 15 nodes 1214 pv d2d4 b8c6 g1f3 g8f6
502695.078 Adapter->Xboard: 3 +15 2 1214 d4 Nc6 Nf3 Nf6
502695.078 Engine->Adapter: info multipv 4 depth 3 score cp 12 time 15 nodes 1344 pv e2e4 b8c6 b1c3 g8f6
502695.078 Adapter->Xboard: 3 +12 2 1344 e4 Nc6 Nc3 Nf6
502695.078 Engine->Adapter: info depth 3 time 15 nodes 1541 nps 0 tbhits 0
502695.094 Engine->Adapter: info depth 4
502695.094 Engine->Adapter: info multipv 1 depth 4 score cp 25 time 31 nodes 1771 pv b1c3 b8c6 g1f3 g8f6 d2d4
502695.094 Adapter->Xboard: 0 +25 3 1771
502695.094 Adapter->Xboard: 4 +25 3 1771 Nc3 Nc6 Nf3 Nf6 d4
502695.094 Engine->Adapter: info multipv 2 depth 3 score cp 20 time 15 nodes 1062 pv g1f3 b8c6 b1c3 g8f6
502695.094 Engine->Adapter: info multipv 3 depth 3 score cp 15 time 15 nodes 1214 pv d2d4 b8c6 g1f3 g8f6
502695.094 Engine->Adapter: info multipv 4 depth 3 score cp 12 time 15 nodes 1344 pv e2e4 b8c6 b1c3 g8f6
502695.110 Engine->Adapter: info multipv 1 depth 4 score cp 25 time 31 nodes 1771 pv b1c3 b8c6 g1f3 g8f6 d2d4
502695.110 Adapter->Xboard: 0 +25 3 1771
502695.110 Adapter->Xboard: 4 +25 3 1771 Nc3 Nc6 Nf3 Nf6 d4
502695.110 Engine->Adapter: info multipv 2 depth 4 score cp 25 time 31 nodes 1970 pv g1f3 b8c6 b1c3 g8f6 d2d4
502695.110 Adapter->Xboard: 4 +25 3 1970 Nf3 Nc6 Nc3 Nf6 d4
502695.110 Engine->Adapter: info multipv 3 depth 3 score cp 15 time 15 nodes 1214 pv d2d4 b8c6 g1f3 g8f6
502695.110 Engine->Adapter: info multipv 4 depth 3 score cp 12 time 15 nodes 1344 pv e2e4 b8c6 b1c3 g8f6
502695.110 Engine->Adapter: info multipv 1 depth 4 score cp 25 time 31 nodes 1771 pv b1c3 b8c6 g1f3 g8f6 d2d4

[H.G.Muller]

I need to think about this a bit.

In multipv mode the engine periodically sends its N current best lines, independent of depth (when one of the best lines changes). Viewed in this way the duplicates and the clearing of the engine output window are normal (this is how Arena also does it IIRC, presumably other GUI's do the same).

That is a good analysis of why this method is not really acceptable. If one line changes, it cold send that line. Resending all others, just because one change, is a totally pointless waste of bandwidth.

The clearing of the EngineOutput window is not desirable at all. It makes the output practically impossible to watch, an 99% of the information is already erased before you could possibly see it. So of the five times each line is sent, exactly zero times it is of any use... With multiPV=5 every depth leads to the sending of 5 times a buch of 5 lines, and upto d=10 they disappear invisibly fast. That is 250 lines that served no purpose at all!

If the xboard protocol would interprete multipv in the same way as UCI then polyglot wouldn't have to do anything and WB would have full freedom on how to handle the MultiPV lines. Wouldn't that be more logical?

This could be said of any aspect of UCI protocol, and when carried through, would make WB protocol the same crappy protocol as UCI. In this particular case by sending tons of duplicates. To me that holds no logic at all. WinBoard protocol is not just for making Polyglot communicate with WinBoard, so the distribution of tasks between Polyglot and the GUI is not an arbitrary choice. By not filtering out the garbage in Polyglot, but leaving it to WinBoard, would mean that all WinBoard engines have to deal with garbage.

[Michel]

Could you point me to a description to the xboard protocol version of multipv?

I think people are generally happy with the way UCI handles multipv (on the many forums I read I have never
seen people complain about it).

It is true that it would be possible to use a differential protocol where the engine would only send the
difference between the original N best lines and the new N best lines but that is only
a cosmetic issue (and puts a slightly bigger burden on the engine author).

I don't think bandwidth is an issue. This data is not sent over the network.

EDIT:

I found it

1. Multi-PV

This seems the least controversial one: simply allow an engine to send feature multipv=1 at startup. If the GUI has received this, it can then send multipv N to the engine, to request it to calculate and send (as Thinking Output) the best N lines. The engine can decide how many lines it will actually send; the command is a request only. (After all, there might be only one legal move...)

I don't quite understand this. Does it mean that after receiving

multipv N

PG should send

setoption name multipv value N

to the engine and then report back the next batch of multipv lines (sorted in some unspecified way)?

[H.G.Muller]

When I started working on an implementation of multi-variation in WinBoard, I got increased doubts like the way I proposed it would be the proper way to do it. Many things looked very awkward. Like, for instance, in what menu dialog would the multi-PV setting belong. Should it apply to all engines, as a global setting? That did not feel right, the reason to have such global settings is that you can change, say, hash table size for all engines at once in a tournament. But multi-variation is a feature that is totally useless in tournaments or engine-engine matches. It is a feature that is used in analysis, when you are using your favorite analysis engine.

So I think it would be much more logical to keep this setting amongst the private engine settings. Which means that it might as well keep the status of an engine-defined option. Then it will automatically appear in the dialog where you want to have it. Presumably you would install the engine you want to use for analysis with different settings as you would when you want to use that same engine in a tournament anyway (in other words, install two versions of it, where you would set the multiPV option for one, but not for the other).

So I have come to severely doubt the wisdom of adding a standardized multivar N command. Just have the engine send feature option="multivar -spin 1 1 99" in stead of feature multivar=1, and send it option multivar N in stead of multivar N.

As to the format in which the engine should send the lines: this is indeed underspecified in the definition you quote. I guess a better definition would be:

Code: Select all

In multi-variation mode the engine should make its best attempt to send the best N lines of each iteration with an exact score as Thinking Output, before starting on (and sending Thinking Output for) the next iteration. It would be OK to send more lines, if in the process of searching for the best moves the engine happens to obtain other exact scores, which in hindsight do not belong to the best N. It just should not devote any effort to this. It would also be OK to send fewer lines, e.g. because the number of legal moves is smaller than N, or the score gap is deemed too large for the remaining moves to make sense.


I don't think this puts any extra burdon on the engine. On the contrary. When it has searched a move and obtained an exact score for it (which it would have to do one way or the other) it simply prints the line as Thinking Output. It does not have to remember other lines, nor their scores. Just implement a search algorithm to obtain the N best moves, and then add a print statement for any move that scores between alpha and beta. I don't see how anything could be simpler than that. It is the UCI way that forces the engine to keep a cumbersome record of what lines it obtained in the past, their score and depth, and re-sort them on every new exact score it obtains, to decide if it should output the entire bunch again, or not.

[Michel]

I implemented the patch (except that I put the global variables in the uci object which itself
is passed as a parameter to parse_info).

[H.G.Muller]

OK, thanks! You will know what conforms best to the coding style and organization. I had chosen 'static' within the routine, based on the principle of minimal scope. I could not envision the variales be used anywhere outside the parse_info routine. It is none of my business anyway to nterfere in the programming of Polyglot, I only care about the behavior. And I am quite happy how multi-variation mode works now with this patch. Especially with the WinBoard verson from the development branch, which does not always insert the new Thinking-Output line at the top of the Engine-Output display, but inserts it amongst those of the curent iteration based on its score.

This makes for an optimally quiet display, which is easy to watch.

I still have not decided if it is worth adding a feature multivar=1 to WB protocol. But this can always be done later. To me it seems the current way, where the engine's multiPV setting can be controlled from the Engine #1 Settings menu dialog together with other engine-specific options, is completely satisfactory.