Repository navigation
Fixing a model parameter can violate bounds restrictions on another #2235
Description
Notice that the boundary constraints on mean are violated here
from astropy import __version__
from astropy.modeling import models, fitting
import numpy as np
print __version__
m = models.Gaussian1D(amplitude=3, mean=4, stddev=1,
bounds={'mean': [4, 5]},
fixed={'amplitude': True})
x = np.linspace(0, 10, 10)
y = np.exp(-x ** 2 / 2)
f = fitting.NonLinearLSQFitter()
print f(m, x, y)0.4.dev6909
Model: Gaussian1D
n_inputs: 1
Degree: N/A
Parameter sets: 1
Parameters:
amplitude: Parameter('amplitude', value=3.0)
mean: Parameter('mean', value=3.8251208412576392)
stddev: Parameter('stddev', value=0.1348079843293544)
This goes away if the fixed constraint on amplitude is removed
m.amplitude.fixed = False
print f(m, x, y)Model: Gaussian1D
n_inputs: 1
Degree: N/A
Parameter sets: 1
Parameters:
amplitude: Parameter('amplitude', value=3.0)
mean: Parameter('mean', value=4.0)
stddev: Parameter('stddev', value=1.0)
Activity
embray commentedon Mar 25, 2014
Yeah, I haven't tracked down the exact issue here, but it seems to be related to the complex shuffling around of parameter values at each iteration of the optimizer; something I'm hoping to simplify fairly soon.
embray commentedon Mar 28, 2014
I'm tackling a reworking of how parameter values are shared between models and fitters that should make fixing this issue easier too. This will serve as a good test case I think.
ChrisBeaumont commentedon Mar 28, 2014
A related feature request that might help at least diagnose issues like this: It would be cool to actually "lock" a parameter value, such that trying to change the value raises an Exception. I was trying to debug a case where a fixed parameter didn't appear to be "fixed" to the value I expected -- I realized I was accidentally overwriting the seed value before passing to a fitter. I would have debugged that problem more quickly if my program crashed at the moment the parameter changed.
embray commentedon Mar 28, 2014
That's a good point--really I wouldn't even call it a new feature so much as a consistent application of existing features. If a specific bounds are specified for some parameter then it should be assured that any value given to that parameter (either as an initial value or manually assigned later) is within those bounds. Likewise if a parameter is fixed it should not be modifiable. Tied parameters and other such constraints should also be assured of consistency.
ChrisBeaumont commentedon Mar 29, 2014
Yeah, that's what I had in mind. I didn't know if there were implementation reasons for not enforcing fixing/boundedness at the set level, but such a "strict mode" would be helpful in many situations.
eteq commentedon Apr 30, 2014
@embray - any chance of getting a fix for this in 0.4, or does it require your large scale rewrite? (Note that if it's just a bugfix, it doesn't need to be ready by feature freeze.)
embray commentedon May 1, 2014
It's not immediately fixable. Or if it is, it's complicated and consuming of time that's better spent on refactoring.
embray commentedon Jun 20, 2014
Incidentally, both this issue and #2400 appear to be resolved by 25f2a1b. I added two new regression tests based on the example in this issue and the example in #2400 and both now pass. That's not to say the fits are very good (in fact the second example in this issue gives a totally bogus result with negative stddev). But that's a different, known issue. At the very least the constraints are obeyed now.
I'm not happy with the code, but I'll be able to fix that up as I continue to do my refactoring. As it is I'll probably close these issues as fixed once #2634 is merged.
Add two new regression tests based on issues astropy#2235 and astropy…
embray commentedon Jun 26, 2014
This should be fixed by #2634, though if you find it isn't--or find another example where this isn't working--feel free to reopen or whatever.