Re: Compatability and an engineer's perspective

[Carnë Draug]

On 18 July 2012 08:05, Jonathan Lister <address@hidden> wrote:
>>
>> ---------- 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.

Octave code is octave code which may or may not run in matlab because
matlab hasn't implemented all of octave functions yet. It makes no
sense for octave-forge developers to limit themselves because of
matlab. Not only would lead to worse code in octave-forge, you are
assuming that octave-forge developers know what matlab does and are
thus able to write compatible code. Well, that's not true. We write
octave, not matlab code.

> I've been thinking about how to do an oct2mat tool.  Perhaps, I can make a
> preliminary stab at it.

This has already been done. It's one of the octave-forge packages.

Carnë