Re: [Psidev-ms-dev] PSI-MSS WG Tuesday call reminder

[Matthew C. <mat...@va...>]

No measurements I'm aware of in proteomic mass spec use more than 15 
base 10 digits, which is the number of digits that double precision 
floats can represent without precision loss. That means that even if a 
value goes in as 1.5 (which can't be represented exactly), then as long 
as we round to the 15th digit we don't lose precision. As others have 
said, we can thus "round-trip" 15 digits. We get this high degree of 
fidelity to the source data without all the assumptions involved with 
the ASCII representation: I use doubles consistently then I'm always 
providing 15 significant digits. And if we did need more than 15, then 
ASCII is still a very inefficient encoding. You'd want to use arbitrary 
precision fixed or floating point binary types, which can't be computed 
on very easily or efficiently, but they are the Right Way to achieve 
arbitrary precision (i.e. no unspecified assumptions, well defined byte 
width, fast parsing).

So in fact, you can preserve this "poor person's" significant digits 
encoding: if the software is doing its job, then it will go out the same 
way it came in! The real nastiness with floating point is when the 
precision loss accumulates every time an arithmetic operation happens on 
a cumulative sum or product.

-Matt


Stein, Stephen E. Dr. wrote:
> Yes, that is what I had in mind - you get drilled in that when you take a lab course in Chemistry or Physics (maybe it has been dropped in recent years). It is a poor person's way of providing error limits (the lowest significant figure contains the precision of measurement). 
>
> It is true that if only affects 10% of values, but that's enough for me to be concerned. I suppose we could put ASCII in a comment field, but physical quantities do have precisions, and stuffing measured values in those floating formats loses some of it.
>
> Sorry to say, this problem generally affects binary representations of measured values - one reason why I have liked the ASCII nature of XML - and hate to lose it.
>  
> -Steve
>
> -----Original Message-----
> From: Mike Coleman [mailto:tu...@gm...] 
> Sent: Thursday, June 11, 2009 4:41 PM
> To: Mass spectrometry standard development
> Subject: Re: [Psidev-ms-dev] PSI-MSS WG Tuesday call reminder
>
> I took it to mean that with "1", "1.5", "1.50", one gets an implied
> level of precision.  That is, "1.5" is generally understood to mean
> 1.5 +/- 0.05.  If I give you the IEEE float 1.5, much less is implied
> about the precision of this value, unless it's explicitly stated
> elsewhere.  (If you have a whole set of these, then you probably can
> work out the equivalent precision, but this is a bit of a stretch.)
>
> Mike
>
>
> On Thu, Jun 11, 2009 at 3:23 PM, Angel Pizarro<an...@ma...> wrote:
>   
>> Is your question whether we can successfully round-trip the numbers? Eg. go
>> from an ascii format to mzML back to originating ascii format and get the
>> same exact numbers? I believe that when we pack the numbers and unpack them
>> (at least in my non-validating ruby implementations) the numbers and
>> significance are completely the same. E.g. 1.005 === 1.005 and not
>> 1.005000000000001
>> -angel
>>     
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing 
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing 
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>