Polyglot1.4.30b

[F.Huber]

OK, try this WinBoard, then. It should not clear the display on receiving a d=1 line after a d=1 info line. (Untested.)

Ok thanks, I'll try it!

This is a Polyglot problem. In WB protocol the value of a check is 0 or 1. It is Polyglot's task to translate that to proper UCI. (Thanks for spotting it, BTW.)

Well, but how should Polyglot know, whether an option is from a checkbox or from any other numerical entrybox?

[H.G.Muller]

Well, but how should Polyglot know, whether an option is from a checkbox or from any other numerical entrybox?

That's what the engine tells it at startup, not? The name of the option is associated with a type.

[F.Huber]

That's what the engine tells it at startup, not? The name of the option is associated with a type.

Yes, you're right - I hope Polglot is still remembering this type when getting such an option later from Winboard.

BTW, your last WB now handles d=1 correctly (I've switched back again to PG 1.4.34 from yesterday).
The only thing I still don't like is that huge space in front of the info strings, I'd really appreciate if they would start at the beginning of the line (and without the depth value).

[H.G.Muller]

That is easily changed (new version at same URL). But I am afraid this might look really ugly on other engines, that interject just a few info lines into the normal thinking output. Keep in mind that WinBoard / Polyglot is not there only for ChestUCI. We must do what on the average looks best.

The amount of space for the leadng numbers is fixed. It only looks "huge" when the Engine-Output window is very narrow. Perhaps resizing it to a larger width would solve the problem better.

[F.Huber]

That is easily changed (new version at same URL). But I am afraid this might look really ugly on other engines, that interject just a few info lines into the normal thinking output. Keep in mind that WinBoard / Polyglot is not there only for ChestUCI. We must do what on the average looks best.

No, that looks really nice now!
Of course you shouldn't make any changes just for ChestUCI, but I'm quite sure that this modification won't affect any other UCI engine at all (which usual chess engine would send such info string mixed up with regular search infos?)

The amount of space for the leadng numbers is fixed. It only looks "huge" when the Engine-Output window is very narrow. Perhaps resizing it to a larger width would solve the problem better.

Well, this resizing is not so easy on a small 800x600 screen! Making the analysis window larger results in a smaller board ...

Now I'm only waiting for Michel's fix of this "0/1->false/true" bug (which makes in fact asmost every UCI engine unusable), then ChestUCI is really working quite well in WB, too.

[H.G.Muller]

..., then ChestUCI is really working quite well in WB, too.

Great! That is what we want!

[F.Huber]

And here another (minor cosmetic) problem of Polyglot:
it sends the pv twice to Winboard,

Code: Select all

20408.914 Engine->Adapter: bestmove g7g2
20408.914 Adapter->GUI: 6 +9989 39 9069 Rg2 h1=N Rg8+ Kf7 Rg7+ Kf8 Nf4 Rd8 Ng6+ Ke8 Rxe7#
20408.914 Adapter->GUI: 6 +9989 39 9069 Rg2 h1=N Rg8+ Kf7 Rg7+ Kf8 Nf4 Rd8 Ng6+ Ke8 Rxe7#


and so of course it's also displayed twice in the analysis window:

Code: Select all

  6   +99.89   9069   0:00.39   Rg2 h1=N Rg8+ Kf7 Rg7+ Kf8 Nf4 Rd8 Ng6+ Ke8 Rxe7#
  6   +99.89   9069   0:00.39   Rg2 h1=N Rg8+ Kf7 Rg7+ Kf8 Nf4 Rd8 Ng6+ Ke8 Rxe7#
Matt in 6 gefunden !  (1 Lösung in 00:00)
Suche abgeschlossen ...  (Zeit=0.39s)
Rg2
Suche nach Matt in 10 ...  (Hash=33MB)
Problem in Datenbank gefunden:  #6; 00:00;
Stellungs-Analyse:  C0/R0/K1/P5/X10   W:3/15
FEN: 2b1rk2/2p1p1RK/2p1p3/7N/8/8/7p/8 w - -   (3+8)


[F.Huber]

There's one thing in the following output of WB I still don't understand:

Code: Select all

  6   +99.89   9069   0:00.44   Rg2 h1=N Rg8+ Kf7 Rg7+ Kf8 Nf4 Rd8 Ng6+ Ke8 Rxe7#
  6   +99.89   9069   0:00.44   Rg2 h1=N Rg8+ Kf7 Rg7+ Kf8 Nf4 Rd8 Ng6+ Ke8 Rxe7#
Matt in 6 gefunden !  (1 Lösung in 00:00)
Suche abgeschlossen ...  (Zeit=0.44s)
Rg2
Suche nach Matt in 10 ...  (Hash=31MB)
Problem in Datenbank gefunden:  #6; 00:00;
Stellungs-Analyse:  C0/R0/K1/P5/X10   W:3/15
FEN: 2b1rk2/2p1p1RK/2p1p3/7N/8/8/7p/8 w - -   (3+8)


Where does this single line Rg2 come from???
Since it's left-aligned (without the 4 usual preceding numbers), is seems to be treated as an info line, but Polyglot is sending it to the GUI as usual analysis line (see the logfile below), so what's going wrong here?

Code: Select all

22828.579 Adapter->GUI: 2 +0 0 0 Suche nach Matt in 10 ...  (Hash=32MB)
22828.579 Engine->Adapter: info depth 6 seldepth 6 currmovenumber 15 currmove h7g6 hashfull 1 nodes 9069 nps 20611
22828.579 Engine->Adapter: info string Suche abgeschlossen ...  (Zeit=0.44s)
22828.579 Adapter->GUI: 6 +9989 44 0 Rg2
22828.579 Engine->Adapter: info string Matt in 6 gefunden !  (1 Lösung in 00:00)
22828.579 Adapter->GUI: 6 +0 0 0 Suche abgeschlossen ...  (Zeit=0.44s)
22828.579 Engine->Adapter: info depth 6 seldepth 6 time 440 score mate 6 multipv 1 pv g7g2 h2h1n g2g8 f8f7 g8g7 f7f8 h5f4 e8d8 f4g6 f8e8 g7e7
22828.579 Adapter->GUI: 6 +0 0 0 Matt in 6 gefunden !  (1 Lösung in 00:00)
22828.579 Engine->Adapter: bestmove g7g2


[F.Huber]

... so what's going wrong here?

I've tried it now with different positions, and it only happens when ChestUCI finds the solution immeadiately (i.e. in 00:00), for longer times it's ok.
So this seems to be a timing problem in WB ...

[H.G.Muller]

That line has a node count of 0. This latest WB version uses the node count as a kludge to recognize a thinking-output line as disguised info string. I figured that would be enough, as zero would not be a valid node count in a normal line. And if the node count really were zero, the time would likely be 0 as well anyway, so why test it? But how can you do a search with 0 nodes? It seems to me you should always have at least 1 node (the root).

If I understand the UCI correctly, it seems that indeed 9096 nodes where searched. So I have no idea why Polyglot then sends a node count of zero. (Or how it gets those 44 centi-sec. Does it calculte that from the nodes and nps?)

[F.Huber]

Maybe I should have better posted the FULL Polyglot log, there are some infos before my first posted line - here the full text for the same position:

Code: Select all

27390.545 GUI->Adapter: name Franz
27390.545 GUI->Adapter: time 90000
27390.545 GUI->Adapter: otim 90000
27390.545 GUI->Adapter: go
27390.545 POLYGLOT THINK
27390.545 POLYGLOT START SEARCH
27390.545 POLYGLOT FEN 2b1rk2/2p1p1RK/2p1p3/7N/8/8/7p/8 w - - 0 1
27390.545 Adapter->Engine: position fen 2b1rk2/2p1p1RK/2p1p3/7N/8/8/7p/8 w - - 0 1
27390.545 Adapter->Engine: go wtime 900000 btime 900000 movestogo 40
27391.103 Engine->Adapter: info string CPU: Celeron 400MHz
27391.103 Adapter->GUI: pong 2
27391.103 Engine->Adapter: info string FEN: 2b1rk2/2p1p1RK/2p1p3/7N/8/8/7p/8 w - -   (3+8)
27391.103 Adapter->GUI: 1 +0 0 0 CPU: Celeron 400MHz
27391.158 Engine->Adapter: info string Stellungs-Analyse:  C0/R0/K1/P5/X10   W:3/15
27391.158 Adapter->GUI: 1 +0 0 0 FEN: 2b1rk2/2p1p1RK/2p1p3/7N/8/8/7p/8 w - -   (3+8)
27391.158 Engine->Adapter: info string Problem in Datenbank gefunden:  #6; 00:00;
27391.158 Adapter->GUI: 1 +0 0 0 Stellungs-Analyse:  C0/R0/K1/P5/X10   W:3/15
27391.158 Engine->Adapter: info string Suche nach Matt in 10 ...  (Hash=38MB)
27391.158 Adapter->GUI: 1 +0 0 0 Problem in Datenbank gefunden:  #6; 00:00;
27392.340 Engine->Adapter: info depth 6 currmovenumber 11 currmove g7g2
27392.340 Engine->Adapter: info depth 6 time 330 score mate 6 pv g7g2
27392.340 Adapter->GUI: 1 +0 0 0 Suche nach Matt in 10 ...  (Hash=38MB)
27392.340 Engine->Adapter: info depth 6 seldepth 6 currmovenumber 15 currmove h7g6 hashfull 1 nodes 9069 nps 23253
27392.340 Engine->Adapter: info string Suche abgeschlossen ...  (Zeit=0.39s)
27392.340 Adapter->GUI: 6 +9989 33 0 Rg2
27392.340 Engine->Adapter: info string Matt in 6 gefunden !  (1 Lösung in 00:00)
27392.340 Adapter->GUI: 6 +0 0 0 Suche abgeschlossen ...  (Zeit=0.39s)
27392.340 Engine->Adapter: info depth 6 seldepth 6 time 390 score mate 6 multipv 1 pv g7g2 h2h1n g2g8 f8f7 g8g7 f7f8 h5f4 e8d8 f4g6 f8e8 g7e7
27392.340 Adapter->GUI: 6 +0 0 0 Matt in 6 gefunden !  (1 Lösung in 00:00)
27392.340 Engine->Adapter: bestmove g7g2
27392.344 Adapter->GUI: 6 +9989 39 9069 Rg2 h1=N Rg8+ Kf7 Rg7+ Kf8 Nf4 Rd8 Ng6+ Ke8 Rxe7#
27392.344 Adapter->GUI: 6 +9989 39 9069 Rg2 h1=N Rg8+ Kf7 Rg7+ Kf8 Nf4 Rd8 Ng6+ Ke8 Rxe7#
27392.344 POLYGLOT MOVE Rg2
27392.344 POLYGLOT THINK -> WAIT
27397.453 GUI->Adapter: EOF
27397.455 GUI->Adapter: result * {xboard exit}
27397.455 POLYGLOT GAME END
27397.455 POLYGLOT WAIT
27397.455 GUI->Adapter: force
27397.455 POLYGLOT WAIT
27397.455 GUI->Adapter: ping 3
27397.455 Adapter->GUI: move g7g2
27397.455 GUI->Adapter: quit
27397.455 POLYGLOT *** "quit" from GUI ***
27397.455 POLYGLOT *** QUIT ***
27397.455 Adapter->Engine: go wtime 900000 btime 900000 movestogo 40


27397.455 POLYGLOT Closing engine
27397.455 Adapter->Engine: EOF
27397.527 Engine->Adapter: EOF
27397.529 POLYGLOT Calling exit


In fact Polyglot takes the time from a previous line (this time it's 390), but "nodes 0" is definitely not coming from ChestUCI.

[H.G.Muller]

The line might be sent by Polyglot, combining two info lines previously received from the engine:

27392.340 Engine->Adapter: info depth 6 currmovenumber 11 currmove g7g2
27392.340 Engine->Adapter: info depth 6 time 330 score mate 6 pv g7g2

Together these lines define a depth, score, time and move, but no node count, and no true PV. I don't know what criteria Polyglot applies to decide when it should flush such a partial line to the GUI. Apparently it decides it can do without a node count.

Unfortunately it substitutes 0 for the unknown node count, which triggers the kludge for info-string recognition. Perhap it should not do that if it wants to use this kludge, i.e. make sure it uses a different made-up value in the node-count field for sending info strings and partial regular thnking output. I am not sure negative values are safe here. (Some GUIs might implement the node count as unsigned.) So perhaps 0 and 1 would be better choices?

[F.Huber]

The line might be sent by Polyglot, combining two info lines previously received from the engine:

27392.340 Engine->Adapter: info depth 6 currmovenumber 11 currmove g7g2
27392.340 Engine->Adapter: info depth 6 time 330 score mate 6 pv g7g2

Together these lines define a depth, score, time and move, but no node count, and no true PV. I don't know what criteria Polyglot applies to decide when it should flush such a partial line to the GUI. Apparently it decides it can do without a node count.

Yes, but 2 line later (and BEFORE Polyglot sends this problematic line) there's an info from the engine which in fact contains the nodes:

Code: Select all

27392.340 Engine->Adapter: info depth 6 seldepth 6 currmovenumber 15 currmove h7g6 hashfull 1 nodes 9069 nps 23253
27392.340 Engine->Adapter: info string Suche abgeschlossen ...  (Zeit=0.39s)
27392.340 Adapter->GUI: 6 +9989 33 0 Rg2


Since Polyglot (in the current version) seems to send alway three zero values after the depth (d +0 0 0), there's also the possibility that you make your kludge for info strings a bit more restrictive by checking for 2 (or even all 3) values to be zero ...

[Michel]

info depth 6 time 330 score mate 6 pv g7g2

I think this is the culprit. You send a PV without a node count. You send it later but then it is too late. If I understand correctly this is against the UCI specification.

Also all infos belonging to the pv should be sent together
e.g. "info depth 2 score cp 214 time 1242 nodes 2124 nps 34928 pv e2e4 e7e5 g1f3"

The fact that PG repeats the last PV has a reason which I have not fully investigated. You can turn this behaviour off by setting RepeatPV false.

I have fixed the problem with the incorrect translation of check options but not posted it yet.

[F.Huber]

info depth 6 time 330 score mate 6 pv g7g2

I think this is the culprit. You send a PV without a node count. You send it later but then it is too late. If I understand correctly this is against the UCI specification.

Also all infos belonging to the pv should be sent together
e.g. "info depth 2 score cp 214 time 1242 nodes 2124 nps 34928 pv e2e4 e7e5 g1f3"

Ok, but the 3 lines before tell the following:

Code: Select all

   The engine can send only selected infos or multiple infos with one info command,
   e.g. "info currmove e2e4 currmovenumber 1" or
        "info depth 12 nodes 123456 nps 100000".


So this together is indeed a bit ambiguous - but I don't know any other UCI-GUI which has (or had) problems with the way I did it in ChestUCI.

[H.G.Muller]

What do you mean by "no problems"? I would be surprised if these GUIs would have printed the correct node count with the PV. But perhaps you did not perceive that as a problem, because the node count was not used to trigger a kludge, so a 0 for the node count would not really be very disrupting (or perhaps they were re-using the node count from the previous iteration).

After reading this part of the UCI specs I am also of the opinion that it is a violation to send a PV without nodes. That other incomplete sets can be sent applies only to info lines that contain no PV. So Polyglot is correct in using the PV as a trigger in relaying the thinking input to WB.

Its "error handling" could be improved, though: if the engine omits one of the required fields it should not substitute 0 if it uses "depth 0 0 0" to indicate info-string lines. Using a default node-count value of 1 would solve this. That seems better than having WinBoard trigger only on all three of (score, time, nodes) to be 0, because score=0 is a normal value, and a non-compliant engine that wold leave out node count might just as well leave out time as well. (Plus that time=0 s actually a quite common value early in the search.)

[Michel]

Now I'm only waiting for Michel's fix of this "0/1->false/true" bug (which makes in fact asmost every UCI engine unusable), then ChestUCI is really working quite well in WB, too.

I think I have fixed this. I think the default depth is now also 1 but this is untested as it is a bit difficult to trigger.

[Michel]

Don't bother trying this version. It contains a nasty buffer overflow. I will post a new version tomorrow.

[Michel]

Don't bother trying this version. It contains a nasty buffer overflow. I will post a new version tomorrow.

I posted a new 1.4.36b at http://alpha.uhasselt.be/Research/Algeb ... t-release/

I didn't bump the version number.

1.4.34b and 1.4.35b should not be used (although the windows versions seemed to work fine for me; I am testing on W2k3).

the default depth is now also 1

I meant the default node count.

[F.Huber]

I posted a new 1.4.36b at http://alpha.uhasselt.be/Research/Algeb ... t-release/

Yes, all 3 problems are fixed now - good job!

Now it's Winboard's turn again for further improvements in supporting UCI engines ...