octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: future development of the control package


From: Lukas Reichlin
Subject: Re: future development of the control package
Date: Sat, 31 Oct 2015 19:00:31 +0100

On Sat, Oct 31, 2015 at 2:46 PM, JuanPi <address@hidden> wrote:
> On Sat, Oct 31, 2015 at 2:19 PM, Lukas Reichlin
> <address@hidden> wrote:
> > Hi Thomas,
> > dear Octave community,
> >
> > On Friday morning, I have published control-3.0.0, the first major release 
> > after control-2.0.0 in early 2011. I’m very pleased with the outcome [1] 
> > and hope that it finds general approval. However, its development process 
> > during October 2015 was freelancing/a solo run and I did not include you in 
> > the decision process. For future releases, I would like to improve this and 
> > involve especially you (as co-author), but also other contributors 
> > (therefore CC’ing maintainers list), more into decision making. 
> > Appreciation and an attempt to increase the bus factor are two of the 
> > reasons for this step.
> >
> > Regarding control-3.0.1, I propose the following changes:
> > - Your work on tf2ss conversion
> > - Accepting only finite values as inputs, see bug #46330.  
> > <http://savannah.gnu.org/bugs/?46330>
> > - Fix problems with "algebraic loops» (as Matlab calls this) as outlined in 
> > [2].
> >
> > Regarding the third point, I wonder whether it’s possible to apply some 
> > kind of state transformation if matrice A is not invertible in the equation 
> > below. (such that C A^-1 B can be computed)
> >
> > y = [D - C A^-1 B] u
> >
> >
> > For the mercurial repository, I propose the creation of a second branch 
> > (besides default), named stable, similar to Octave.
> > I have tried to merge control-3.0.0 into your control-time-delay repo, but 
> > I had to give up. There were simply too many conflicts. Maybe it’s better 
> > when I create a «delay» branch in the control repo and you copy-paste your 
> > changes there? I could start by integrating your oct-files into a single 
> > __control_delay_functions__.oct.
> > Shall we create this delay branch before or after realizing the array 
> > feature? (see bug #45314, <http://savannah.gnu.org/bugs/?45314>). Please 
> > don’t feel pressed for an answer, we could discuss such topics in meeting, 
> > see the next paragraph.
> >
> >
> > Finally, I would like to propose a meeting in real life. Since you’re still 
> > working at ETH Zurich and we haven’t met for quite a while, what do you 
> > think about a meeting in one of its cafeterias (in November)? Fellow Swiss 
> > residents (JuanPi, Reza) are welcome as well!
> >
> > Best regards,
> > Lukas
> >
> > [1]
> > http://sourceforge.net/p/octave/control/ci/default/tree/NEWS
> >
> > [2]
> > http://sourceforge.net/p/octave/control/ci/default/tree/devel/algebraic_loops.m
> >
> >
> >
> 
> Hi Lukas,
> 
> Thanks for the initiative. With Reza we have been trying to organize a
> local code-sprint since our return from OctConf but so far we haven't
> come to it. Maybe we should take your initiative and build up on this.
> 
> Cheers
> 
> 
> --
> JuanPi Carbajal
> Public GnuPG key: 9C5B72BF
> -----
> The end of funding: "Many researchers were caught up in a web of
> increasing exaggeration."
> - Hans Moravec
> 
> On 31.10.2015, at 16:52, Reza Housseini <address@hidden> wrote:
> 
> Hello guys
> 
> Yes we should definitely do a code sprint on top of your great work!
> Shall we just announce it and then try to choose a date?
> 
> Cheers Reza
> 

Probably yes. You may want to set up a doodle survey to find a date. If we want 
to do actual coding work besides consultation, the location should provide 
public Wi-Fi (not restricted to eduroam).

Best regards,
Lukas





reply via email to

[Prev in Thread] Current Thread [Next in Thread]