Menu
▾
▴
Re: [python-control-discuss] discrete time / multiple repositories
|
From: Richard M. <mu...@cd...> - 2011-12-27 23:44:48
|
My suggestion would be to have DStateSpace derive from Lti. To handle situations were the operations are the same, we could split out the add, multiple, etc routines from StateSpace and instead make them utility functions (not part of any class). Then statesp._add() could be called by both StateSpace.__add__ and DStateSpace.__add__ after whatever checks are required. -richard On 27 Dec 2011, at 8:37 , Gustavo Goretkin wrote: > So both TransferFunction and StateSpace inherit from Lti, which is a very simple class containing only two fields. > > Should I then make a DLti class with an additional field with the sample time? Or should DStateSpace inherit from StateSpace? Some of the DStatesSpace methods will closely mirror StateSpace methods. Namely, for the different binary operations, like multiplication, feedback, adding, the code needs to check that the sample time of both systems is the same, but other than that the matrix manipulation is the same. > > Is there another class hierarchy I should consider too? > > Thanks, > Gustavo > > On Fri, Nov 25, 2011 at 9:52 PM, Richard Murray <mu...@cd...> wrote: > There's been some discussion on how to handle discrete time systems in the past. It would be great to get the discrete time routines into python-control as part of the next release. If I remember correctly, the approach that Roberto (or someone) originally took was to put in the field Tsamp into the StateSpace class and if this was nonzero then assume it was a discrete-time system (as you described). I think it would be a bit cleaner to define a separate class for discrete-time systems, perhaps something like this: > > Lti - general object for linear time invariant systems > StateSpace - continuous time, state space representation > TransferFunction - continuous time, frequency domain representation > DStateSpace - discrete time, state space representation > DTransferFunction - discrete time, state space representation > > The 'D' versions would have to have all of the methods for manipulating discrete time systems and eventually we would have to update various time and frequency domain routines to support them (bode, nyquist, lsim, etc). > > Of course, the person who does the work gets to make at least the initial choice of how to implement. So perhaps Gustavo should take a first cut based on what makes sense to him, then we can see how things look and modify if there is a strong feel that we should implement it differently. Note that many things are likely to break/behave oddly when discrete time first gets added since a lot of functions don't check to see what type of system they are passed. > > In terms of repositories: SourceForge is the "official" home of python-control, but of course others are welcome to generate versions of their own, which eventually should make their way back here. Eike Welk is on this list and I've been incorporating his changes as I see them. > > -richard > > On Nov 25, 2011, at 12:21 PM, Gustavo Goretkin wrote: > > > Hey list, > > > > I'd like to try use some discrete-time in python-control. > > Specifically, I want MATLAB's c2d and dlqr. > > > > I'm aware of the discussion here [1] and code here [2]. yottalab.py > > has a all the functionality I want (thanks!) but I'm not sure which > > branch of python-control it is assuming. Specifically in c2d, line > > line 173, there is a call to construct a statespace object which takes > > 5 arguments A,B,C,D,Ts, but no such constructor seems to exist in > > python-control. From the rest of the code (i.e. d2c), I infer that all > > it seems to do is add a field called "Tsamp" to the statespace object. > > > > If the statespace object can represent both continuous and > > discrete-time systems, what then should the semantics be? It looks > > like Tsamp=0 for continuous time systems. > > > > It also looks like there is a repository here [3]. Is it going to be > > merged with the sourceforge repository eventually, or other way > > around? > > > > Thanks! > > Gustavo > > > > [1] http://mail.scipy.org/pipermail/scipy-dev/2010-August/015468.html and > > [2] www.dti.supsi.ch/~bucher/wp-content/uploads/2011/03/yottalab.py > > [3] https://bitbucket.org/eike_welk/python-control > > > > ------------------------------------------------------------------------------ > > All the data continuously generated in your IT infrastructure > > contains a definitive record of customers, application performance, > > security threats, fraudulent activity, and more. Splunk takes this > > data and makes sense of it. IT sense. And common sense. > > http://p.sf.net/sfu/splunk-novd2d > > _______________________________________________ > > python-control-discuss mailing list > > pyt...@li... > > https://lists.sourceforge.net/lists/listinfo/python-control-discuss > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > _______________________________________________ > python-control-discuss mailing list > pyt...@li... > https://lists.sourceforge.net/lists/listinfo/python-control-discuss > > ------------------------------------------------------------------------------ > Write once. Port to many. > Get the SDK and tools to simplify cross-platform app development. Create > new or port existing apps to sell to consumers worldwide. Explore the > Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join > http://p.sf.net/sfu/intel-appdev_______________________________________________ > python-control-discuss mailing list > pyt...@li... > https://lists.sourceforge.net/lists/listinfo/python-control-discuss |
