-
Notifications
You must be signed in to change notification settings - Fork 438
DLQR and DLQE #670
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DLQR and DLQE #670
Conversation
Any indication, why you can't have Slycot on your M1? No conda packages? |
Not sure. conda has been spending a lot of time "solving" the environment and then not succeeding (I don't remember the error message) when I try to install slycot with conda-forge. Will try again |
control/tests/statefbk_test.py
Outdated
@slycotonly | ||
def test_care_antistabilizing(self, matarrayin): | ||
"""Test anti-stabilizing feedbacks, continuous""" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about instead of duplicating code lines, you parameterize test_care
and test_dare
with something like
@pytest.mark.parametrize(
"stabilizing",
[True,
pytest.param(False, marks=slycotonly),
]
def test_care(self, matarrayin, stabilizing):
...
X, L, G = care(A, B, Q, R, S, E, stabilizing=stabilizing)
sgn = {True: -1, False: 1}[stabilizing]
assert np.all((sgn * np.real(L)) > 0)
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks for the suggestion & code sketch. done
control/mateqn.py
Outdated
if not stabilizing: | ||
return care_slycot(A, B, Q, R, S, E, stabilizing) | ||
else: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This always favors the SciPy version over Slycot for stabilizing=True
. I guess the SLICOT routine should be more efficient than calling 3 solvers for X
, G
, L
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might be nicer to implement a method
keyword as suggested in #255.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess the significant number of uncovered lines as reported by coveralls comes from this change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One of my grad students actually encountered that bug with slycot’s dare
. I’ll see if I can find the bug. Ok if we leave adding a method
keyword to a different PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm would be okay with deferring the method keyword to a later PR.
But I don't like leaving code in the repo which is essentially untested or disabled.
control/mateqn.py
Outdated
raise ControlArgument("Q must be a symmetric matrix.") | ||
raise ControlDimension("Q must be a symmetric matrix.") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's not a dimension error. ControlDimension
would have been raised above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True. I was trying to make it so both slycot and scipy versions raised the same kind of error (ValueError) rather than different types (ControlArgument is a TypeError), so that we could run the same test on both. win-win solution: I'll just change that to a ValueError because I think it can be argued that being non-symmetric is more of a value error than a type error.
Marked this as ready for a review to merge. Still working on getting slycot working on my mac (reinstall anaconda didn't do it) so I think a PR that adds a method keyword will have to wait until I get that resolved. |
Some (minor) overlapping changes in #673, which allows the |
@murrayrm I like the idea of "overloading" Happy to rebase this one on top of #673, or vice versa, but it may be a few days before I have time to do anything on it. |
@sawyerbfuller FYI, if you rebase this, you might want to wait until #683 is merged since that has a lot of relevant changes in both |
…ug in non-slycot care. lqr, lqe, dlqr, dlqe now get tested without slycot.
…when arrays are not of the correct dimension
Rebased on latest master. A couple of other things we could do before merging:
|
@murrayrm thanks for moving this one toward the finish line. One remark in regards to a change on line 280 in The question is, what if |
Oops. Reverted. |
update 2021.1.09
Slycot not currently working with my new M1 mac so I made it so lqr, lqe, dlqr, and dlqe now have a fallback to scipy-only. They use an updated version of
care
anddare
that have non-slycot options available.care
anddare
now use scipysolve_continuous_are
andsolve_discrete_are
if possible instead of slycot (only case they don't is whenstabilizing=False
)