Repository navigation
Releasing 0.9.4 and moving to 0.10.0 #904
Description
Activity
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
StateSpaceandLinearIOSystemclasses. 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
As long as we are talking about architecture, I had a question about the use of the dictionaries
input_indexandoutput_index. Is there any chance we could get away with a simplification in which signal names were stored entirely ininput_labelsandoutput_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 syntaxsys.input_labels.index('u')rather thansys.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.There are not actually two separate class variables. Instead
input_labels(and the others) is a property that just returnsinput_labels.keys(). So no syncing issues (and you can usesys.input_labels.index('u')if you like -:).Reacted by Sawyer FullerRegarding 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 LiaoThat 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.
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.
I 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
interconnectinterface.Are there any additional changes we want for 0.9.4?
For version 0.10.0, I was thinking that we might:
matrixclass (no longer recommended by NumPy, though not yet deprecated)Use this issue to post thoughts and suggestions.