Refactoring #1538
Feature #1534: === Parameter handling ===
AttLimits::isInRange(value) returns true for value==m_lower_limit, and false for value==m_upper_limit
Status: | Rejected | Start date: | 27 Jul 2016 | |
---|---|---|---|---|
Priority: | Normal | Due date: | ||
Assignee: | - | % Done: | 0% | |
Category: | - | |||
Target version: | - |
Description
Current implementation is
bool AttLimits::isInRange(double value) const { if(hasLowerLimit() && value < m_lower_limit) return false; if(hasUpperLimit() && value >= m_upper_limit) return false; return true; }
Why this asymmetric handling of lower and upper limit? What would be a better choice? Do we possibly need a extra bits to tell whether lower and upper limits are allowed values?
Long-term idea: if a limit is excluded from a range, then upon approaching this limit, a GUI slider or a fit algorithm could automatically cross-over to logarithmic handling of that variable.
History
#1 Updated by wuttke over 4 years ago
- Subject changed from AttLimits::isInRange(value) allows value==m_lower_limit but not for value==m_upper_limit to AttLimits::isInRange(value) returns true for value==m_lower_limit, and false for value==m_upper_limit