From: Richard M. <mu...@cd...> - 2010-12-18 03:33:41
|
A couple of comments on your suggested changes (hopefully others will chime in as well): >> 1. MIMO - The most important item is a new LTI base class to support MIMO (and StateSpace and TransferFunction derived classes). This is discussed in the document lti_overhaul.pdf, and we have a skeleton of the python code, skeleton.py. The basic approach sounds fine, but I would suggest having the class named control.lti since I don't think python is going to get confused between that class and signal.lti. To some extent all of this is hidden from the end user, so probably doesn't matter much (just aesthetically I never like new classes that use '2' as the modifier). Other possibilities would be MIMO, LtiMIMO, etc. To Roberto's point, I think we should also think through how we want to do discrete time systems. Comments (and alternatives) on the class structure I outline would be great. I would eventually like to allow for time delayed systems as well (similar to MATLAB). >> 2. Documentation - Python, NumPy, and SciPy use Sphinx to generate the documentation found at their respective websites. For purposes of consistency, we will use the same. An example is provided in html.zip Sounds right to me. >> 3. New Functions and Unit Tests - We have implemented the gram, rss, and hsvd functions. We have also implemented unit tests for these functions as well as ctrb and obsv using the Python unittest framework. Next we are planning on wrapping SLICOT routines to add balred and modred functions. Good. We need to go through and start implementing unit tests for all of the other basic functions, so we can make sure that we have fairly comprehensive testing built into the package. >> 4. SVN Merge - After getting your feedback, we would like to implement the new MIMO Lti2 class. Once we have all of the wrinkles ironed out, we intend to make a merge back into the SVN repository. Until then, we are doing internal version control using Mercurial. Let me know what you think about the class name, but I think it is OK to commit when you are ready. If you are going to break some functions due to your changes, we should create a branch and update things there, so that trunk is always a working copy. -richard |