Thanks again Matt. Following up on your point 2 above, does this mean that the 32/64/mz32/ mz64/inten32/inten64 flags for msconvert are always ignored, or are they used elsewhere, e.g. for non-Agilent data?
bio.x2y On Feb 16, 8:17 pm, Matthew Chambers <[email protected]> wrote: > 1. I don't know. > > 2. The Agilent IBDASpecData interface returns an array of 64-bit floats > for m/z values and an array of 32-bit floats for intensity values. > However, msconvert ALWAYS defaults to writing 64-bit m/z values and > 32-bit intensity values, regardless of the precision of the input. It's > a safe enough assumption. The 1000514 refers to the m/z array term in > the PSI-MS CV and the 1000515 refers to the intensity array. I agree > that behavior is absurdly confusing and jargonish. The byte order is > also pretty much irrelevant since both mzXML and mzML specify a > mandatory byte order. It would only matter for mzData which we don't > support yet. > > 3. Yes, for high accuracy data, there is benefit to using 64-bit m/z > values. But not a terribly significant benefit: > 1234.567 -> 7 significant base10 digits is the worst case for 32-bit > IEEE-794 AFAIK. > > -Matt > > > > bio.x2y wrote: > > Hi, > > > Msconvert allows the user to specify the required precision of output > > peak data - either 32-bit or 64-bit. > > Trapper does not seem to have an equivalent switch (at least there is > > no mention of it in the usage documentation). > > > (1) Is there a way to force Trapper to generate 64-bit precision > > output? > > > (2) I'm wondering if I would "lose" data by using Trapper for Agilent > > MassHunter ".d" data. > > I'm not comfortable enough with C++ to answer this for myself - when > > Trapper/Msconvert call the Agilent interface, do they receive back 32- > > bit or 64-bit data? I'd like to know if the 64-bit precision of > > Msconvert is actually giving me real data, or just padding out 32-bit > > numbers to help collapse my hard drive? > > > (3) This is probably a question I should be able to answer myself, and > > might be much too broad for here, but might there be any practical > > benefit for having 64-bit data rather than 32-bit? I suspect that the > > different might be negligible in the sense that the difference between > > a 32-bit and 64-bit m/z would have no impact on things like peptide > > identification or feature detection for quantification? > > > Thanks again, > > bio.x2y -- You received this message because you are subscribed to the Google Groups "spctools-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/spctools-discuss?hl=en.
