PGN standard, its improvement and standardization

[sovaz1997]

...

The main thing for me is to unify the formats of online tournaments, I am not going to compete with anyone, since it is impossible to do better than ChessBase alone, and the main goal is different

Well, the 'online tournaments' will always invent new formats
(TCEC, CCCC, you name it)

And also: Arena, Cutechess, TLCV, ChessBase, Octagon.. How many GUIs do we have that hold tournaments for engines? Everyone has their own vision. It would be easier to have one extensible format for this with one basic part, it seems to me.

[DustyMonkey]

Sure, users wont program their own parser.

Authors do that. There are fewer authors than there should be, because parsing pgn requires a full bug free move generator, and therefore there are fewer programs for those users to enjoy.

PGN wasnt meant for automated computer consumption. Excuses, that in reality harms the very people being invoked as the important ones, for the weaknesses of pgn as an interchange format, doesnt add anything to the discussion.

To quote from a comment in the cited reddit thread, which backs up what I just said:

"Considering how old and ubiquitous the format is, the quantity and quality of open source tools and libraries are abysmal. Most implementations seem to suffer from various subtle bugs and/or don't support the entirety of PGN"

To add to the discussion:

What you do not want is a pgn replacement. What you want is an open fit-for-purpose format. The purpose being the interchange of games and annotations between programs. If you try to replace pgn it will fail because then the format has to be at least everything that pgn is, which is contrary to the goal of leaving pgn behind as an interchange format.

[hgm]

The goal is to add the values of the engines to the game file. Moreover, the engine can be far from one.

Thus, you can get some unification of online tournaments, and then use a separate client to view the tournaments (with eval schedules, etc.). Well, and view games offline. And I want to unify so that it is just more convenient for everyone to use this.

But the problem is not so much that de-facto standards that can do this do not exist. They do exist, but people are just not willing to use them, and prefer to improvise their own stuff. This cannot be cured by designing more standards.

Engine evals, depth, tablebase hits, etc. are just comments to the move, made by an engine (which could be the player). The original PGN standard does supply a mechanism for including comments. So it seems logical to use it for this purpose. It is designed to be able to hold arbitrary information, so it should not be a problem if that information happens to be engine 'thinking output'.

People can use existing conventions for this, so that off-line viewing of the type you aim for is possible with existing software. It rarely happens that displaying the engine info in text form (like any other comment) would not be fully satisfactory. Perhaps for evals it would be useful to present them as a graph, and to achieve that the viewer software should be able to somehow recognize it in the comment. But that is really an exceptional case. Most people would not care a hoot about things like (say) TBhits or % hash usage anyway.

If a tourney organizer deviates from the de-facto standards it is most likely intentional, because they do not consider it to be in their interest that people can do what you sketch. If it is accidental, a better course would be to convince them to use an existing de-facto standard than first to define a new standard and then have to convince them to use that.

[Fulvio]

The main thing for me is to unify the formats of online tournaments

That can be done with the current PGN.
You already posted how TCEC encode the engine's evaluation:
d=16, sd=51, mt=161000, tl=7049000, s=219832, n=35024512, pv=Nb3 ...
But is the order of the operands mandatory?
sd=51, d=16, ... is acceptable?
If you create a table with columns "depth", "selective depth", etc...
and rows "TCEC", "CCRL", "lichess", etc...
it will greatly help you in identifying the commonality and the differences.

Then you can create a sort of "normalizer" which will convert all those different ways of encoding the engine's output to the "perfect" new PGN way (which would still probably be inside a comment:
{user comment [%engine d: 16, sd: 51, ....]}
or maybe using the % at the start of a newline, but old programs may have problems with long lines:
{user comment}
%engine d: 16, sd: 51, ...
)

[Dann Corbit]

PGN is intended as a format to interchange games between humans on text-based media (such as web pages). Binary formats are suitable only for storage in databases. As Guenther points out, several well-developed formats for this purpose already exist, and are in wide-spread use.

If you think you can design better database programs than scid or chessbase, by all means, go ahead. But it has absolutely nothing to do with PGN, and being completely ignorant of what you will be competing against doesn't seem a promising starting point.

Regarding: "several well-developed formats for this purpose already exist, and are in wide-spread use."

The existing formats are poorly developed, poorly designed, and poorly documented. Furthermore, they are terribly flawed.
Scid croaks when you give it too much data (and too much is not very big). ChessBase is a moving target and many of the sub-formats are poorly documented. How do you turn a ChessBase opening book into PGN? There are some programs that attempt it. But none fully succeeds. How do we store statistics into these chess formats? How do we store evaluation data into these formats?

The right place to store chess data for empirical study via computers is in a database.
I think we should also store UCI and Xboard parameters in a database and standardize it.
I think we should also combine UCI and Xboard into a homogeneous interface, taking the best parts of both standards.
(Xboard is better for gameplay and learning because you can have stateful game progress, whereas UCI is stateless)
I also think it would be a good idea to layer CQL over top of SQL as an alternative interface.
https://www.chessprogramming.org/Chess_Query_Language

I think it would be good to perform a query that will tell us which openings over-perform as a function of Elo and which under-perform?

But I guess most of these things will not happen.

[sovaz1997]

Ok, I decided to try writing my GUI: https://github.com/sovaz1997/ZevraGUI for offline viewing of the TCEC games and games from alternative SuFi (with position evals, etc.). I admit that then it will be a full-fledged GUI with many features. I never wrote in PyQT5, this is my first project. So far, only the board has been implemented and moving back and forth. Now in the foreground is the functionality.

[phhnguyen]

...
Xboard is better for gameplay and learning because you can have stateful game progress, whereas UCI is stateless
...

Your thought is interesting! However, it is not clear to me. How come it (Xboard) is better than UCI on gameplay/learning? Can you explain more?
Lc0 is a UCI engine and it can train itself a lot. Do you think Lc0 can get some more benefits if it uses XBoard protocol?

[Dann Corbit]

...
Xboard is better for gameplay and learning because you can have stateful game progress, whereas UCI is stateless
...

Your thought is interesting! However, it is not clear to me. How come it (Xboard) is better than UCI on gameplay/learning? Can you explain more?
Lc0 is a UCI engine and it can train itself a lot. Do you think Lc0 can get some more benefits if it uses XBoard protocol?

LC0 does not train during game play. It trains during training sessions.

An Xboard engine just gets the move to play. And so it maintains a state. A UCI engine gets the entire board position sent each time.
I think it is possible to make a UCI engine know the state, but it takes more work because it is not part of the design.

[Robert Pope]

Also, I believe that UCI doesn't send a game result/end game flag to the engine, so if you are doing any post-game processing, you have to infer when this occurs, rather than being told explicitly.

[phhnguyen]

LC0 does not train during game play. It trains during training sessions.

An Xboard engine just gets the move to play. And so it maintains a state. A UCI engine gets the entire board position sent each time.
I think it is possible to make a UCI engine know the state, but it takes more work because it is not part of the design.

That is only the problem of how to sync a UCI engine when receiving a list of moves. I think for anyone who needs to keep all internal states he may simply match that list with current move history, if all matched, all internal states can be kept. In normal cases, there is not different between UCI-XB engines in keeping states. However, only UCI engines have the chance to sync again with chess GUIs in broken/complicated cases.

IMO, implementation UCI protocol is a bit harder (than XB one) in the old day when multi-threads is not popular. But nowadays with multi-thread programming, it makes UCI become easier than WB. On the other hand, like a chess GUI developer, supporting XB takes me at least twice time/labor as UCI one.