Interest in adding some set control

[gleasonj]

Hi,

I worked, and still utilize tools, from set-theoretic control communities. When I graduated and lost my university access to MATLAB I was bummed to find that set-based control methods weren't available in python, which is the language I most commonly use for work now.

I have been working on getting some basic set control implementations using support functions/vectors and basic polytopes built in Python and thought it would fit nicely as a sub-package of this toolbox. I forked the repository and added a sub-package called "sets" where I've stored it all. Feel free to take an early look at it: https://github.com/gleasonj/python-control. (See the adding_sets branch.) The goal would be to allow the computation of control invariant sets, reachable sets for discrete linear systems, etc. I am modeling the implementation of these sets to be a pythonic version of Julia's LazySets implementation: https://juliareach.github.io/LazySets.jl/dev/.

Before I bother you with pull requests, I wanted to check in and see if this functionality is something you would be interested in including here or if you believe it to be outside of the domain of this project.

[murrayrm]

This type of functionality would definitely be welcome. A couple of comments:

• Not clear to me whether this should be something that sits "underneath" the current control package or whether this should just be a separate package (would could import functions from python-control if needed). I think the question may come down to how closely integrated the different modules in the main package (control) and the sub-package (sets) are.
• There is an existing polytope package that was developed as part of the TuLiP package: https://github.com/tulip-control/polytope. Not sure if that might be helpful here or not.
• The current PR seems to be a bit preliminary: thin documentation (and not following numpydoc standard), minimal unit tests (and using unittest instead of pytest). At the point that a PR comes through, it would be good to have sufficient documentation and a set of unit tests that provide 85-90% (or higher!) code coverage plus a few examples (ideally also appearing in the user manual) that demonstrate package use (similar to what was done for the flatsys module or the iosys module in python-control).

[gleasonj]

I hadn't heard of TuLiP. Thanks for sharing that. It looks like it has a relatively limited implementation and I don't immediately see the ability to perform set operations on things that aren't basic H-Polytopes. My implementation of polytopes is based off of pytope: https://github.com/heirung/pytope, which does not appear to be maintained to any extent anymore.

The reason I wanted to check regarding creating a package underneath control is largely to address some of the things you mention in your third point. Since your package is the most extensive set of control codes available for python I would like to, even in the event of having set operations/control built as an entirely separate package, design my setup to work with your toolbox, and ideally would like you to be able to use any set tools that benefit your development. Specifically this would mean making sure that I follow documentation, unit-testing, and other input styles that align with the practices that the control package already uses.

Do you have an informal set of guidelines that your community uses to develop the code? You mentioned the numpydoc standard and pytest vs. unittest. I have also seen that your collection of vectors in a 2d numpy array has individual vector represented as the columns of the matrix. These types of things are helpful for me to keep in mind to ensure that any implementations I develop will most seamlessly coordinate with your code.

[murrayrm]

We haven't put together a "developer's guide" for the control package yet, though there are some rough notes on a few related topics (PRs, releases, etc) on the python-control developer's wiki. I've added some (currently blank) pages there to track coding style (naming, documentation) and testing conventions.

[gleasonj]

Great! I'll keep an eye out and keep working when I get the time. Once I have a suitably developed/documented/tested setup I will reach back out and determine if it seems like something that should go inside of the general control package or stand alone.