Thanks for this contribution,@SCLiao47.

I think the_bandwidth method should be renamed tobandwidth and put in theLTI class inlti.py. With that change, you should be able to get rid of thebandwidth methods inTransferFunction andStateSpace, since they will get the method from their parent class. You will probably have to overridebandwidth inFrequencyResponseData since thedcgain method is not implemented there.

I have some other suggestions, but if you agree with the change above then I would start there, since it will move things around.

Coverage: 94.652% (+0.003%) from 94.649% when pullingab68562 on SCLiao47:feature_bandwidth intoc06a205 on python-control:main.

@murrayrm thank you for the comments and suggestions.

The_bandwidth method was implemented as I was following the_dcgain method in theLTIclass inlti.py. But as you suggested renaming it tobandwidth can simplify the code structure. One other thing I wasn't so sure about is "what other classes should have thebandwidth method." TheFrequencyResponseData class is one of them as you mentioned, and I wonder if there are others as well?

[Regarding development flow]

• I'm still learning the development flow on GitHub. Thecontribute wiki page (step 11) mentioned that I could keep working on the branch under my own fork. However, does the new commit directly sync to this pull request?
• One other thing I notice while following the contribute wiki page. It seems like GitHub has renamed themaster branch tomain. Maybe there needs some edition to the wiki page but I'm not so sure.

Hi@SCLiao47

i think only the classes that derive from LTI should get a bandwidth method: tf, ss, and frd.

As for your question about development: adding new commits to your branch is very seamless. Add them to your own branch (on your own computer) and then, when you do git push origin, they will appear right here on your pull request.

Our main branch name is grandfathered in as master.

I've updated the documentation to refer to the main branch (master is deprecated).

@sawyerbfuller@murrayrm thank you for the suggestions and comments. I've restructured thebandwidthmethod in theLTI class inlti.py.

FRD

As for theFrequencyResponseData class, I wonder how you would suggest implementing thebandwidth method for it? At the moment, the class seems to not support interpolating, which is needed to infer DC gain and compute the bandwidth. However, this will probably fall outside of the scope of this feature. Is there a way to get around this?

Development flow

I think I need to make sure I understand the flow and might need some clarification. In step 8 of thecontribute wiki page, the intention is to update and sync thelocal code (on my machine) to theupstream version (python-control/python-control).

What happened in the instructions:

1. After clickingsync fork andUpdate branch on github.com, myforked repo (SCLiao47/python-control) will be sync to theupstream version. Both repos are remote on github.
2. The first chunk of command lines (on my machine) is to sync mylocal main branch to themain of theforked repo on GitHub.
3. The second chunk of command lines is to bring the commits in thelocal feature branch to thelocal main. Thegit rebase allows resolving conflict before merginglocal feature intoupstream main and maintaining a cleaner git graph.

If the above understanding is correct, I wonder about the following:

1. Thelocal main is not intended to be developed and made changed from my understanding. Why do we need togit push aftermerge origin/main?
2. Can we skipsync fork on github.com and replacegit merge origin/main withgit merge upstream/main? This will have the same result that thelocal main will be synced toupstream main, right?

What happened in the instructions:

1. After clickingsync fork andUpdate branch on github.com, myforked repo (SCLiao47/python-control) will be sync to theupstream version. Both repos are remote on github.

Correct.

2. The first chunk of command lines (on my machine) is to sync mylocal main branch to themain of theforked repo on GitHub.

Correct.

3. The second chunk of command lines is to bring the commits in thelocal feature branch to thelocal main. Thegit rebase allows resolving conflict before merginglocal feature intoupstream main and maintaining a cleaner git graph.

Yes, the commands make sure that your local feature branch also has all the recent changes of your recently updated localmain which should now be at the same commit asupstream/main

If the above understanding is correct, I wonder about the following:

1. Thelocal main is not intended to be developed and made changed from my understanding. Why do we need togit push aftermerge origin/main?

If you didn't change anything in your local main before the merge, you don't need to push. The push is a noop then. In that case the merge will be a fast-forward and it is sufficient to alternatively just.

git switch main; git pull

But if you have changes in local main (which you should not), you will notice here.

2. Can we skipsync fork on github.com and replacegit merge origin/main withgit merge upstream/main? This will have the same result that thelocal main will be synced toupstream main, right?

Yes, but then you need the push so that yourorigin/main does not stay behind. These sequences are equivalent, assumingorigin/main is already the tracked remote branch of your local clone.

1. git switch main; git fetch --all; git merge upstream/main; git push

2. on main press "sync fork", then:

   git switch main; git pull