Polyglot glitch? (feature?)

[Guenther Simon]

I am a bit dissapointed about zero reaction to my thread linked below.

http://www.open-aurec.com/wbforum/viewtopic.php?t=49458

Thus I am trying it again here. Why does Polyglot need to duplicate the
last info from UCI engines in case they don't send final search infos with
the move made(which happens practically very often)? Is it because it
tries to circumvent the lack of the final search info, which according to the
UCI protocol, _should_ be sent? (I know that should != must, but...)
Anyway this behaviour of course screws up current WB and also other
tools which calculate e.g. nps from WB debugs, as the timestamp then
doesn't fit for the duplicated search info.

Guenther

Simple example from above mentioned thread:
Polyglot log:

Code: Select all

< ENGINE info score cp -10 depth 9 nodes 335126 time 1570 pv f5d6 f4d6 e7d6 d3d6 c8c7 a2a3 h8f8 d6d4 c6c5 d4d6
> XBOARD 9 -10 157 335126 Nxd6 Bxd6 Bxd6 Rxd6 Kc7 a3 Rf8 R6d4 c5 Rd6
< ENGINE info string branching factor = 0.373622
< ENGINE info depth 10 seldepth 10
< ENGINE info nps 213716
< ENGINE info score cp -11 depth 10 nodes 335535 time 1570 pv f5d6 f4d6 e7d6 d3d6 c8c7 a2a3 h8f8 d6d4 c6c5 d4d6
> XBOARD 10 -11 157 335535 Nxd6 Bxd6 Bxd6 Rxd6 Kc7 a3 Rf8 R6d4 c5 Rd6
< ENGINE info string branching factor = 0.00481624
< ENGINE info depth 11 seldepth 11
< ENGINE info nps 202817
< ENGINE info score cp -9 depth 11 nodes 1087103 time 5360 pv f5d6 f4d6 e7d6 d3d6 c8c7 a2a3 h8f8 d6d4 c6c5 d4g4 f8g8
> XBOARD 11 -9 536 1087103 Nxd6 Bxd6 Bxd6 Rxd6 Kc7 a3 Rf8 R6d4 c5 Rg4 Rg8
< ENGINE info string branching factor = 13174.8
< ENGINE bestmove f5d6
> XBOARD 11 -9 536 1087103 Nxd6 Bxd6 Bxd6 Rxd6 Kc7 a3 Rf8 R6d4 c5 Rg4 Rg8
> XBOARD move f5d6
POLYGLOT MOVE Nxd6

How it appears then in the WB debug file:

Code: Select all

390231 <second: 8 -12 15 28687 Nxd6 Bxd6 Bxd6 Rxd6 Kc7 a3 Rf8 R6d4 c5 Rd6
390231 <second: 9 -10 157 335126 Nxd6 Bxd6 Bxd6 Rxd6 Kc7 a3 Rf8 R6d4 c5 Rd6
390231 <second: 10 -11 157 335535 Nxd6 Bxd6 Bxd6 Rxd6 Kc7 a3 Rf8 R6d4 c5 Rd6
391583 <second: 11 -9 536 1087103 Nxd6 Bxd6 Bxd6 Rxd6 Kc7 a3 Rf8 R6d4 c5 Rg4 Rg8
415067 <second: 11 -9 536 1087103 Nxd6 Bxd6 Bxd6 Rxd6 Kc7 a3 Rf8 R6d4 c5 Rg4 Rg8
415067 <second: move f5d6

From the UCI specs:

Code: Select all

* bestmove  [ ponder  ]
   the engine has stopped searching and found the move  best in this position.
   the engine can send the move it likes to ponder on. The engine must not start pondering automatically.
   this command must always be sent if the engine stops searching, also in pondering mode if there is a
   "stop" command, so for every "go" command a "bestmove" command is needed!
   Directly before that the engine should send a final "info" command with the final search information,
   the the GUI has the complete statistics about the last search.

[Jaap Weidemann]

Hi Guenther

Hope this solves your problem. Unfortunetely there is no binary in the archive. Maybe Jim or Dann can help.

Kindest Regards

Jaap

[Jim Ablett]

Hi Guenther

Hope this solves your problem. Unfortunetely there is no binary in the archive. Maybe Jim or Dann can help.

Kindest Regards

Jaap

Well done Jaap.
Download windows build here > http://www.mediafire.com/?mzytiyniyzj

Jim.

[Guenther Simon]

Hi Guenther

Hope this solves your problem. Unfortunetely there is no binary in the archive. Maybe Jim or Dann can help.

Kindest Regards

Jaap

Thanks a lot Jaap(and Jim for a quick compile)! I will try it out in the next days.
I requestion though. You only mention the new timestamp feature
in the readme, but not that you have removed the unwanted replication
of the last engine search info itself, if there is no new search info together
with the move made?

Best wishes,
Guenther

[F. Bluemers]

I am a bit dissapointed about zero reaction to my thread linked below.

Sorry for that Guenther.
I myself was too busy lately to play around with polyglot.
I'll have a look at the double sended info although fixing that might not improve much.
The best solution would be if winboard measured time-usage itself and not to rely on any (buggy) engine output.
I'll also check Jaap Weidemann's time-stamp solution and if i like it i might even "steal" it

Best
Fonzy

[F. Bluemers]

Thanks from me too
Best
Fonzy

[Charles Browne]

May be of no importance to what is trying to be achieved for Guenther, but should it be worth noting.

With polyglot_081115_ja there is no search information showing up here in the Engine output window when it is the engine's turn to move. Every once in awhile there might be a line shown in the output window but when it happens it is a jumble of characters that aren't displayed correctly.



While in ponder the expected reply of the opponent isn't displayed in the parenthesis. Only the two parenthesis are displayed, no moves in between them. But ponder searches do show up in the Engine output window.

polyglot1.4w log pv ponder line-

Adapter->XBoard: 1 -15 256 41 (Nc3) d5 exd5 Nxd5 Nxd5 Qxd5

polyglot_081115_ja log pv ponder line-

2833800710 > XBOARD 3 +66 2384 381 () d3

[Guenther Simon]

I am a bit dissapointed about zero reaction to my thread linked below.

Sorry for that Guenther.
I myself was too busy lately to play around with polyglot.
I'll have a look at the double sended info although fixing that might not improve much.
The best solution would be if winboard measured time-usage itself and not to rely on any (buggy) engine output.
I'll also check Jaap Weidemann's time-stamp solution and if i like it i might even "steal" it

Best
Fonzy

I received your mail Fonzy thanks! The main reason for me to ask for a fix here is
that I also use other tools e.g. LGDEBUG sometimes for a full
info pgn. It also calculates nps from the WB timestamps and of course
it screws up if the same number of reported nodes is used in the faked
last search info and it looks like nps jumps around a lot which actually
isn't true.(Note BTW that it also calculates average depth in the Annotator
tag...)


Example:

[Event "?"]
[Site "?"]
[Date "2008.11.08"]
[Round "1"]
[White "Philou_110"]
[Black "Ifrit_b2-9"]
[Result "1/2-1/2"]
[TimeControl "40/900"]
[PlyCount "127"]
[Annotator " 9.4- 9.9"]

1. Nf3 {0.03s} Nf6 {0.10s} 2. c4 {0.05s} c5 {0.14s} 3. Nc3 {0.07s} e6 {0.16s} 4. g3 {0.11s} b6
{0.18s} 5. Bg2 {0.13s} Bb7 {0.20s} 6. O-O {0.16s} Be7 {0.23s} 7. Re1 {0.19s} d6 {0.26s} 8. e4
{0.22s} a6 {0.29s} 9. d4 {0.25s} cxd4 {0.31s} 10. Nxd4 {0.27s} Qc7 {0.33s} 11. Be3 {0.30s} Nbd7
{0.35s} 12. Rc1 {0.32s} O-O {0.38s} 13. f4 {0.34s} Rac8 {0.40s} 14. f5 {0.37s} e5 {0.43s} 15. Nb3
{+0.27/9 33.65s 6716977n 201.8Knps} Qd8 {0.46s} 16. Qe2 {+0.28/8 66.93s 6703294n 201.4Knps} Ra8
{-0.13/10 40.15s 5183676n 130.6Knps} 17. a3 {+0.44/8 100.21s 7305021n 219.5Knps} a5
{-0.04/10 80.40s 5697244n 141.6Knps} 18. Nd2 {+0.40/8 133.50s 6835540n 205.3Knps} Qb8
{+0.06/9 99.00s 1309676n 70.4Knps} 19. Nd5 {+0.60/9 182.86s 10505275n 212.9Knps} Nxd5
{+0.01/10 117.87s 2825904n 149.9Knps} 20. cxd5 {+0.60/9 215.40s 6344211n 195.0Knps} Ba6
{+0.15/10 150.82s 3695816n 112.2Knps} 21. Qh5 {+0.53/8 247.95s 7332729n 225.3Knps} Nc5
{+0.46/9 170.23s 514413n 26.5Knps} 22. Rc2 {+0.47/8 289.14s 10096198n 245.1Knps} a4
{+0.52/9 190.99s 2162810n 104.2Knps} 23. Nc4 {+0.53/8 321.22s 7804310n 243.3Knps} Ra7
{+0.44/9 223.10s 4088604n 127.3Knps} 24. Rec1 {+0.54/8 360.34s 11282064n 288.4Knps} Nd3
{+1.67/9 240.98s 2159177n 120.8Knps} 25. Nxb6 {-0.03/9 392.00s 9731973n 307.4Knps} g6
{+1.27/8 250.27s 1610410n 173.5Knps} 26. Qh6 {+1.01/9 423.66s 9967309n 314.9Knps} Nxc1
{+0.99/9 271.25s 1766835n 84.2Knps} 27. Rxc1 {+1.00/9 455.32s 12202525n 385.5Knps} Rc7
{+1.12/9 283.86s 1121632n 89.0Knps} 28. Rc3 {+0.36/8 486.98s 11984916n 378.6Knps} Rb7
{+1.81/9 299.18s 2197769n 143.4Knps} 29. Nxa4 {+0.41/9 518.63s 11607777n 366.8Knps} Bb5
{+1.51/9 311.25s 1213980n 100.7Knps} 30. b3 {+0.41/9 550.28s 11509592n 363.7Knps} Be8
{+1.75/9 332.56s 3676677n 172.5Knps} 31. Nb2 {-0.51/9 581.93s 12374445n 391.0Knps} Rxb3
{+2.27/9 345.60s 2398355n 184.0Knps} 32. Nd1 {-0.70/9 613.58s 11949432n 377.6Knps} Rxc3
{+2.30/9 362.90s 3815219n 220.7Knps} 33. Nxc3 {-1.07/10 645.22s 12256900n 387.4Knps} Qb2
{+2.30/10 387.48s 3747975n 152.5Knps} 34. Bd2 {-1.17/9 676.85s 14501181n 458.5Knps} Qa1+
{+2.50/9 402.06s 3154264n 216.5Knps} 35. Kf2 {-1.19/9 708.48s 14303895n 452.3Knps} Bd7
{+2.37/9 413.38s 783359n 69.2Knps} 36. Bh3 {-1.53/8 740.10s 15862935n 501.8Knps} gxf5
{+2.36/8 421.69s 1069199n 128.6Knps} 37. Bxf5 {-1.22/10 771.71s 14550284n 460.4Knps} Bxf5
{+2.00/10 442.65s 4147991n 197.9Knps} 38. exf5 {-1.46/10 803.32s 14155128n 447.9Knps} Qb2
{+2.10/10 453.62s 1704088n 155.4Knps} 39. Ke2 {-1.18/9 834.89s 14373151n 455.3Knps} Rc8
{+2.28/10 461.61s 1297052n 162.3Knps} 40. f6 {-0.84/9 866.46s 18478198n 585.4Knps} Bf8
{+2.28/10 468.56s 1396972n 201.3Knps} 41. Qg5+ {-1.76/10 889.21s 10846423n 476.7Knps} Kh8
{+2.28/12 494.69s 5000840n 191.4Knps} 42. Qe3 {-1.62/9 911.96s 10385475n 456.5Knps} Qxa3
{+2.23/11 537.78s 7786784n 180.7Knps} 43. Ne4 {-1.71/9 934.71s 9848454n 432.8Knps} Qa6+
{+2.18/11 561.95s 3483915n 144.2Knps} 44. Qd3 {-1.67/10 957.45s 10779891n 474.0Knps} Rc4
{+2.15/12 615.74s 11553149n 214.8Knps} 45. Kf2 {-1.76/9 980.20s 10196236n 448.1Knps} Qc8
{+3.10/11 651.94s 6518625n 180.1Knps} 46. Ng5 {-1.75/9 1002.95s 10746193n 472.3Knps} e4
{+2.25/11 681.39s 5777705n 196.2Knps} 47. Qe2 {-1.48/10 1025.69s 10621711n 467.0Knps} Qf5+
{+2.26/10 706.30s 5986027n 240.4Knps} 48. Ke1 {-1.85/10 1050.59s 11607714n 466.2Knps} e3
{+2.49/11 741.48s 6429122n 182.7Knps} 49. Bxe3 {-0.93/10 1073.27s 13134485n 579.1Knps} Qxd5
{+2.27/10 763.56s 4199508n 190.3Knps} 50. Qh5 {-0.12/10 1095.95s 14337491n 632.1Knps} Qh1+
{+2.66/10 785.38s 4335659n 198.7Knps} 51. Ke2 {+0.00/10 1118.62s 19006638n 838.3Knps} Rc2+
{+2.66/10 822.30s 7796072n 211.1Knps} 52. Kd3 {+0.00/11 1141.29s 19218987n 847.7Knps} Rxh2
{+2.62/9 839.80s 3948579n 225.7Knps} 53. Nxf7+ {+0.00/11 1163.96s 12652643n 558.1Knps} Kg8
{+3.69/11 865.75s 5422665n 209.0Knps} 54. Qg4+ {-2.55/10 1186.63s 18612806n 821.0Knps} Kxf7
{+6.64/10 882.09s 3541236n 216.7Knps} 55. Qd7+ {-1.35/10 1209.29s 20810478n 918.3Knps} Kg8
{+4.13/10 901.53s 4109088n 211.4Knps} 56. f7+ {+0.00/11 1231.95s 16540359n 729.8Knps} Kg7
{+6.69/11 938.89s 7000050n 187.3Knps} 57. Bd4+ {+0.00/11 1254.62s 20178252n 890.0Knps} Kh6
{+4.12/11 965.09s 5006527n 191.1Knps} 58. Qe6+ {+0.00/10 1277.28s 22852441n 1008.4Knps} Kh5
{+4.13/11 993.66s 5310370n 185.9Knps} 59. Qf5+ {+0.00/10 1299.93s 21550510n 951.4Knps} Kh6
{+4.12/10 1006.48s 2312814n 180.6Knps} 60. Qf6+ {+0.00/10 1322.59s 22046338n 972.8Knps} Kh5
{+6.67/11 1041.25s 6459479n 185.8Knps} 61. Qf5+ {+0.00/11 1345.24s 20997929n 926.9Knps} Kh6
{+0.00/10 1061.61s 6111417n 300.2Knps} 62. Qf4+ {+0.00/10 1367.89s 21641516n 955.3Knps} Kg6
{+4.13/10 1073.06s 2002779n 175.0Knps} 63. Qf6+ {+0.00/11 1390.54s 19124548n 844.2Knps} Kh5
{+6.67/11 1107.24s 7253363n 212.2Knps} 64. Qf5+ {+0.00/11 1413.19s 20831084n 919.6Knps}
1/2-1/2 {Draw by repetition(claimed by white)}

Best,
Guenther

[F. Bluemers]

I received your mail Fonzy thanks! The main reason for me to ask for a fix here is
that I also use other tools e.g. LGDEBUG sometimes for a full
info pgn. It also calculates nps from the WB timestamps and of course
it screws up if the same number of reported nodes is used in the faked
last search info and it looks like nps jumps around a lot which actually
isn't true.(Note BTW that it also calculates average depth in the Annotator
tag...)

Ok,I understand.
For the next release i'll add an inifile option to enable/disable the pv-duplicating "feature".
(That will save me for shipping around special versions )
This allows for testing to see if pv-duplicating is neccesary at all and when.
Best
Fonzy

[Jaap Weidemann]

May be of no importance to what is trying to be achieved for Guenther, but should it be worth noting.

With polyglot_081115_ja there is no search information showing up here in the Engine output window when it is the engine's turn to move. Every once in awhile there might be a line shown in the output window but when it happens it is a jumble of characters that aren't displayed correctly.



While in ponder the expected reply of the opponent isn't displayed in the parenthesis. Only the two parenthesis are displayed, no moves in between them. But ponder searches do show up in the Engine output window.

polyglot1.4w log pv ponder line-

Adapter->XBoard: 1 -15 256 41 (Nc3) d5 exd5 Nxd5 Nxd5 Qxd5

polyglot_081115_ja log pv ponder line-

2833800710 > XBOARD 3 +66 2384 381 () d3

Hi Charles

I tested Jim's build on windows and I'm able to reproduce your problem. I compiled the same source with Visual Studio 2008 and it works just fine here. So it seems there is something wrong with Jim's build. Would you be so kind to verify that it works in your enviroment? I uploaded it here.

Ok,I understand.
For the next release i'll add an inifile option to enable/disable the pv-duplicating "feature".
(That will save me for shipping around special versions )
This allows for testing to see if pv-duplicating is neccesary at all and when.
Best
Fonzy

Hi Fonzy

Just to elaborate on this problem. While the engine is searching, PolyGlot parses the information sent by the engine (in the form "info ...") and stores it. When the search is ended PolyGlot sends the last information sent by engine to the GUI. The problem usually occurs if the engine exists the search before finishing the its current iteration (and does not send the time information just before exiting the search). The result of this is that PolyGlot sends the the last time information sent by the engine (which usually is only sent when finding a new best move) to the GUI. In a case like this PolyGlot sends the time sent by the engine when it found a last best move at the previous iteration . The solution is simply to always send PolyGlot's internal time to the GUI rather than that sent by the engine. The PV will be sent at the end of the search (or will be "replicated") in such a case by my version too. Nothing in this regard has been changed nor do I think it is needed to.

Kind regards

Jaap

[F. Bluemers]

May be of no importance to what is trying to be achieved for Guenther, but should it be worth noting.

With polyglot_081115_ja there is no search information showing up here in the Engine output window when it is the engine's turn to move. Every once in awhile there might be a line shown in the output window but when it happens it is a jumble of characters that aren't displayed correctly.



While in ponder the expected reply of the opponent isn't displayed in the parenthesis. Only the two parenthesis are displayed, no moves in between them. But ponder searches do show up in the Engine output window.

polyglot1.4w log pv ponder line-

Adapter->XBoard: 1 -15 256 41 (Nc3) d5 exd5 Nxd5 Nxd5 Qxd5

polyglot_081115_ja log pv ponder line-

2833800710 > XBOARD 3 +66 2384 381 () d3

Hi Charles

I tested Jim's build on windows and I'm able to reproduce your problem. I compiled the same source with Visual Studio 2008 and it works just fine here. So it seems there is something wrong with Jim's build. Would you be so kind to verify that it works in your enviroment? I uploaded it here.

Ok,I understand.
For the next release i'll add an inifile option to enable/disable the pv-duplicating "feature".
(That will save me for shipping around special versions )
This allows for testing to see if pv-duplicating is neccesary at all and when.
Best
Fonzy

Hi Fonzy

Just to elaborate on this problem. While the engine is searching, PolyGlot parses the information sent by the engine (in the form "info ...") and stores it. When the search is ended PolyGlot sends the last information sent by engine to the GUI. The problem usually occurs if the engine exists the search before finishing the its current iteration (and does not send the time information just before exiting the search). The result of this is that PolyGlot sends the the last time information sent by the engine (which usually is only sent when finding a new best move) to the GUI. In a case like this PolyGlot sends the time sent by the engine when it found a last best move at the previous iteration . The solution is simply to always send PolyGlot's internal time to the GUI rather than that sent by the engine. The PV will be sent at the end of the search (or will be "replicated") in such a case by my version too. Nothing in this regard has been changed nor do I think it is needed to.

Kind regards

Jaap

Hi Jaap,send polyglot clock is an interesting workaround but some engines* do not even update the nodecount before moving,so the nps will look better but still be wrong(but probably not by much?).

* see f.i. smash (http://www.open-aurec.com/wbforum/viewtopic.php?t=49458)