From: Matthew C. <mat...@va...> - 2009-06-30 23:12:37
|
Hi Mike, Are you using long doubles in greylag? The reasonable fix if more than 15 digits are truly needed is to use a bigger data type, although a standard and portable long double does not exist AFAIK. If one wanted to write trivial code to read XML, it would probably be a simple token parsing approach in which case reading the XML comments I proposed earlier is even easier than reading some cooked up ASCII notation. And remember that the ASCII notation, whether in standard form or in XML comments, would necessarily be an optional representation. I shudder with glee at the thought of how much fun that the optional "standard form" would be to deal with! ;) A DOM approach is conceivable, but unlikely to be scalable and in any case if you've got the facilities to read XML with a DOM then you almost certainly have access to base64 decoding or can get it easily. -Matt Coleman, Michael wrote: > I¹ve been on vacation, so this is a bit late. Comments below. > > On 6/12/09 10:05 AM, "Matthew Chambers" <mat...@va...> > wrote: > >> This is what I was refuting below. Assuming 15 or fewer base10 digits >> are needed, a double precision float is a better representation than >> ASCII in every way except human readability. Do you have examples of >> reference data that uses more than 15 digits in ASCII? >> > > For what it's worth, in greylag, the mass used for O (Oxygen) has 12 decimal > digits to the right of the decimal point. (This value comes from NIST, and > is meant to be as precise as possible.) Since peptides/proteins have masses > of at least 1000 Da, this means that at least 16-17 significant digits would > be needed to fully represent these calculations. > > One might dispute whether or not this level of precision is useful, but > since you asked, there's an example. > > >> And unless you can demonstrate that you need more >> than 15 digits of precision in your data, human readability is the only >> reason for ASCII representation. >> > > I would argue that the possibility of writing trivial programs that read > peak data is also a reason, perhaps a more important one. Having the peaks > encoded does make it a bit harder to jump in and start doing something with > them. > > Mike > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Psidev-ms-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev > |