Question about Sjaak

[hgm]

Understanding SAN requires significant effort, through disambiguation

Well it is more or less trivial if you have a move generator. Which a chess engine must have anyway.

Far from it. It requires a significant amount of code in addition to the move generator, which otherwise would not be needed at all. SAN moves are variable length, so it requires you to identify if there is a piece ID, which characters are the to-square, if there are 0, 1 or 2 disambiguation characters, and whether these are rank or file disambiguators. Then you have to extract the corresponding ranks or files from the move representations in the move lists to compare them. The moves must be legal moves, while most engines use pseudo-legal move generation.

[Michel]

Understanding SAN requires significant effort, through disambiguation

Well it is more or less trivial if you have a move generator. Which a chess engine must have anyway.

Far from it. It requires a significant amount of code in addition to the move generator, which otherwise would not be needed at all. SAN moves are variable length, so it requires you to identify if there is a piece ID, which characters are the to-square, if there are 0, 1 or 2 disambiguation characters, and whether these are rank or file disambiguators. Then you have to extract the corresponding ranks or files from the move representations in the move lists to compare them. The moves must be legal moves, while most engines use pseudo-legal move generation.

It seems we have a different opinion on what is trivial. I consider regular expression parsing trivial, even without a dedicated library.

But honestly I don't understand your reaction at all. Many winboard engines implement SAN simply because it makes for a more pleasant console experience (so I disagree with you that SAN serves no purpose). If an engine understands SAN then icsdrone _can_ use this to offer a bit more functionality at no cost. I don't see why it shouldn't.

Recall that icsdrone is not a real GUI but an adapter between two entities: an ICS and an engine. So preferably it should do as little work by itself as possible. It is an unfortunate fact, but one we have to live with, that some ICS's use SAN in their reply to certain commands...

[hgm]

Obviously you are not representative for the beginning engine programmer. Trivial is a one-liner like

move = buf[0]-'a'<<8 | buf[1]-'0'<<12 | buf[2]-'a' | buf[3]-'0'<<4;

Now count the number of characters you would need to do the same thing for SAN.

I don't understand what 'extra functionality' you are talking about. Who cares in what format icsdrone sends moves to the engine? No one can see them.

I still think that only a very small minority of WB engines would understand SAN on input. Who cares how an engine runs from the console now there are GUIs? Do you think UCI would stand a chance for being used if people cared about running the engine from the console?

[Michel]

I don't understand what 'extra functionality' you are talking about.

I explained this already. To properly resume an adjourned game it is best to send a movelist to the engine (otherwise it may not see a 3-fold rep or a 50-move draw occurring at the point where the game was adjourned). ICC sends movelists in SAN.

Code: Select all

Who cares how an engine runs from the console now there are GUIs? 

A console is quite useful for debugging because you can make the engine understand all kinds of extra commands. When running an engine on a small device (e.g. an orange-pi) you will usually not even have a GUI available.

Even UCI engines sometimes have (undocumented) commands for debugging or other purposes. Winboard authors often take this one step further by providing a usable console.

[Evert]

A console is quite useful for debugging because you can make the engine understand all kinds of extra commands. When running an engine on a small device (e.g. an orange-pi) you will usually not even have a GUI available.

Even UCI engines sometimes have (undocumented) commands for debugging or other purposes. Winboard authors often take this one step further by providing a usable console.

SjaakII is almost fully useable from the console. It actually keeps track of its own clock so you can play against it in the console and it will manage its time properly (but it won't forfeit itself or the user). You normally don't notice because the time command overrides its own time keeping, and it doesn't print the remaining time in XBoard mode.
What is lacking is a way to review the game history and a way to load and save games...

[hgm]

I explained this already. To properly resume an adjourned game it is best to send a movelist to the engine (otherwise it may not see a 3-fold rep or a 50-move draw occurring at the point where the game was adjourned). ICC sends movelists in SAN.

You mean icsdrone can only resume adjourned games for engines that understand SAN? You would need the code for SAN->coordinate anyway if you also want it to work for normal WB engines.

[Michel]

You mean icsdrone can only resume adjourned games for engines that understand SAN?

No I did not say that. It can simply set up the current board (with setboard). There will be a small risk that the engine misses a 3-fold rep draw or a 50-move draw. The problem is only on ICC (and perhaps on your ICS?). FICS has an (undocumented) option to send movelists in coordinate notation. Probably because the original author of icsdrone (Henrik Gram) was one of the founders of FICS.

To get this functionality on ICC you need their proprietary level-2 protocol.

You would need the code for SAN->coordinate anyway if you also want it to work for normal WB engines.

Style <12> boards contain both SAN and coordinate notation.

[hgm]

Yes, I knew the latter. But I meant for resuming the adjourned game. But I had not thought about starting from the position, which you indeed would also get.

But I am surprised that that icsdrone doesn't have a SAN parser, considering what you said about regular expressions. If you think engines could easily implement it, why not implement it in icsdrone? A move generator is pretty trivial too, compared to parsing regular expressions.

In fact you don't even need a complete move generator, as things that normally complicate it, such as castling, can be simply string-matched, and have a context-independent meaning. (Well, apart from side to move, but I suppose you do keep track of that.) Otherwise the to-square is always fully specified, so you just have to find the from-square.

[Michel]

But I am surprised that that icsdrone doesn't have a SAN parser, considering what you said about regular expressions. If you think engines could easily implement it, why not implement it in icsdrone? A move generator is pretty trivial too, compared to parsing regular expressions.

Well I don't really want to implement the rules for all the variants supported by ICS's. For me icsdrone is just an intermediary. It has no chess knowledge.

[hgm]

I know how appealing that idea is (I use it for UCI2WB too), but for communicating with an ICS that might simply not be possible. But fortunately the rules for ICS variants are all pretty much the same. I guess the board update in Atomic is special, and the Shatranj Queen moves only 1 step diagonally, but that is about all the variant-dependence there is. Unless you want it to also play the variants on my ICS.