deprecate: deprecate the rest of the methods in recipeorganizer.py

[cadenmyers13]

No description provided.

[cadenmyers13]

@sbillinge ready for review

[codecov]

Codecov Report

❌ Patch coverage is 95.94595% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 78.40%. Comparing base (1c11b31) to head (c115478).
⚠️ Report is 23 commits behind head on v3.3.0.

Files with missing lines	Patch %	Lines
tests/test_sgconstraints.py	0.00%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           v3.3.0     #169      +/-   ##
==========================================
+ Coverage   78.25%   78.40%   +0.15%     
==========================================
  Files          24       24              
  Lines        3674     3700      +26     
==========================================
+ Hits         2875     2901      +26     
  Misses        799      799              

Files with missing lines	Coverage Δ
tests/conftest.py	92.40% <100.00%> (ø)
tests/test_constraint.py	98.30% <100.00%> (+1.33%)	⬆️
tests/test_fitrecipe.py	99.85% <100.00%> (ø)
tests/test_recipeorganizer.py	99.73% <100.00%> (ø)
tests/test_restraint.py	96.87% <100.00%> (ø)
tests/test_sgconstraints.py	10.06% <0.00%> (ø)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[sbillinge]

please see comment.

[sbillinge]

I think I like add_restraint better than constrain_parameter. It is not completely clear to me whether we are constraining parameters or variables or what is happening. Actually, I think that the constraint maps parameters to variables somehow. In that case, to avoid awkwardness, does it make sense to call it add_constraint. I am open to discussion on this, but I since we are deprecating everything, it is really our opportunity to think about this and get it right this time....

[cadenmyers13]

@sbillinge Yeah lets go with add_. I think the words constrain and restrain can also get mixed up in the heads of users (and mine lol). What if we did change,

• constrain --> add_constraint
• restrain --> add_penalty or add_bounds or add_soft_bounds

what do you think?

[cadenmyers13]

We actually have a Restraint class that manages all the restraints as well as _restraints attributes, so this could get confusing if we change... I still am not much of a fan of how similar those two words are

[cadenmyers13]

There is a Restraint.penalty method though that calculates the penalty, so add_penalty might be okay

[sbillinge]

Let's go with add_penalty, I like that.

[cadenmyers13]

@sbillinge okay i made the change, see the commit messages and the news items for whats changed

[sbillinge]

I am again not sure about this. Looking at the code, the only penalty we are allowed to add seems to be bounds on a variable, that are presumably soft bounds. I actually think that "restraint" is the right word to use here. We maybe just need to educate people what restraints are, as "soft" constraints, that restrain parameter values within a window by applying a penalty when they move out of the window.

[cadenmyers13]

@sbillinge yeah makes sense. I do think it would be nice to have some difference between the two though. Something like add_soft_restraint or something because, even if you know the difference, the name similarity can be a little annoying when writing cmi scripts.

[cadenmyers13]

@sbillinge or even add_soft_bounds since we are bounding the parameter with upper and lower bounds. this is a bit more descriptive i think.

[sbillinge]

OK, let's go with add soft bounds. I think this is good because the signature is something like add_soft_bounds(variable_name, lower_bound, upper_bound, penalty) so it reads well.

[sbillinge]

incidentally, let's make sure it is documented well how the bounds are applied in detail and whether the behavior can be controlled in any way by the user, if they want to use their own function for some reason or change how it is weighted.

[cadenmyers13]

@sbillinge ready for review. There is a defined penalty equation that is used so the user cannot add their own. We could add this feature though. probably better on a different PR