allowing invalid positions

[lucasart]

I agree it would be nice if the UCI protocol would standardize basic move inputs.

It would be nice if the UCI protocol used SAN moves and not the bulky, hard-to-read e2e4 c7c5 g1f3 d7d6 coordinate notation which went out of style forty years ago.

SAN is the worst possible choice for the protocol. It is a format for humans to read, but an absolute nightmare to read/write for a program. It would force all GUI and especially all engine authors to have to write some bulky SAN read/write into their program.

The only place for SAN is when you display something to the user, in a GUI. Nothing more.

Even the PGN standard, if it was up to me, I would never have made it as complicated and hard to parse as it is. And I see no good reason to use SAN in the PGN. A PGN is a file for programs to read, nothing forbids them to display something in SAN to the user after.

It is very fortunate that you did not participate in the elaboration of the UCI protocol.

[michiguel]

I agree it would be nice if the UCI protocol would standardize basic move inputs.

It would be nice if the UCI protocol used SAN moves and not the bulky, hard-to-read e2e4 c7c5 g1f3 d7d6 coordinate notation which went out of style forty years ago.

SAN is the worst possible choice for the protocol. It is a format for humans to read, but an absolute nightmare to read/write for a program. It would force all GUI and especially all engine authors to have to write some bulky SAN read/write into their program.

The only place for SAN is when you display something to the user, in a GUI. Nothing more.

Even the PGN standard, if it was up to me, I would never have made it as complicated and hard to parse as it is. And I see no good reason to use SAN in the PGN. A PGN is a file for programs to read, nothing forbids them to display something in SAN to the user after.

It is very fortunate that you did not participate in the elaboration of the UCI protocol.

The PGN standard, on the other hand, was specifically designed to be read by both, computers and humans. There were very good reasons for it at the time, and still today. In fact, I started to hate when there was a modification and people started to add some %emt thing that made it unreadable. I used to read it directly from the screen, but at one point it became impossible.

Miguel

[michiguel]

Generating SAN is fast and easy. To make it even faster, Symbolic has a routine which will scan a list of the moves for a position and determine which moves give check without actually doing an Execute()/Retract() cycle. Another routine tests each checking move for being a checkmate, and this is fast because Symbolic uses a HasNoMoves() routine, highly optimized for this purpose.

Symbolic also handles notation generation for list of sequential moves. Each move has a set of move flags, and one of them indicates if the move has already had its four notation flags (check, checkmate. rank/file disambiguation) correctly set. Therefore, notation work is not done more than once for the same data.

When Symbolic handles user move input, that input can be a long sequence of sequential moves. Each is checked before the entire sequence is played on the main beard.

Yes, I have some fancy stuff too. That is the issue, a protocol should not impose an author to do fancy stuff when there is a light weight solution, and more is not needed. You can always do it yourself, but a author may have no intention to write an application for human interaction.

I cannot agree more with everything you say here.

Note the irony of on the one hand demanding that all engine authors start by implementing SAN and on the other hand dismissing the idea that engines should not crash on illegal input for the reason that it is the task of the GUI to filter out illegal positions.

I'll add that GUIs cannot realistically filter out all illegal positions (in theory it is certainly possible given that chess is finite, in practice it is silly) and cannot know what types of illegal positions happen to crash a given engine.

It would be nice that the engine had the option to reject a FEN, and the protocol should take that into account. The engine should be able to reject even legal positions! For instance, I could write a pedagogical engine that only mates with BN. Or a table base engine that works only with 5-6 pieces. In that case, the ability to reject a position will allow the system to end gracefully. What we have is a protocol is too narrow minded.

It is a bad idea to shove down the throat of an engine information that the engine has to like no matter what.

Miguel

[tpetzke]

I totally agree with my developer colleagues that for the communication with an engine LAN is perfect, SAN is not.

I really hated the fact that for a simple epd parser I had to have a board class with move generation logic just to translate the bm into my internal move format.

Thomas...

[lucasart]

I totally agree with my developer colleagues that for the communication with an engine LAN is perfect, SAN is not.

I really hated the fact that for a simple epd parser I had to have a board class with move generation logic just to translate the bm into my internal move format.

Thomas...

I know exactly what you're talking about: I hate EPD with a passion.

A while ago, I wanted to write a simple Python script that parses an EPD, and sends the positions one by one to an engine, and lets it search for a specified time, and compares the best move returned by the engine to the one in the EPD file. So you could do a WAC test for example. The advantage is that the script would be external tool, so it would be engine independant (also Python is much more high level than C/C++ and lets you do lots of high level code in a few lines w/o headache). Really, it would be just a "few" lines of code.

But I quickly realized that this project was going to turn into a big reinvention of wheels, when I realized that the idiotic EPD format specifies that best moves should be in SAN format, and that I had to write a SAN decoder, which implies that I almost had to write an entire chess engine in Python...

Frankly, I am shocked to see that people praise the supposedly great design of chess standard formats: PGN and EPD (recently Don thanked Steven for that). PGN and EPD are *worst* design I've ever seen, and I would have made a much simpler format if I could redo it (too late it's a de-facto standard now).

[michiguel]

I totally agree with my developer colleagues that for the communication with an engine LAN is perfect, SAN is not.

I really hated the fact that for a simple epd parser I had to have a board class with move generation logic just to translate the bm into my internal move format.

Thomas...

I know exactly what you're talking about: I hate EPD with a passion.

A while ago, I wanted to write a simple Python script that parses an EPD, and sends the positions one by one to an engine, and lets it search for a specified time, and compares the best move returned by the engine to the one in the EPD file. So you could do a WAC test for example. The advantage is that the script would be external tool, so it would be engine independant (also Python is much more high level than C/C++ and lets you do lots of high level code in a few lines w/o headache). Really, it would be just a "few" lines of code.

But I quickly realized that this project was going to turn into a big reinvention of wheels, when I realized that the idiotic EPD format specifies that best moves should be in SAN format, and that I had to write a SAN decoder, which implies that I almost had to write an entire chess engine in Python...

Frankly, I am shocked to see that people praise the supposedly great design of chess standard formats: PGN and EPD (recently Don thanked Steven for that). PGN and EPD are *worst* design I've ever seen, and I would have made a much simpler format if I could redo it (too late it's a de-facto standard now).

Regarding the bestmove in EPD it is debatable and you may be right. I already gave my opinino that a protocol should not have a SAN move for engine communication and you seem to be in sync with that. But you are missing the significance of PGN. There was a "before and after that standard" in computer chess, and it revolutionized the communication between databases, engines, and anything that has the word "computer" and "chess" in it.

See this:
http://www.mark-weeks.com/aboutcom/aa07e19.htm

"Portable Game Notation (PGN): It may seem unusual to include PGN in an account of Internet chess. The moves of a chess game are easy to digitalize, and the Internet made the data easy to transfer. Before PGN, every chess software vendor had a different way of encoding chess data. PGN, developed in 1993 by Steven J. Edwards, was discussed and disseminated via rgc. It became an immediate success because, as a readable text format, it satisfied the needs of people as well as of computers."

Moves needed to be in SAN because people were manipulating those by hand too. I can only imagine the thousands of games that were input into databases in that form, after either scanning, typing, or reformatting previous records.

The prove is really in its success.

In fact, SJE developed a more compact standard, a binary one. That was PGC, which never picked up and PGN was preferred.

Miguel

[lucasart]

"Portable Game Notation (PGN): It may seem unusual to include PGN in an account of Internet chess. The moves of a chess game are easy to digitalize, and the Internet made the data easy to transfer. Before PGN, every chess software vendor had a different way of encoding chess data. PGN, developed in 1993 by Steven J. Edwards, was discussed and disseminated via rgc. It became an immediate success because, as a readable text format, it satisfied the needs of people as well as of computers."

Moves needed to be in SAN because people were manipulating those by hand too. I can only imagine the thousands of games that were input into databases in that form, after either scanning, typing, or reformatting previous records.

The prove is really in its success.

In fact, SJE developed a more compact standard, a binary one. That was PGC, which never picked up and PGN was preferred.

Miguel

Yes, having a standard is a great thing, and it prevents vendor locking users into using their own format (vendors still do that with opening books, despite the popularity of the PolyGlot format).

The PGN format is basically reproducing the way chess books present chess games. This is nice because it means the games are human readable in text format.

Human readable was a requirement 20+ years ago, and is probably not a requirement today. Of course, people like you and me, still like to open a command line and open the PGN in a text editor, but most users want to open a PGN in a GUI and see the pieces moving on the board (whether the text is human readable or not, they don't care, and you can always display it in a text box that way to make some users happy).

The real problem is that the format has completely degenerated, and developped too tolerance against abuse by GUI developpers. The result is that pretty much anything was OK as far as generating PGN was concerned, and now it's a real mess, and writing a fully fledged PGN parser (that will accept PGN from all possible GUIs) is a real nightmare.