Ray asks: > On the FCS side, are there any programs that do cover > all of the permutations of any version? Are there any > that actually conform yet? The answer to the first part is definitely no. The FCS standard is unfortunately much too flexible--thus writing code to read all possible variants is nearly impossible, not to mention simply not worth the effort! For example-who now stores bivariate histograms in data files? Anyone? And yet, this is part of the FCS standard. And I will buy dinner, with wine, for the first person who shows me a legitimate, non-hypothetical use for the $LOST keyword. In particular, the problem becomes considerably more difficult when you consider fully bit-packed data (i.e., putting 10 bit data in only 10 bits instead of 16). For those who thought byte order was a problem for FCS, this is a nightmare by comparison. Even for those who didn't think byte order was difficult, this is still a nightmare. It also seems that the evolution of FCS is only going towards greater flexibility rather than less. This is like the evolution of CPU's--for a while, manufacturers were putting greater and greater power into each--supporting thousands of different instructions. Then someone discovered that supporting LESS instructions made for MORE efficient processers (i.e., RISC processors). I hope that the FCS standard will soon evolve in a similar direction--simplify! Especially, in a way that encourages rigorous data analysis (e.g., not allowing the storage of non-listmode data). Why not make the new FCS actually only allow those formats which are currently supported by a vast majority of software? The distilled version would be far easier to support programmatically, and would result in far fewer problems for cross-compatibility. mr
This archive was generated by hypermail 2b29 : Wed Apr 03 2002 - 11:49:53 EST