Display Engine Output analysis with Move Numbers?

[EdCollins]

Question:

For UCI engines, is there an option to display the Engine Output display with move numbers?

(If there is, I don't see it anywhere.)

For example, in my Engine Output window, I currently see this:

22 +8.27 3298.0M 20:11.55 Rbf1 f5 exf5 Nf6 gxf6 exf6 axb5 axb5 Ra1 Qb6 fxg6 Qd4 Rad1 b4 Bc1 Qb6 Ne2 f5 Bh5 Ra8 Qxf5 Re7 Rde1 Qc7 Ng3 Rxe1 Rxe1 c3 Qf7+ Qxf7 gxf7+ Kh7 bxc3 Bxc3
22 +7.83 789.8M 13:32.85 Rbf1
22 +7.26 3185.5M 8:32.39 Rbf1
21 +6.97 2558.3M 6:51.76 Rbf1 f5 exf5 Nf6 gxf6 exf6 axb5 axb5 Ra1 Qb6 fxg6 Qd4 Rad1 b4 Bc1 Qb6 Ne2 b3 cxb3 Qxb3 Qxb3 cxb3 f5 Nd7 Nd4 Ne5 Be2 Ra8 Rh7 Ra2 Ne6
21 +6.33 1436.9M 3:50.80 Rbf1

etc.

At times, for various reasons, it would be beneficial to optionally see this:

22 +8.27 3298.0M 20:11.55 25.Rbf1 f5 26.exf5 Nf6 27.gxf6 exf6 28.axb5 axb5 29.Ra1 Qb6 30.fxg6 Qd4 31.Rad1 b4 32.Bc1 Qb6 33.Ne2 f5 34.Bh5 Ra8 35.Qxf5 Re7 36.Rde1 Qc7 37.Ng3 Rxe1 38.Rxe1 c3 39.Qf7+ Qxf7 40.gxf7+ 41.Kh7 bxc3 42.Bxc3
22 +7.83 789.8M 13:32.85 25.Rbf1
22 +7.26 3185.5M 8:32.39 25.Rbf1
21 +6.97 2558.3M 6:51.76 25.Rbf1 f5 26.exf5 Nf6 27.gxf6 exf6 28.axb5 axb5 29.Ra1 Qb6 30.fxg6 Qd4 31.Rad1 b4 32.Bc1 Qb6 33.Ne2 b3 34.cxb3 Qxb3 35.Qxb3 cxb3 36.f5 Nd7 37.Nd4 Ne5 38.Be2 Ra8 39.Rh7 Ra2 40.Ne6
21 +6.33 1436.9M 3:50.80 25.Rbf1


The position I'm analyzing was pasted in (3rrnk1/3nppb1/p2p2p1/qp1P2P1/P1p1PPB1/2N4Q/1PPB2K1/1R5R w - b6 0 25) so WinBoard knows it's White to play, and move #25.

I've noticed when I analyze with Crafty, Crafty does display the output with move numbers. Thus, I'm guessing it's a WinBoard protocol/UCI prototcol type of thing, and WinBoard is just displaying the output as it receives it from the engine, (or Polyglot) with no parsing.

I know that "other" (read: lesser quality) GUIs display the move numbers in their analysis window, so it would be nice if WinBoard had that option to display it that way too, regardless of the engine used.

I could probably sit down and in less than an hour, code a little parser to parse the above type of analysis (once I save it to a text file) and give it move numbers. The only thing I'd have to supply would be the starting move number. (And if no move number was passed, start it at Move #1.) But it would be convenient if WinBoard had the option to display it that way for me, regardless of which engine I had loaded.

[H.G.Muller]

You guessed right. In WB protocol the PV is a free-format text field in the thinking output, and WinBoard displays it exactly as the engine sends it. Many engines do not even send SAN (e.g. try Fairy-Max). In UCI the format of the PV is strictly defined, but it is defined as long algebraic, not SAN. Polyglot converts it to SAN.

So as thing stands now, adding the move numbers should be a Polyglot task (under control of a Polyglot option in the Engine Settings dialog). But then it would not be available for WinBoard engines.

I am not entirely happy with this state of affairs. I think formatting of the PV is a GUI task, and should be under control of a GUI option (LAN/SAN/raw). But so far I found consolation in the idea that the PV was not really for looking at, but for playing out on the board, if I wanted to examine it. For the later purpose it is of course also essential that WinBoard can understand what the engine sends it, meaning the parser should be smart enough to skip smilies, and a host of other non-compliant stuff some engines cough up. (But not Polyglot, so UCI engines would be fine.)

One thing that has so far stopped me to implement this is that generation of SAN in WinBoard is a very inefficient process. It generates all legal moves of all pieces, including a check test on each of them (which involves generating all pseudo-legal moves of the opponent), and then counts how many have the same piece type, to-square, from-rank and from-file. As an engine typically coughs up many hundreds of moves in thinking output for ever move it does in the game, this could put a significant burdon on the CPU. I can conceive of a much more efficient algorithm, where you would only generte moves of pieces of the same type as the one on the from-square, and do a check test on them only if they actually go to the given to-square. Similar efficiency problems exist in the parsing of SAN.

This would require a complete re-write, however. And it would abandon the idea of having a single move generator for pseudo-legal moves, from which all else follows (which guarantees consistency). And when I would have to do that, I might as well put another wish of mine in it, namely make it possible for the engine to define the pseudo-legal moves of pieces through the protocol. That would come in very handy in variants that now have to be played with legality testing off (and this produce crappy SAN). But it will require a lot of designing.

An additional problem is that after pasting a FEN with move number 25, WinBoard currently does NOT know the starting move is 25. On such pasting it starts a new game for it, which always starts at move 1. So that would have to be fixed as well.

[H.G.Muller]

Well, I couldn't resist giving it a try, as practically all the required code was already there. Parsing PVs had to be done when you click them for dsplay in the engine-output. And each move in them was converted to SAN then, for display above the board, needed for advancing the game along the PV in analysis mode. So I only had to write a small piece of code to invoke all that, and then collect all the SAN moves.

I uploaded a new version to http://hgm.nubati.net/WinBoard-4.5TM.exe , which implements the (volatile) options -fSAN and -sSAN, which switch on converting the PV field in the thinking output of the applicable engine to SAN, before processing it further. (This SAN includes move numbers.) They are intended for use on engines that produce PVs in long-algebraic format (such as Fairy-Max, or engines run through UCI2WB) If they encounter something they don't understand in the engine PV, the relay the remaining part of it verbatim. (I could not test that, as I did not have such an engine at hand.)

This is meant as a 'proof of principle' only. I will still have to contemplate how to embed this in a more logical structure of PV manipulations, (e.g. if we also want an opion to force long algebraic or other formats, such as WXF or PSN), and how to let the user control these. (E.g. by SAN and MoveNumber buttons in the Engine-Output window?) Furthermore, use of this option might be costly in terms of CPU usage, as the current implementation is horribly inefficient. So you are adviced to not use these options, unless badly needed.