On 13.05.2010, at 21:23, Alois Schlögl wrote: > Lukas, > > > of course it is desirable to have a perfect solution. Until this goal is > reached, Oct2mat is a great help and readly available for those who have > the need of free toolboxes for matlab. And its not that nobody does the > manual changes - I started doing it for functions that I needed, and > extend the support and a few more. Others > might do so, too. Lack of support for texinfo help string and package > manager in matlab is not a crucial factor, I think. I'm happy with > addpath/rmpath. But if there is a need for a package manager, someone > might do it. > > >> If you are interested in porting control to Matlab, I urge you to >> copy the files to octave-forge/extra and name it something like >> control_ml. Then you could start porting the oct-files or running the >> conversion scripts. > > Currently, I do not have plans to do this. But its good to see that you > are not opposed to the idea.
I think as long as you use copies of the packages in /main for your conversions, there won't be any opposition. >> >> >>> You are right Mathworks sells a control toolbox. But it does not >>> mean that everyone with a Matlab license has also a license for the >>> control toolbox. Just recently, I did a course at the university >>> in a computer lab with 20 people. Licenses for Matlab were >>> available, and at the first glimpse it seems that also all >>> necessary toolboxes were available (we needed about 5 functions >>> from signal and statistics toolbox). However, when we tried to use >>> functions from these toolboxes, these licenses were locked to some >>> other department and we could not use them. Such a situation can >>> also happen to users of the control toolbox. >> >> They should install Octave :-) There are even graphical frontends >> like QtOctave and XOctave for those who need such things. > > > Certainly. But at this event, only Windows machines were available and > Matlab was already pre-installed. I had little options > about the setup. (and i do not want to say it loud, but M is still > faster, [1]. Admittingly, Octave has improved since 2006, and I see only > difference by a factor of 2-3 instead of 4-5). > > [1] http://arxiv.org/abs/cs/0603001v1 Hey, einem geschenkten Gaul schaut man nicht ins Maul :-) > >> >>> Concering Oct-files: you are right, oct-files can not be converted. >>> For this reason, I'm prefering the use of the mex-interface. The >>> mex-interface is also open, and available to Octave. If you want to >>> keep your the control toolbox to octave only, that's ok. But I can >>> imagine that also matlab users might be interested in your work. >> >> I prefer the OCT interface because it's object-oriented and fun to >> use. The MEX interface is neither of them. > > > O-O and fun? not for me! I think that's a matter of taste, I prefer C > over C++. Better control of memory management is also a good reason. > But I do not want to start a discussion about C vs. C++, its good that > both can be used simultaneously, and one can choose those concepts that > are more suitable to solve a problem. > > Following your argument, it would be of interest to make an > OCT-interface for matlab (similar to the mex-interface for octave). Nice one, you made me laugh :-) As I wrote below, I have very little motivation to write code for our "nemesis", "the dark side", ... My goal is a free and open control system design tool based on Octave. >> Since control is licensed >> under GPL 3, I couldn't keep it Octave-only even if I wanted to. The >> reason is that I just have no motivation to put any effort into it. > > That's fine. If there is a need for this, somebody else might step in. > > > Alois Best Regards, Lukas ------------------------------------------------------------------------------ _______________________________________________ Octave-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/octave-dev
