fillChromPeaks for XCMSnExp

[jorainer]

Implement the fillChromPeaks for XCMSnExp objects.

[jorainer]

The original fillPeaks fills the missing peaks always using the profile matrix. This makes sense for e.g. chromatographic peaks identified with matchedfilter but could be problematic for e.g. centWave detected peaks since in that case the "into" (original intensity) for the peaks are calculated on the raw data.

[jorainer]

In most use cases the issue above might not be a problem. It could get hairy if the step (i.e. binSize) for the profile matrix is too large and the profile matrix starts merging to broad mz slices.

Still - for the XCMSnExp implementation I will drop the profile matrix generation and integrate the intensity for the missing peaks purely on the raw data.

[stanstrup]

The pull require here #3 was related to the issue of the bin size.
I guess you still need to find a smart way to find a reasonable mz window to integrate.

[jorainer]

Thanks for the link @stanstrup . Yes, the mz range seems to be quite problematic. In some instances also your expand.mz does not help, i.e. when the difference between mzmax and mzmin is 0. To account for this I am thinking to allow for an optional argument ppm that would increase the mz window by the ppm (i.e. mzmin - (mzmin * ppm / 1e6) and mzmax + (mzmax * ppm / 1e6)). To me that would make sense, what do you think?

[jorainer]

Actually, there seems to be a problem in the current implementation of the expand.rt and expand.mz. See issue #139

[jorainer]

Done in 083fd4b
What's still missing is an option for MSW and matchedFilter peak finding

[stanstrup]

Damn. Thanks for finding that.

Regarding the diff=0 issue I did suggest to have have a min.width too to solve that issue. For some reason that was never accepted:
https://github.com/sneumann/xcms/pull/3/files

There was also a check to make sure we don't extend beyond the range of the data.

Edit: now I understood what you did with the ppm. So your suggestion is a relative min width where mine was fixed. I think either would be ok. Don't have strong feelings for one vs. the other.
In my original suggestion also RT range would have a minimum.

[jorainer]

I think the ppm makes sense since it considers/is related to the precision of the machine - at least that was the idea.

You're right, I should ensure that the rt width is within the data range, for the mz it shouldn't matter, in the worst case an NA is returned, which is not counted for the integration.

[jorainer]

fillPeaks.MSW calculates the mz and maxo differently from fillPeaks.chrom, thus, the fillChromPeaks,XCMSnExp method has to handle that too:

• mz is the mz closest to the mzmed of the feature (selecting the one with the highest intensity, if more).
• maxo is the intensity of the above mz.

This is in contrast to the other methods, in which mz is the intensity-weighted mean mz and maxo simply the largest intensity of the peak area.

TODO: add this information to the documentation!

[jorainer]

Now, another peculiarity of the fillPeaks.MSW: to find the mz values within the mzmin and mzmax it doesn't use something like mz >= mzmin & mz <= mzmax, but seq(which.min(abs(mz - mzmin)), which.min(abs(mz - mzmax))) which can also pick up mz values that are outside of the mz range defined by mzmin and mzmax.