---------- Forwarded message ----------
From: Przemek Klosowski <address@hidden>
To: <address@hidden>
Cc:
Date: Mon, 16 Jul 2012 17:34:58 -0400
Subject: Re: Compatability and an engineer's perspective
On 07/15/2012 07:02 PM, Jonathan Lister wrote:
So, when I can take the Signal Processing Toolbox from Octave and run it
in MATLAB it allows me to prove (in a more credible way) that Octave is
a sound alternative.
But why do you want to run this Octave toolbox on Matlab? If Octave code requires Octave, Matlab users can always try Octave. If Matlab code requires Matlab, users can't just come up with Matlab on a short notice, so Octave tries to emulate as much of Matlab language as it can.
Of course anyone can chose to avoid Octave language extensions if they want to offer their software to both Matlab and Octave users. It seems to me that Mathworks actually discourages such sharing---I seem to remember that Matlab Central forbids running even user-contributed code in non-Matlab environment. It seems to me that Octave-friendly Matlab users such as yourself should contact Mathworks and suggest to them more cooperation in areas such as:
- adopting the best Octave language extensions
- coordinating future language extensions with Octave developers
- promoting not hampering third-party code compatibility
- making Central licensing more cooperation-friendly
I personally think this would help their business, by broadening their market. As it is, they seem to studiously pretend to not notice Octave, but the cat is out of the bag. These are my own opinions, based on my personal experience, anyway.
The idea that Octave code is just Octave code isn't actually correct. I've had no problem porting the Octave-Forge Signal Processing tool box or Statistical Toolbox over to Matlab. As long as Octave extensions to the m-language their should be no difference. I've found that to be the case so far. Octave's FFT works like Matlab's FFT. The only Octave functions that tend to give me difficulty are those like ___functionX___ . Matlab doesn't like function names like that. So I have to change the name. Matlab's find in files search feature makes it almost effortless to change all the calls to functions like that. No problem at all sharing between the two.
When I mentioned handle graphics I was meaning user programmable GUI's. (uicontrols) Handle graphics isn't just the handles to the figures. I am glad to see progress on it.
I've been thinking about how to do an oct2mat tool. Perhaps, I can make a preliminary stab at it.