Author: Andreas Guettinger
Date: 02:14:26 06/11/04
Go up one level in this thread
On June 11, 2004 at 02:14:42, Russell Reagan wrote: >On June 10, 2004 at 21:01:00, Anthony Cozzie wrote: > >>I am going to summarize my viewpoint here, and leave it at that. Ultimately it >>is your format, so you can do whatever you want with it. I am just trying to >>give you some advice. >> >>You have 3 options: SAN, Coordinate, and Long SAN >> >>SAN Advantages: Easy for humans to read >>SAN Disadvantages: Relatively difficult to parse. See epd.c. >> >>Coordinate Advantages: Easy to parse (1 line). >>Coordinate Disadvantage: Difficult for humans to read >> >>Long SAN Advantages: Pretty easy for humans to understand >> Easy to parse (1 line) >>Long SAN Disadvantages: 2 extra characters over coordinate. > > >This isn't really accurate, is it? Long algebraic is mostly the same static >conversion that coordinate notation is, but what about checking moves? How about >a discovered check? I think that requires some dynamic computing involving the >board/movegen/make/undo, just like SAN. To get it right, I would end up making >the move and seeing if the king is attacked after the move. Handling that >statically seems very error prone. > >Of course I haven't implemented this particular notation. Is there another less >complicated way to handle checks? If you have to implement a chess engine to >parse long algebraic, then it is no better than SAN in that regard. >>You and Russel say that no one is supposed to be reading these files. I say why >>go out of your way to make it hard? Why throw away something that you can get >>for free? I can think of any number of scenarios where it would be useful to >>look in the file. For example, Zappa makes a questionable move, so I go back >>and grep for the move. Then I can read score, ply, PV, etc. I don't know about >>you, but I can follow at least 8-10 ply of a PV if it is SAN. > > >This isn't an advantage of using any notation over any other. You are >arbitrarily most familiar with SAN, and so you could follow 8-10 moves in SAN. >What if you had grown up using descriptive notation? Maybe the next guy can >follow 20 moves of descriptive notation. Is that a reason supporting the use of >it in a data standard? > >Also, remember that we are discussing one data standard here. We are not >discussing the one notation that everyone must use from now on. If the standard >adopts coordinate notation, does that prevent you from dumping out your own file >with long algebraic notation? > > >>I simply do not see any advantage to coordinate notation over long SAN. Let me >>make this clear: coordinate is not easier to parse for computers, but it is much >>more difficult for humans to understand. The *only* advantage of coordinate >>notation that you save 2 bytes. Coordinate is not too bad when you have the >>board in front of you, but when you are recalling something from memory it is >>much worse. >> >>The (obvious) international solution is simply to allow any piece type. You are >>free to write Xf3xe5 Vd6-d5 or any other random characters you like. The piece >>letter is for the human. The only issue is the promotion type, but you'll have >>to worry about that anyway for coordinate notation. >> >>What it comes down to is this: is there _any_ point where coordinate is better >>than Long SAN? >> >>anthony > > >We just have different initial assumptions. I put simplicity above readability. >You put readability above simplicity. > >It is very clear why we disagree based upon that. Watch. > >Higher numbers are better. > >Coordinate >Simplicity = 3 >Readability = 1 > >SAN >Simplicity = 1 >Readability = 3 > >Long Algebraic >Simplicity = 2 >Readability = 2 > >I don't think human readability of the moves even matters, since the moves will >be crammed in the middle of a dozen other lines of XML >(http://www.talkchess.com/forums/1/message.html?369824). Effective readability >for all move notations goes into the toilet for me in the middle of that kind of >XML file. > >Since that is my stance, remove readability from the picture, and we have: > >Coordinate >Simplicity = 3 > >SAN >Simplicity = 1 > >Long Algebraic >Simplicity = 2 > >And coordinate notation wins. At least, that explains why we disagree. > >If you can show that long algebraic is a static notation like coordinate >notation, then I don't have any problem with it. I'm interested to find out how >you handle the discovered check situation. If you need a movegen or not doesen't matter. Every raw data creating machine (input device, chess engine, Java board etc.) has to check for the legality of moves, so this data is already present. The important thing is to provide as many possible data in the raw file for the parsing. A convertor can remove the check signs easily, but if he has to add them he must have a move generator. And coordinate -> SAN is what a lot of people is what they wnat to do visualize the games. Why creating a JPEG image if you want to convert it to TIFF? Loss of data is always bad, especially if the additional data comes for free. To summarize: long algebraic: convertion to coordinate noatation: easy convertion to SAN notation:: easy About the xml tags: every decent editor has an function "Hide markup language" or something. About internalisation: English is the way to go. My mother langauge is german, but i don't even know the german signs for PNBRQK. FEN also uses the same letter code. regards Andy
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.