From: "Jeroen J.-W. Tiggelman" HDETUD2 TUDELFT NL> Date: 28 may 1996 Subject: Conversion of notations Hi all, After the dismaying disagreements about the notations we have seen in the past, I decided to think about the possibility of automating move conversion between systems. The conclusion I reached so far, is that it is quite feasible to write a program to the purpose which will run on (any) MS-DOS; both input and output will be in ASCII, and it is assumed that this is from and to file (I don't want to build all sorts of loops for correcting typing mistakes :-)). First of all, there is the issue of designing the format of the input and output. I have already exchanged ideas with Mr. Iwakura about this, but I would like to hear any thoughts on the subject. What I have in mind right now is this: * There must be a way to specify a position. A position consists of a list of pieces with their squares (or "in hand") and owners, plus which player is to move. I suggest - Keyword "GAME=" to indicate a position follows, followed by (*3*) - A pair (,POSITION=), where is either SENTE or GOTE (*1*) is a list (indicated by brackets) containing the names of pieces and their positions like this: GYOKU=(59S,51G) (*1*) (*2*) indicating that _S_ente's king is on 59 (5i), and _G_ote's king is on 51 (5a). To indicate "in hand", supply "S" or "G" only. To indicate "promoted" add a "+". ==> The starting position could be written like this: GAME=(SENTE,POSITION=(GYOKU=(59S,51G),KIN=(49S,69S,41G,61G), GIN=(39S,79S,31G,71G),KEIMA=(29S,21G,89S,81G), KYOSHA=(19S,11G,91G,99S),HISHA=(28S,82G),KAKU=(88S,22G), FU=(57S,67S,47S,77S,37S,87S,27S,97S,17S, 53G,63G,43G,73G,33G,83G,23G,93G,13G)) ==> You do not have to specify all the pieces, but you cannot specify more pieces of a type than can be in the game, and you cannot specify more than one piece on a square. The order of the names of the pieces is immaterial, and you need not specify all pieces of the same type together. Pieces not specified are not in the game. ==> Because this is a lot of typing, we will introduce some abbreviations. To indicate a starting position, write GAME=(START,HANDICAP=), where can be one of "NONE", "L", "B", "R", "R+L", "2P", "4P", "6P". (*2*) To indicate a tsume problem (assumed: the white king is to be mated, it is _not_ a handicap game), write GAME=(TSUME,POSITION=) and the program will assume all pieces not mentioned to be in White's hand. (Except Black's King, of course.) * There must be a way to specify the input format, so that the program need not guess about it; and there should be a way to specify the output format. We will use the keyword commands INPUT= and OUTPUT= for this. Their usage is as follows: - INPUT=(), where specifies keyword parameters separated by commas. We define the following keyword parameters: - either JAPANESE or WESTERN is required The notations I mean are supposed to be clear; if you can think of important variations, yell. - required parameter: NUMBERS=, where is one of NONE, SINGLE, PAIRS. SINGLE counts the moves, whereas PAIRS uses the western style "," format. For any of the latter two possibilities it is also allowed to specify NUMBERS=(,) to start counting at instead of 1. - (OUTPUT only) required: FORMAT=, where is either "COLUMNS" (indicating that the moves should be formatted into two columns, which will additionally have the effect on the Western notation of aligning as much as possible, leaving a space before an unpromoted piece, an inserting "-"s and aligning commas and move numbers) or a number (indicating the number of columns to be used, which will have the additional effect that everything will be packed as tightly as possible, dropping "-"s etc.) - (OUTPUT only) optional: DROPCHAR= specifying the character to indicate a drop. I intend to make the apostrophe (') the default. It is mandatory you specify these formats before specifying any moves. However, I will allow the statement OUTPUT=DIAGRAM before the specification of either. This is really a different command, which will not alter the currect format, but just dump the current game position in diagram form to the output file. For the packed move format, I haven't really considered whether to break off the current line, or insert a reference to the diagram and print it after the current line is complete. (Printing it after the entire score is an option I do not like in connection with some other features I planned.) Let me hear you about this! * In addition to "OUTPUT=DIAGRAM" to write a diagram, I also consider the addition GAME=(,DIAGRAM) to read such a diagram. This is not planned for the initial implementation, but as a future extension. Also the keyword "DIAGRAM" itself will identify a diagram that represents the present position (the current plan is to copy the starting position to the output file in a GAME statement, and the OUTPUT format as an INPUT= one, so that the output file can be used as input with only specifying a new output format -- but diagrams should be skipped :-)). * To be able to translate a game score with embedded comments, it must be identified which parts are comments. I suggest that this is easiest done by adding the keyword commands COMMENTS and SCORE to switch back and forth. These would form one set with DIAGRAM. You will have to add these to the input file; and unless you convince me it is worth another option to be able to suppress the data written to the output file to make it a near-valid input file, you will have to delete them yourself from them as well. --> Note that I currently do not plan to scan the comments for the presence of piece names or fields; you will need to adapt the comment sections yourself -- I plan to copy them as-is. * To be able to investigate a (number of) variation(s), I suggest to add the following three keywords: MEMORIZE (i.e., push the current position on a stack) RECALL (i.e., retrieve the last memorized position; no pop) RESUME (i.e., pop the last memorized position from the stack) To investigate a variation, issue "MEMORIZE" at the split point, and RESUME where you want to resume the main line of play. If you want to investigate several variations use MEMORIZE at the split point, RECALL to investigate the next variation from the last split point, and RESUME to resume the main line. Programmers will note that RECALL is just short-hand for "RESUME-MEMORIZE" :-)). --> This works recursively. If you use another MEMORIZE you can study sub-variations. In this case RESUME will then return to the main variation, and a later RESUME to the main line. --> To look at another game with a similar position, or maybe a tsume or tesuji position in the middle of a game score, you can use MEMORIZE to save the game position, GAME= to load the other position and RESUME to return to the first game. I expect there are some things I have not yet addressed here, and in any case I expect some input. As for the coding, I don't think I need a whole lot of advice; if you would be interested in my ideas on the implementation, however, we can certainly discuss them. :-) Note that I have other things to do as well, so it might take a while before I have actually written the program _after_ we have established the way it works. :-) Regards, Jeroen Tiggelman P.S. I am somewhat in dount what to do after an error has occurred. On the one hand, it is annoying to find only one mistake per run, on the other hand, after the omission of, say, "COMMENT", you probably do not want a flood of resulting errors. Suggestions in this area are very welcome. For now, I will simply assume that the input is correct, and if it isn't, you'll get an error - pity. :-) BTW, an ambiguous move will be counted as an error; for now I do not plan to try to resolve it from the following moves. ;-) P.P.S. The current meaning of "diagram" is similar to the ones I hear are used on the ladder. The "b" indicating Sente is scheduled for omission, though. Differently formatted diagrams may be added in the future; I do not plan to try and generate Kanji on a system that does not support Kanji unaided, however. (*1*) Thoughout the program, the following indications will always be considered equivalent: SENTE S BLACK B GOTE G WHITE W (*2*) Throughout the program, the following indications will always be considered equivalent: GYOKU GYO KING K KIN GOLD G GIN SILVER S (Note that "G" is _not_ "GIN") KEIMA KEI KNIGHT N KYOSHA KYO LANCE L HISHA HI ROOK R KAKU KAK BISHOP B FU PAWN P (*3*) Throughout the program, keyword commands - should start in column 1 - are not case sensitive - are not sensitive to the presence of spaces, tabs or line breaks, as long as they do not occur in the middle of a word or token (e.g., "52S+" may not be broken).