Re: A question on Matlab compatibility

[Joe Koski]

on 9/16/06 5:06 PM, Ron Crummett at address@hidden wrote:

> I'm not sure if I completely follow that.  Looking at the code for both
> series and sysmult, I see that both were copyrighted in 1996 but that
> sysmult was again copyrighted in 1999.  Whether sysmult was written
> before the Matlab control toolbox came out or after, it looks to me like
> there was a function called series that performed a cascade of systems.
> But really, that's beside the point.
> 
> All I am really trying to do is raise the issue of compatibility.  If
> Matlab has a function that performs a series cascade of two systems and
> it is called 'series', and Octave has one that does the same thing, also
> called 'series', but it is preferred that you use this other one called
> 'sysmult' instead...why not just call it 'series' and maintain
> compatibility?
> 
> This is just one example that I have seen.  There are others...for
> example, there are no filter conversion functions such as 'lp2lp' and
> 'lp2bp' - instead, there is just one, 'sftrans', which I have never been
> able to figure out and which has no Matlab counterpart.  Again, I am
> sure that sftrans is a fine function and does its job well...but when I
> write code under Matlab and then try to run it on Octave later, I am
> expecting to be able to do so without having to do a lot of editing in
> my code.  Some is necessary, I understand that.  But when I want to do
> 'a' and am told that 'a' does not exist but 'b' does the same
> thing...why not just call it 'a' in the first place and save a lot of
> headache?  If it is a simple matter of renaming the functions and
> resubmitting them, I'll do it.  I can change a line of code or two, save
> it under a different filename and resubmit it, so long as I don't upset
> the powers that be who wrote these functions in the first place.
> 
> -Ron

Ron,

I took my digital signal analysis course about 25 years ago, so now I mostly
trust that what's there is OK. You have some very good points that could
lead to some significant improvements in both octave and octave-forge.

Both the problem and the advantage is that octave is open source software.
This may be the right time to update all the dsp routines, but someone needs
to step forward and volunteer to do it. Signal processing is a very
specialized field, and only a few are qualified to do such an upgrade. Those
who are capable are probably already working on a textbook to publish.

There are some other packages out there that, while open source, aren't
included directly into octave. That doesn't stop people from adapting and
using them. Two examples are the Time and Frequency Tool Box (tftb) at
http://tftb.nongnu.org/ and WaveLab at
http://www-stat.stanford.edu/~wavelab/.

I also use the Stearns and David routines from the book "Digital Signal
Processing Algorithms in Matlab," first because they seem to be more a bit
robust than the octave-forge filter routines, and second because 25 years
ago, Sam Stearns had his office down the hall.

The bottom line is that it is not difficult to adapt open source MATLAB
routines to octave. There will never be complete compatibility between
octave and MATLAB, especially in the ToolBox/octave-forge areas because
there is no reason or incentive for that to occur.

My thought is that if I use open source software, I should give back where I
am able. On balance, I probably get more from octave use than I give back.

Joe