You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I know it has been a while and maybe you already figured out your issue, but I saw post and figured I could help.
The twin.factor parameter is designed to disallow a valley result being returned if the valley's y value is very close to the y value of the peaks. This usually occurs when two peaks are about the same height and are next to each other. For example
Please note that when twin.factor is reduced to 0.85 the valley is no longer accepted and a value related to the inflection point of the distribution is returned.
Regarding getPeaks, the twin.factor parameter is not commonly (possibly never) used for calculating peaks since we are looking for peaks and not valleys. And looking at the code, the part using twin.factor is implemented differently than the way it is implemented in deGate. I would advise not to use twin.factor in getPeaks. So your comment of "The first peak is ignored as expected", is actually not an expected result.
One tip is if you want to get both valleys in your example you can use the all.cuts parameter in deGate. For example,
library(flowDensity)
library(flowCore)
set.seed(123)
dat <- matrix(c(rnorm(3000, mean = 5, sd = 0.5),
rnorm(3000, mean = 7, sd = 0.25),
rnorm(1000, mean = 8, sd = 0.25)))
colnames(dat) = "d"
ff <- flowFrame(dat)
peaks <- getPeaks(ff, "d", twin.factor = 0.5)
gates <- deGate(ff, "d", all.cuts=T)
gates
[1] 6.153844 7.670830
I'm wondering if this is expected behavior. Example:
The first peak is ignored as expected
But the gate from deGate() is not between the two peaks from getPeaks() as if
twin.factor
did not have an effectPlot
Is this expected behavior? Thanks.
sessionInfo()
The text was updated successfully, but these errors were encountered: