Author: Robert Hyatt
Date: 16:51:03 06/09/98
Go up one level in this thread
On June 09, 1998 at 13:24:57, Danniel Corbit wrote: >On June 09, 1998 at 11:05:09, Steven J. Edwards wrote: >>On June 09, 1998 at 10:46:10, Danniel Corbit wrote: >[snip] >>>This would have serious performance implications for some platforms. If >>>we use some highly capable database like Rdb, you can get 65000 >>>characters in a column you can index. But in many database systems, the >>>max is 255 [and for some it is 254]. >> >>Some compilers enforce a silent limit of 31 characters per symbol of >>significance and there aren't too many problems with that. Strings need >>to be longer; for example, a FEN spcification may hit more than 80 >>characters in some cases. >I would not mind if [some] strings were allowed more than 255. Perhaps >free-form annotation remarks could be memo/list of byte varying or >whatever. But the fields I wish to do lookups on would be a pain in the >gizmo if they were too big [for some systems]. I want to write a public >spec, complete with domains and SQL scripts to populate the data. If we >had 3000 character PGN tags, MS Access and many other popular database >systems would fail. It would not bother my use any because I have a >boatload of very nice database systems here [we are a database outfit]. >But it would be a pest for others. if we are going to nitpick the standard, here is one thing that is really ugly: when you output a variation with black to move, it apparently should be done like this: 15... Nf6 Nf3 d5 etc. That "15..." is totally illogical. for normal moves we see 15. e4 h6 16. Nf6 and so forth.. so that the move number is one "token", then it must be followed by a white move, and a black move. Using "15..." violates that and is more difficult to parse to boot, since most scanf() input readers will suck in 15... as one string... why not use the more common 15. ... Nf6 format, where a separate token (...) indicates that the white move is omitted. This seems more common in published analysis and it is much more compatible with normal parsing algorithms...
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.