[REDMINE1D-43] [RM-6106] Discussion: minimal number of peaks to keep with CExtremum::Find Created: 04/Jun/21 Updated: 13/Jun/23 |
|
| Status: | Open |
| Project: | 1D Redmine |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Normal |
| Reporter: | Redmine-Jira Migtation | Assignee: | Redmine-Jira Migtation |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
Created on 2020-11-06 12:55:15 by Mira Sarkis. % Done: 0 Currently with develop0.14, the minimal number of peaks is set to 2 in CExtremum::Find. We decided to pass it 1 in the context of issue #6051 where we privilige vicinity cut over meritCut. Didier states that a minimal number of Peaks is only meaningful when using relative metrics, i.e., comparing two peak metrics to each other (e.g., comparing PDF values). If we decide to use non-relative metric (#5625), e.g., DtD = cte and compare peak merits to this value, we could face cases where this metric eliminates all the pdf peaks (thus eliminating Euclid spurious ??). In this case, does it have a meaning to force keeping 2 or even 1 peak? Wouldnt be more beneficial to throw an error in such a case? |