Iterative generation of profile matrix subsets in findpeaks.matchedFilter required? about xcms HOT 2 CLOSED

Writing unit tests comparing the results from matchedFilter with and without iterative buffering I stumbled across another problem from the iterative buffering concept:

• In each profBin call the bin size is calculated anew and, due to rounding errors (imprecision of floating point numbers), this will result in slightly different bin sizes in repetitive calls. Under certain conditions this can affect the binning and even result in presumably wrong results (such as in the example below for step = 0.2).

library(xcms)
f <- system.file('cdf/KO/ko15.CDF', package = "faahKO")
xr <- xcmsRaw(f)
mz <- xr@env$mz
int <- xr@env$intensity
scantime <- xr@scantime
scanindex <- xr@scanindex
valsPerSpect <- diff(c(scanindex, length(mz)))
step <- 0.2
## Run the feature detection using iterations.
A <- xcms:::do_detectFeatures_matchedFilter(mz, int, scantime, valsPerSpect, step = step)
## Run the feature detection without iterations.
B <- xcms:::do_detectFeatures_matchedFilter_no_iter(mz, int, scantime, valsPerSpect, step = step)
all.equal(A, B)
[1] "Mean relative difference: 0.7609699"

## If we run the implementation using binYonX with iteration.
C <- xcms:::do_detectFeatures_matchedFilter_binYonX_iter(mz, int, scantime, valsPerSpect, step = step)
all.equal(B, C)
[1] TRUE

## Or binYonX without iteration
D <- xcms:::do_detectFeatures_matchedFilter_binYonX_no_iter(mz, int, scantime, valsPerSpect, step = step)
all.equal(B, D)
[1] TRUE

The *_matchedFilter_binYonX_iter implementation calculates the breaks defining the bins once and re-uses them in each iteration thus avoiding the above described problem.

The conclusion from this is that the iterative buffering adds to data insecurity and potentially leads to a wrong binning result. I thus strongly suggest that we change this in the new code for xcms3.

from xcms.

Closing because we changed the default to use the new code in version > 1.51.1.

from xcms.