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 inroot_locus, but I think that they are better done as part of a batch improvement of style that goes into a single version increment.

I will wait until you comment before doing a thorough review. However, I skimmed some of your work inee7c35d, and most of the refactoring is good. In terms of the API, tests are failing onroot_locus and a call to_convertToTransferFunction.

Whether_convertToTransferFunction should have the prefix_ might be worth discussing, but that might be outside the scope of this PR.

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:

1. file history is studied through commit history;
2. changelogs in the files can become difficult to search compared to root CHANGELOG.

Some of the files have author, date, and change notes, but they are mostly vestigial and not consistently added. They might be deleted soon.

@slivingston
I have taken into account all comments you post and I have made the corrections. I am not programmer so probably there are several mistakes related to collaborate in a project (like changing the API). This is because it is the first time I try to participate in this kind of work.
There are any guide to collaborate with this particular project ? There are some automatic check that to do before the pull request?
I have plot several root locus and lines look nice using default gains calculation.

@murrayrm I made suggested corrections.

Thanks a lot.

Coverage increased (+0.7%) to 78.001% when pulling32fe9b6 on gonmolina:smart-rlocus into5ab74cf on python-control:master.

Coverage increased (+0.7%) to 78.03% when pulling03df169 on gonmolina:smart-rlocus into5ab74cf on python-control:master.

@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 andPEP 257. Many practices used for the NumPy project we also aspire to have here, so consider consultingthe NumPy contributing guide. Some details, e.g., about NumPy project governance, are not relevant here. Another guide that is good to try to follow isthat of TuLiP.

Regarding automatic checks on the pull request (PR), tests are performed using Travis CI. You can find results from jobs for PRs athttps://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:

• https://help.github.com/articles/about-git-rebase/
• https://sethrobertson.github.io/GitBestPractices/

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 thepython-control sourcetree.

E.g., compare withhttps://sourceforge.net/p/octave/control/ci/tip/tree/inst/rlocus.m

After you address my question about originality, can you provide a nontrivial demonstration of the changes? I played some with your_default_gains, but I would enjoy your recommendation about an example.

@slivingston
I have ported from Octave a part of this PR. I have also used some part of the code of evans.sci (siclab) in this PR. However, for simplicity, most of the pionts calculated would be the same that calculated in Octave.

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 nowit 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?
There is any rule to define when it is original or when is a copy?

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
Ok. Thanks for the comments. In that way, I think this PR have to be rejected! I will rewrite the code taking into consideration all comments you made and I will make a new PR. Thank you very much.

@gonmolina thanks. I will review your new PR soon.

for ease of future reference, note that the replacement PR is#138