Author: Tord Romstad
Date: 08:37:09 06/10/04
Go up one level in this thread
On June 10, 2004 at 11:00:23, Robert Hyatt wrote: >On June 10, 2004 at 04:33:21, Tord Romstad wrote: > >>On June 09, 2004 at 16:19:10, Robert Hyatt wrote: >> >>>Parsing SAN is _not_ hard. >> >>Perhaps not extremely hard, but still an unnecessary complication, IMHO. >>A format like "g1f3" or "Ng1f3" is closer to the internal representation >>of moves in almost all chess-related programs. I find it hard to believe >>that there is a big number of programs which actually stores only the >>type of piece and the destination square, and adds more information only >>when it's necessary to avoid ambiguity. >> >>By using SAN, you make life more difficult for the programs which produce >>the files as well as for programs which read the files. The programs which >>produce the files are forced to convert it's internal from-to representation >>of moves to SAN, and the programs which read the files have to reverse the >>process. This seems really silly to me. > >Notice that I said "I like and prefer SAN myself". > >However I proposed that if we do a new standard, we pick _one_ move >representation and stick with it, and provide conversion utilities to convert it >to other representations (including san). Here, I agree 100%. It is extremely annoying that the xboard protocol, for instance, does not require some specific move representation. The PV in the xboard protocol is essentially just a string, and the GUI has to *guess* the move format if it wants to do anything more complicated than just displaying the raw string. I don't think using SAN is the best solution, but I agree that the most important thing is to agree about a single representation. >>SAN is only a good idea when the information is presented to the user. >>It has no place in file formats which are not designed to be read by >>humans, nor in engine communication protocols. > > >I don't disagree, except that there are always going to be humans that insist on >reading the raw data.. Yes, but I don't think making life easier for those who insist on reading the raw data should be a guideline when designing the standards. >>>There is public code to do that in the epd kit as well as inside Crafty >>>itself. >> >>I am not sure what the "epd kit" is, but if you are referring to the >>epd*.c and epd*.h files by Steven J. Edwards which are included in the >>Crafty source code, they are unusable to the majority of chess programmers >>because of their gigantic size. The epd*.* files alone are bigger than >>the complete source code of my engine, despite the fact that my code has >>grown very bloated. > > >What does their "size" have to do with being usable? They don't add megabytes >to the executable... Not megabytes, but it wouldn't surprise me if they add 100 KB, which is already far more than I can accept for something which does not increase playing strength. >Ever looked at the _size_ of the shared C libraries you are including without >knowing??? Hint: They _are_ megabytes in size. Yes, but the point is that they are _shared_. If I were forced to always deliver statically linked executables, I would have tried to economize my library usage as much as possible. Tord
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.