- Notifications
You must be signed in to change notification settings - Fork441
fixed bug in calculation of percent overshoot#555
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
coveralls commentedMar 4, 2021
Is#337 also addressed, by chance? |
sorry, didn't have a chance to get to that one on this PR |
LGTM |
Dear@sawyerbfuller, the solution could have problem with systems with initial condition different of zero. I want to contribute , but at the moment, I don't now how test the last version. I maked this example, to explain:
{'RiseTime': 2.616832783582626, new_overshoot = 38.34913836051592 |
But |
Uh oh!
There was an error while loading.Please reload this page.
Now it gives the correct result even if the transfer function is not strictly proper.
Other changes:
step_info
(and updated unit tests)a remark:
sys.dcgain()
now always returns a complex number because it evaluates at a frequency of zero (1 for DT systems) (as a result of#542?). This returns a real-valued complex number. I think there is a reasonable argument that it should be cast to afloat
because currently we assume system parameters are real-valued.