Lukas Reichlin wrote: >> Lukas, >> >> >> thanks for your comments. I'm not sure I understand your comment on >> "those automated changes just mess things up". The point of the >> patch is that in some cases its better to use a manual change in >> the source code, rather than applying an automated script. > > IMO it doesn't make sense to partially convert the files when nobody > does the manual changes afterwards, because they won't run on Matlab > this way and it's possible they introduce errors. There are some > issues like texinfo help strings and oct-files. AFAIK, Matlab even > lacks a package manager.
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. > > >> 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 > >> 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). > 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 ------------------------------------------------------------------------------ _______________________________________________ Octave-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/octave-dev
