GeezerVison is showing github.com — Releasing 0.9.4 and moving to 0.10.0 · Issue #904 · python-control/python-control
Releasing 0.9.4 and moving to 0.10.0 #904DescriptionI am planning to do a new release (0.9.4) in the coming days that will include all recent PRs except #881, since that may have some incompatibilities due to the requirement to use lists (versus tuples) in some parts of the interconnect interface.
Are there any additional changes we want for 0.9.4?
For version 0.10.0, I was thinking that we might:
- Add in the new multivariable interconnect functionality
- Get rid of support for the NumPy
matrix class (no longer recommended by NumPy, though not yet deprecated)
- Consider other changes that would require small rewrites of working user code.
Use this issue to post thoughts and suggestions. Activitysawyerbfuller commented on Jun 5, 2023 I think I have everything that I hoped to for a .9.4 release already submitted.
As for .10, I am in favor of using that release to begin phasing out deprecations, most notably the matrix class.
Another possible future change to consider for that time frame is merging StateSpace and LinearIOSystem classes. Are there any reasons to keep them separate aside from the effort to refactor the code? There is also the matter of what the resulting class should be called.
What's needed for a 1.0 release? Here are two possible features that come to mind that may be worth considering:
- Time delays
- Refactoring the code to separate plotting from computation enough to enable a plot-free version of python control as suggested in Lightweight version of python-control #808, which would be helped by New plotting paradigm #645
sawyerbfuller commented on Jun 5, 2023 As long as we are talking about architecture, I had a question about the use of the dictionaries input_index and output_index. Is there any chance we could get away with a simplification in which signal names were stored entirely in input_labels and output_labels, which are lists of signal names? The location in the list could encode the index of the signal. To find the index associated with a name/label, you would use the syntax sys.input_labels.index('u') rather than sys.input_index['u'] -- a few more characters, but fewer fields to keep around and keep in sync. But I really don't know all the ways these are used -- especially as we move toward multivariable interconnect -- so I may be missing something. murrayrm commented on Jun 5, 2023 There are not actually two separate class variables. Instead input_labels (and the others) is a property that just returns input_labels.keys(). So no syncing issues (and you can use sys.input_labels.index('u') if you like -:). murrayrm commented on Jun 6, 2023 Regarding system classes, here is what we have now:
I think we can do the following:
- Collapse NamedIOSystem and InputOutputSystem into a single class (probably InputOutputSystem)
- Collapse LinearIOSystem and StateSpace into a single class (probably StateSpace)
- All other classes (LTI, FRD, NonlinearIOSystem, InterconnectedSystem, LinearICSystem) remain
This would give us something like this (focusing just on the I/O system classes and leaving out FRD):
Reacted by Ilhan Polat, Sawyer Fuller and Shih-Chi Liao sawyerbfuller commented on Jun 7, 2023 That makes sense! - I agree with your suggestions for how to collapse the class hierarchy.
Also - sounds good in regards to putting off multivar interconnect to the next release. Might be nice to have some time to experiment with it once it is merged because of the aforementioned changes. bnavigator commented on Jun 7, 2023 Hi, I am sorry that I can not participate much in the discussions recently. I am in preparation of my upcoming PhD defense.
As far as I can tell, all suggestions look good to me, though. murrayrm commented on Jun 19, 2023 Closing this issue since 0.9.4 has now been released. Discussion on 0.10 is moved to #917.
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|
