hgm wrote:SAN is utterly unsuitable as move format for in a comminication protocol, and should be outlawed. The fact that you are allowed to send moves as SAN is the biggest mistake of XBoard protocol. This is one thing where UCI got it right...
+1000
Including SAN in the xboard protocol was a blunder of gigantic proportions. It bloated software for no reason whatsoever. It was a magnet for bugs and GUI tantrums. Some GUI refused to correctly managed the "+" (check), since it required extra code that could potential slow down the process. This made some engines hang, since technically they were sending "illegal" moves (a check without a "+"). It is good for human communication, but for computers it is not.
Even though Gaviota's SAN input/output is correct, when I set Gaviota to use "e2e4" format by default, many of the headaches went away. The other option would have been to accept "non-standard" SAN and make the code even more bloated.
Miguel
How does it bloat code? To require coordinate notation bloats code, since an engine ought to use SAN to display moves and PVs to the player. Now we need a second block of code to output in a second format. That seems more like code bloat than using SAN does..
As far as SAN goes, one CAN write a SAN parser that does not require the check (+) indicator. I did the same for castling since even ChessBase can't manage O-O (oh-oh) as opposed to o-o (lowercase oh-oh) or 0-0 (zero-zero). Software engineering says improper input should not cause crashes or misbehavior when possible, so accepting all of those is reasonable.
"slowing down" is pretty much irrelevant. So you add a few nanoseconds. Who can measure that?
hgm wrote:SAN is utterly unsuitable as move format for in a comminication protocol, and should be outlawed. The fact that you are allowed to send moves as SAN is the biggest mistake of XBoard protocol. This is one thing where UCI got it right...
+1000
Including SAN in the xboard protocol was a blunder of gigantic proportions. It bloated software for no reason whatsoever. It was a magnet for bugs and GUI tantrums. Some GUI refused to correctly managed the "+" (check), since it required extra code that could potential slow down the process. This made some engines hang, since technically they were sending "illegal" moves (a check without a "+"). It is good for human communication, but for computers it is not.
Even though Gaviota's SAN input/output is correct, when I set Gaviota to use "e2e4" format by default, many of the headaches went away. The other option would have been to accept "non-standard" SAN and make the code even more bloated.
Miguel
How does it bloat code? To require coordinate notation bloats code, since an engine ought to use SAN to display moves and PVs to the player. Now we need a second block of code to output in a second format. That seems more like code bloat than using SAN does..
Reading SAN does not use the same code for writing. And besides, for a good protocol, it should be up to the GUI to display the moves.
As far as SAN goes, one CAN write a SAN parser that does not require the check (+) indicator. I did the same for castling since even ChessBase can't manage O-O (oh-oh) as opposed to o-o (lowercase oh-oh) or 0-0 (zero-zero). Software engineering says improper input should not cause crashes or misbehavior when possible, so accepting all of those is reasonable.
Then, you are asking to have a protocol standard that should be violated. Before doing that, I prefer to stick to e2e4.
"slowing down" is pretty much irrelevant. So you add a few nanoseconds. Who can measure that?
Ask the GUI writers. That is the reality for the engine programmer, they do not comply and then I need to accommodate them. No.
bob wrote:I have seen programs output bogus coordinate output as well. Doesn't mean that because someone can't do it right then it should not be done period.
Interesting point. To my delight such line of reasoning, in conjunction with the other endorsements for using SAN at the engine level, can then without even as much as a shred of doubt, also be used to support the addition of traditional English Descriptive Notation to TSCP. And one shall not forget about letting the distinguished program use Roman Numerals for its move numbering and spell out the evaluations in easy to read English (of course always from White's perspective). Maybe newbies would be interested to learn about the Auto232 protocol as well when they encounter this program so it could be added.
That, or perhaps, as some have humbly suggested but not all have taken notice, time moves forward and UCI has made a wise and righteous design choice? Surely, newly written SAN-supporting engines are not a common sight in these days anymore? Those programmers can't be all wrong by embracing the separation of concerns that the UCI protocol provides, letting the GUI worry about human interaction in general and SAN specifically?
Which leads me back to the original topic, as in in that context I would have suggested that TSCP, in order to regain some of the educational and inspirational value it once possessed, would first and foremost benefit from a conversion to bit boards and the adoption of the UCI protocol as its sole interface. But then it would cease to be TSCP of course.
hgm wrote:SAN is utterly unsuitable as move format for in a comminication protocol, and should be outlawed. The fact that you are allowed to send moves as SAN is the biggest mistake of XBoard protocol. This is one thing where UCI got it right...
+1000
Including SAN in the xboard protocol was a blunder of gigantic proportions. It bloated software for no reason whatsoever. It was a magnet for bugs and GUI tantrums. Some GUI refused to correctly managed the "+" (check), since it required extra code that could potential slow down the process. This made some engines hang, since technically they were sending "illegal" moves (a check without a "+"). It is good for human communication, but for computers it is not.
Even though Gaviota's SAN input/output is correct, when I set Gaviota to use "e2e4" format by default, many of the headaches went away. The other option would have been to accept "non-standard" SAN and make the code even more bloated.
Miguel
How does it bloat code? To require coordinate notation bloats code, since an engine ought to use SAN to display moves and PVs to the player. Now we need a second block of code to output in a second format. That seems more like code bloat than using SAN does..
Reading SAN does not use the same code for writing. And besides, for a good protocol, it should be up to the GUI to display the moves.
Don't use your program in console mode for debugging? I do. Don't print moves as the tree is searched when debugging? I do.
As far as SAN goes, one CAN write a SAN parser that does not require the check (+) indicator. I did the same for castling since even ChessBase can't manage O-O (oh-oh) as opposed to o-o (lowercase oh-oh) or 0-0 (zero-zero). Software engineering says improper input should not cause crashes or misbehavior when possible, so accepting all of those is reasonable.
Then, you are asking to have a protocol standard that should be violated. Before doing that, I prefer to stick to e2e4.
Matter of taste I suppose. I'm not going to require a human to follow the standard precisely, unless it is necessary. If "+" is needed to disambiguate, I'll require it, otherwise it is optional. I certainly don't want to display moves in one format, and input them in another. I quite often take output from my program, save it to a file, and then use it as input. And again, now you have to output moves in two different formats assuming you have the ability to write PGN output. And you have to input two different forms assuming you have the ability to read PGN input. Seems ridiculous to me.
"slowing down" is pretty much irrelevant. So you add a few nanoseconds. Who can measure that?
Ask the GUI writers. That is the reality for the engine programmer, they do not comply and then I need to accommodate them. No.
bob wrote:I have seen programs output bogus coordinate output as well. Doesn't mean that because someone can't do it right then it should not be done period.
Interesting point. To my delight such line of reasoning, in conjunction with the other endorsements for using SAN at the engine level, can then without even as much as a shred of doubt, also be used to support the addition of traditional English Descriptive Notation to TSCP. And one shall not forget about letting the distinguished program use Roman Numerals for its move numbering and spell out the evaluations in easy to read English (of course always from White's perspective). Maybe newbies would be interested to learn about the Auto232 protocol as well when they encounter this program so it could be added.
That, or perhaps, as some have humbly suggested but not all have taken notice, time moves forward and UCI has made a wise and righteous design choice? Surely, newly written SAN-supporting engines are not a common sight in these days anymore? Those programmers can't be all wrong by embracing the separation of concerns that the UCI protocol provides, letting the GUI worry about human interaction in general and SAN specifically?
Which leads me back to the original topic, as in in that context I would have suggested that TSCP, in order to regain some of the educational and inspirational value it once possessed, would first and foremost benefit from a conversion to bit boards and the adoption of the UCI protocol as its sole interface. But then it would cease to be TSCP of course.
Cease with the hyperbole. You have not seen ME suggest multiple forms of input or output, multiple protocols, multiple anything in fact. I want just ONE. Most humans want SAN not coordinate notation. PGN specifies SAN although many do not follow that. I want to keep it simple. If English Descriptive were the common format (as it was when I started in the late 60's) then I would use ONLY that...
bob wrote:Most humans want SAN not coordinate notation.
Unfortunately most end users want to see figurine notation and not SAN. And when they must read SAN, they typically want to read it in their own language. Luckily, with the emerging UCI standard (it has gained a lot of traction this century), these end users don't have to see the notation that engines put out, also not in PV, because their GUIs and adapters fully take care of it. Therefore no engine writer has to bother with SAN in order to please the end user, unless he considers him or herself as the end user and s/he prefers to pound away in the console window. But that is hardly a typical use case, but I agree that in the case of Crafty that is probably a different matter. But not for TSCP if it is to be used as a demonstration engine? There SAN is certainly out of place.
hgm wrote:SAN is utterly unsuitable as move format for in a comminication protocol, and should be outlawed. The fact that you are allowed to send moves as SAN is the biggest mistake of XBoard protocol. This is one thing where UCI got it right...
+1000
Including SAN in the xboard protocol was a blunder of gigantic proportions. It bloated software for no reason whatsoever. It was a magnet for bugs and GUI tantrums. Some GUI refused to correctly managed the "+" (check), since it required extra code that could potential slow down the process. This made some engines hang, since technically they were sending "illegal" moves (a check without a "+"). It is good for human communication, but for computers it is not.
Even though Gaviota's SAN input/output is correct, when I set Gaviota to use "e2e4" format by default, many of the headaches went away. The other option would have been to accept "non-standard" SAN and make the code even more bloated.
Miguel
How does it bloat code? To require coordinate notation bloats code, since an engine ought to use SAN to display moves and PVs to the player. Now we need a second block of code to output in a second format. That seems more like code bloat than using SAN does..
Reading SAN does not use the same code for writing. And besides, for a good protocol, it should be up to the GUI to display the moves.
Don't use your program in console mode for debugging? I do. Don't print moves as the tree is searched when debugging? I do.
Yes, but it is irrelevant to my point. A protocol should not mandate what you may or may not want to do for debugging or any other that is beyond the scope of the communication with the interface (the point of the protocol).
Miguel
As far as SAN goes, one CAN write a SAN parser that does not require the check (+) indicator. I did the same for castling since even ChessBase can't manage O-O (oh-oh) as opposed to o-o (lowercase oh-oh) or 0-0 (zero-zero). Software engineering says improper input should not cause crashes or misbehavior when possible, so accepting all of those is reasonable.
Then, you are asking to have a protocol standard that should be violated. Before doing that, I prefer to stick to e2e4.
Matter of taste I suppose. I'm not going to require a human to follow the standard precisely, unless it is necessary. If "+" is needed to disambiguate, I'll require it, otherwise it is optional. I certainly don't want to display moves in one format, and input them in another. I quite often take output from my program, save it to a file, and then use it as input. And again, now you have to output moves in two different formats assuming you have the ability to write PGN output. And you have to input two different forms assuming you have the ability to read PGN input. Seems ridiculous to me.
"slowing down" is pretty much irrelevant. So you add a few nanoseconds. Who can measure that?
Ask the GUI writers. That is the reality for the engine programmer, they do not comply and then I need to accommodate them. No.
hgm wrote:SAN is utterly unsuitable as move format for in a comminication protocol, and should be outlawed. The fact that you are allowed to send moves as SAN is the biggest mistake of XBoard protocol. This is one thing where UCI got it right...
+1000
Including SAN in the xboard protocol was a blunder of gigantic proportions. It bloated software for no reason whatsoever. It was a magnet for bugs and GUI tantrums. Some GUI refused to correctly managed the "+" (check), since it required extra code that could potential slow down the process. This made some engines hang, since technically they were sending "illegal" moves (a check without a "+"). It is good for human communication, but for computers it is not.
Even though Gaviota's SAN input/output is correct, when I set Gaviota to use "e2e4" format by default, many of the headaches went away. The other option would have been to accept "non-standard" SAN and make the code even more bloated.
Miguel
How does it bloat code? To require coordinate notation bloats code, since an engine ought to use SAN to display moves and PVs to the player. Now we need a second block of code to output in a second format. That seems more like code bloat than using SAN does..
Reading SAN does not use the same code for writing. And besides, for a good protocol, it should be up to the GUI to display the moves.
Don't use your program in console mode for debugging? I do. Don't print moves as the tree is searched when debugging? I do.
Yes, but it is irrelevant to my point. A protocol should not mandate what you may or may not want to do for debugging or any other that is beyond the scope of the communication with the interface (the point of the protocol).
It should also not require jumping through unusual hoops to send anything. For example, suppose you want to be able to send floating point numbers? People are used to xxx.yyy, or x.yyyEnn. Should the GUI force me to convert that to Vax floating point format? Much more concise to use that sort of format (IEEE, etc).
A GUI should not get in the way of communication, it should facilitate it.
Miguel
As far as SAN goes, one CAN write a SAN parser that does not require the check (+) indicator. I did the same for castling since even ChessBase can't manage O-O (oh-oh) as opposed to o-o (lowercase oh-oh) or 0-0 (zero-zero). Software engineering says improper input should not cause crashes or misbehavior when possible, so accepting all of those is reasonable.
Then, you are asking to have a protocol standard that should be violated. Before doing that, I prefer to stick to e2e4.
Matter of taste I suppose. I'm not going to require a human to follow the standard precisely, unless it is necessary. If "+" is needed to disambiguate, I'll require it, otherwise it is optional. I certainly don't want to display moves in one format, and input them in another. I quite often take output from my program, save it to a file, and then use it as input. And again, now you have to output moves in two different formats assuming you have the ability to write PGN output. And you have to input two different forms assuming you have the ability to read PGN input. Seems ridiculous to me.
"slowing down" is pretty much irrelevant. So you add a few nanoseconds. Who can measure that?
Ask the GUI writers. That is the reality for the engine programmer, they do not comply and then I need to accommodate them. No.
The purpose of the communication protocol is to get information across in a compact way that is not bug-prone. It is upto the GUI to present this information to the user, in a format that the user prefers.
GUI = user interface
protocol = engine interface
What you do in console mode to debug is a separate issue. I usually support all kind of commands and output for that that trancends the protocol. And I never print moves in SAN. Sometimes I print them in coordinate notation, but in fact I hardly ever look at that. I always print them in hexadecimal, (so I can see if any flags in there are properly set, and what the sort key is), and that is the format I typically use to select branches from the tree.
