@Tony, I agree on pulling from the debian repo. Doesn't make sense to rehost code. The only things that need to be changed are the build process, and the alternate xerbla.f file. Perhaps the makefiles and the xerbla subroutine could live in the git repo, and julia could just switch them out?
@Simon, I initially started off using the polynomial package, but stopped due to its limitations and some design decisions. I may try to integrate my added functions and send them a pull request. As for the DSP library, nice work! The python control package integrates nicely with scipy's dsp functions, perhaps there's a way we could do the same? Two thoughts on this: 1.) Conversion function between DSP types and control types - or - 2.) Same base type for both DSP TF and control TF (they're basically the same) For ease of use, I'm leaning towards the first one. Does DSP.jl support mimo systems? For those interested in helping, perhaps we should move this discussion somewhere else? Not sure if github issues are the best way to communicate, or if a google group should be started up. -Jim On Friday, February 21, 2014 5:40:52 PM UTC-6, Simon Kornblith wrote: > > This is great! ss2tf and potentially other functionality is also relevant > to DSP more generally. We currently have conversions between most standard > filter representations in DSP.jl (see > https://github.com/JuliaDSP/DSP.jl/blob/master/src/filter_design.jl) but > no state space representation. There is also a Polynomial package ( > https://github.com/vtjnash/Polynomial.jl) that may be a good place for > polynomial-related functions to live. > > Simon > > On Friday, February 21, 2014 1:11:19 AM UTC-5, James Crist wrote: >> >> Hello all, >> >> Glad to see there's some interest in this. I'm the one behind >> https://github.com/jcrist/Control.jl. >> >> I've been working through the getting the base types defined, before >> starting work on the analysis functions. The first goal is to get something >> simliar to matlab's basic control toolbox, with all the commands that an >> undergrad would use in an intro course. After that, higher level stuff will >> be tackled. Both Python control and Octave's control toolbox have been >> serving as inspiration. It's surprising (not really actually) how easily >> most of this transposes into julia. >> >> I need to get ready for a seminar I'm giving tomorrow, but over the >> weekend I plan to commit a major refactoring of the base types >> (TransferFunction and StateSpace) to make them more julia-friendly (python >> has pythonic, what's the julia version?). After that, it should be fairly >> trivial for others to write functions that work on these types. >> >> Slicot will be used to do all the heavy lifting, because it's free* and >> why bother reinventing the wheel. I have a set of wrappers that I generated >> for the raw interface that still need a human to look over them. I was >> planning on doing it as I got to using individual functions, but that'd be >> an easy thing to look through for others. >> >> - - - - - >> >> Major quesion of the moment: what plotting library is best plotting >> library? I'm coming from heavy python usage, so winston's syntax is more >> friendly to me. But gadfly looks great as well. I'd rather not use pyplot >> - I'd like to keep it as much in julia as possible. Thoughts? >> >> -Jim >> >> *Slicot (per they're website) is no longer GPL after version 4.5. >> However, the debian repo has 5.0, and the tar ball I got contains a GPL2 >> license. Not sure what to make of this. The most recent free version should >> definitely be the one used. >> >> On Thursday, February 20, 2014 9:25:10 PM UTC-6, Jeremy West wrote: >>> >>> I guess somebody got impatient with my disappearance :) I'll probably >>> contribute to that instead, it looks like a similar roadmap I had in mind >>> before things got messy. >>> On Feb 20, 2014 8:00 PM, "Tony Kelman" <[email protected]> wrote: >>> >>>> Well and at least a start on some useful functionality, to get >>>> everybody in the same place and not duplicating the initial effort. >>>> >>>> Those kite power projects are so incredibly cool! I imagine you're >>>> using some combination of Casadi, Acado, and/or Optimica? >>>> >>>> I do model predictive control at Berkeley, we have our own custom >>>> Matlab/Simulink tools that work pretty well for our uses but longer-term >>>> I'd rather have something more elegant (and in an open environment) that >>>> doesn't have to work around Matlab's limitations and Simulink's 10+ >>>> subtly-incompatible but still-in-common-use versions. >>>> >>>> >>>> On Thursday, February 20, 2014 4:08:54 PM UTC-8, Uwe Fechner wrote: >>>>> >>>>> Hi, >>>>> >>>>> this looks already promising. The important thing is to get started >>>>> and to have an issue tracker, and with this >>>>> git repo this is already in place. >>>>> >>>>> I am currently working on automated control of kite-power systems. A >>>>> little video about our >>>>> project: http://www.youtube.com/watch?v=FJmlt3_dOuA >>>>> >>>>> Best regards: >>>>> >>>>> Uwe >>>>> >>>>> Am 21.02.2014 00:24, schrieb Tony Kelman: >>>>> >>>>> Have a look here, https://github.com/jcrist/Control.jl is making >>>>> better progress than anything else I've found in the topic. He has >>>>> wrappers >>>>> to Slicot as well. >>>>> >>>>> On Thursday, February 20, 2014 1:56:20 PM UTC-8, Uwe Fechner wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> I could not find any control system library for Julia yet. Would that >>>>>> make sense? >>>>>> There is a control system library available for Python: >>>>>> http://www.cds.caltech.edu/~murray/wiki/index.php/Python-control >>>>>> >>>>>> Perhaps this could be used as starting point? I think that >>>>>> implementing this in Julia >>>>>> should be easier and faster than in Python. >>>>>> >>>>>> Any comments? >>>>>> Should I open a feature request? >>>>>> >>>>>> Uwe Fechner, TU Delft, The Netherlands >>>>>> >>>>> >>>>>
