Repository navigation
Allow min / max / tie constraint removal for modeling Parameter #1078
Description
I think currently it is not possible to un-tie a parameter?
At the moment when I try to set model.parameter.tied = False indicate it should be un-tied I get an AssertionError:
@tied.setter
def tied(self, val):
> assert callable(val), "Tied must be a callable"
E AssertionError: Tied must be a callable
The same applies to trying to remove a min or max constraint from a Parameter, i.e. setting model.parameter.min = None gives an
@min.setter
def min(self, val):
> assert isinstance(val, numbers.Number), "Min value must be a number"
E AssertionError: Min value must be a number
Another minor thing: the constructor arguments minvalue and maxvalue should be changed to min and max to make them consistent with and easier to remember with the min and max properties.
@iguananaut mentioned he is currently working on the Parameter and Model class, so we should wait for #980 before fixing these issues (if they aren't resolved there).
Activity
embray commentedon May 10, 2013
Hmm. First of all if this is going to throw an error at all it should be a
TypeError, not anAssertionError. Second of all, does it make sense to be able to modify these constraints, or does it make more sense to create a new model instance with different constraints?I haven't paid much attention to this issue until recently so I'm not clear on whether it's preferable for Model objects to be very tweakable, or what. Though I suppose, as long as you can modify the parameter values I guess you should be able to modify these constraints as well. And in that case I agree it should be possible to 'unset' them with
NoneorFalse. (in the meantime you could just override them with a noop likelambda v: v).cdeil commentedon May 10, 2013
@iguananaut It's very common to fix / free parameters in interactive fitting sessions to eventually achieve convergence for multi-parameter fits.
nden commentedon May 10, 2013
@iguananaut Yes, this is a bug in the current master
embray commentedon May 10, 2013
Yeah, okay. That makes sense.
cdeil commentedon Aug 8, 2013
I think this feature request has been implemented by @nden in the meantime.
Everyone happy how it works now?
The only think left would be to change the
AssertionErrorinto aTypeErrorand to add some documentation for this feature?Do we want more unit tests with some complicated setting / fitting / unsetting / fitting / ... sequences to make sure the system can't get into a bad state?
If that's all that's missing to close this issue I can make a PR.
nden commentedon Oct 5, 2013
This has been fixed in #1243 and tests were added to
test_constraints.