-
Notifications
You must be signed in to change notification settings - Fork 438
Add smart selection of gains for root locus plot. Calculation of break… #132
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
Conversation
…points of real axis.
Is there any way to make your proposed features without breaking the public API? As a matter of style, I agree with some of the changes, e.g., avoiding camelCase in |
I will wait until you comment before doing a thorough review. However, I skimmed some of your work in ee7c35d, and most of the refactoring is good. In terms of the API, tests are failing on Whether |
Regarding the comments near the top of rlocus.py where you list changes and the date, it is much better to place those notes about changes in your commit message because:
Some of the files have author, date, and change notes, but they are mostly vestigial and not consistently added. They might be deleted soon. |
control/rlocus.py
Outdated
"""Root locus plot | ||
|
||
Calculate the root locus by finding the roots of 1+k*TF(s) | ||
where TF is self.num(s)/self.den(s) and each k is an element | ||
of kvect. | ||
of gvect. |
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 should still be kvect
, based on the call signature.
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.
ok!
control/rlocus.py
Outdated
|
||
Parameters | ||
---------- | ||
sys : LTI object | ||
dinsys : LTI object |
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.
Is there a reason to use dinsys
? Most (all?) other functions use sys
for the system argument. What does dinsys
stand for??
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 had problems while I was testing the code (maybe an import sys in the worng place). I will rename it to sys and test again.
control/rlocus.py
Outdated
|
||
rlocus = root_locus | ||
rlocus = root_locus |
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.
File should end in a new line, no?
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.
ok
restore original API (variables Plot, PrintGain), and calling _convertToTransferFunction fix kvect word comment sys as variable name in input argument add the on line in the last line
@slivingston @murrayrm I made suggested corrections. Thanks a lot. |
tolerance is modified if axis are given.
@gonmolina I will review your recent changes tomorrow. Regarding some guide for collaboration on this project, there is not an explicit one. The general style guides for Python apply: PEP 8 and PEP 257. Many practices used for the NumPy project we also aspire to have here, so consider consulting the NumPy contributing guide. Some details, e.g., about NumPy project governance, are not relevant here. Another guide that is good to try to follow is that of TuLiP. Regarding automatic checks on the pull request (PR), tests are performed using Travis CI. You can find results from jobs for PRs at https://travis-ci.org/python-control/python-control/pull_requests |
Several of the changes that I am requesting involve rebasing and modifying commits in this PR. You might already know how, but in case not, two useful beginning references are:
Alternatively, if you add commits such that the total diff of all combined commits in this PR is good, then I can just squash them into a single commit and merge that. |
Is the code in this PR ported from Octave ? |
I ask because Octave is under the GPL, and I do not want to GPL-pollute the E.g., compare with https://sourceforge.net/p/octave/control/ci/tip/tree/inst/rlocus.m |
# $Id$ | ||
|
||
# Packages used by this module | ||
from functools import partial |
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.
Why did you move the import of partial
to here? Similarly, why were the imports of scipy.signal
and pylab
moved?
Are you changing the code to follow the style that groups imports according to standard library, other packages, etc.? If so, can you move such style-only changes to a dedicated commit? History is easier to understand that way.
@@ -80,6 +88,7 @@ def root_locus(sys, kvect=None, xlim=None, ylim=None, plotstr='-', Plot=True, | |||
PrintGain: boolean (default = True) | |||
If True, report mouse clicks when close to the root-locus branches, | |||
calculate gain, damping and print | |||
plotstr: string that declare of the rlocus (see matplotlib) |
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.
Can you add details to this description? E.g.,
format string for rendering the root loci. Interpretation of the string is defined by matplotlib.pyplot.plot.
ax = pylab.axes() | ||
|
||
# plot open loop poles | ||
# Plot open loop poles |
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 might be missing something, but it is not clear why you changed these "plot" words to uppercase "Plot". Is it merely a style change? If so, can you place it in a separate commit and indicate that it is a trivial change and only affects comments?
After you address my question about originality, can you provide a nontrivial demonstration of the changes? I played some with your |
@slivingston I just fix some problems I found in Octave. In Octave rlocus paths doesn't finished in zeros (I add some extra points) and I change the way that sort the roots (I use the same that It was used in rlocus.py). Other differences are axis limits, and asymptotes. About the license problems. I think right now it is not original, or it is hard to defend the originality. I didn't try to hide it (if you compare you will see that even the comments in part of the code are the same). I have some simple ideas to improve the algorithm, adding points in different positions that could result in fewer calculated points. The same for the finishing and adding points criteria. However I don't know when the work begins to be original. I mean, the main idea would be the same: add points to the rlocus up to a criteria is satisfied (evans.sci and rlocus.m use the same finishing criteria, but the way they add points is quite different between one and another). My idea is to use the same way to add points but changing the creterias. Could be that considered original enough? |
Thanks for your explanation. It might have been better if I asked you whether it is derivative work, since that is the crucial question for copyright. Surely there is some originality in the process of porting. The general guide about whether something is a derivative work is whether you depended critically on referring to most or all details of the original. E.g., did you copy-and-paste and then make necessary changes? Or, did you have to repeatedly compare with the original Octave implementation, line-by-line? The copyright applies to the materials, not the ideas. So, if you provide a new implementation of an existing algorithm, all without detailed copying or porting of another existing implementation, then there should be no doubt about your new implementation being new (not derived). |
@slivingston |
@gonmolina thanks. I will review your new PR soon. |
for ease of future reference, note that the replacement PR is #138 |
…points in real axis.