Author: KarinsDad
Date: 10:30:00 08/25/99
Go up one level in this thread
On August 25, 1999 at 03:17:07, Guido wrote: >In my e-mail I wrote: "without losing compatibility with the current format", >that means that >data can be manually loaded in both formats or also in a mixing of the two >formats. And how would this be lost if it was done in either of the two formats I posted? In fact, it would be easy to distinquish between my formats and FEN due to there not being any / characters in my formats. It would be more difficult to distinquish between your format and FEN since the program would not know that your format wasn't just an invalid FEN format? You would probably have to put a special character into your format to distinquish it. I guess you could ASSUME that if a FEN was sent that matched your format, but was invalid for FEN, that it was your format. However, there are examples where this would just be wrong such as: 7K/7P/7R/6k/7P/7N/7P/7R w. Is this a valid format of yours or an invalid FEN where the h5 square is missing? So, it seems that you would need a way to differentiate. > >Obviously if I want to check the number of squares per rank and the number of >ranks, I must >follow the current FEN format. This is not true. You could use either of the two formats I proposed: 2K52P586k13P483r2N18w OR 2K7P19k4P15r2N9w and the checking information would be maintained. > A switch can set/reset this option during input. How would the program know? Based on file type? > >But when computer programs sort or save records on the disk, there are no >possibilities of >errors (in well debugged programs!), and also some bytes saved can be an >advantage when >files contain millions of positions. This would be a good advantage. > >The only question is: >Is the proposed format equally readable by humans? IMHO yes. Maybe. I'm sure people would get used to it. However, the // type of entries (for example, ////) could also easily be misread by people, so your format is probably not equally readable. It is probably more difficult to read, but only by a slight margin. Your format has the disadvantages of losing the checking information, requiring a method (an extra byte or a file type?) to distinquish from an invalid FEN, and a minor disadvantage of slightly more difficult to read. My formats have the disadvantage of being much more difficult to read by humans(although it is possible). My second format has another advantage over even yours in that it is compressed even more. However, the disadvantages for your format and my formats are probably why the FEN format is the way it is since alternatives drop things on the floor. > >Guido KarinsDad :)
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.