[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A question on Matlab compatibility

From: Ron Crummett
Subject: Re: A question on Matlab compatibility
Date: Sat, 16 Sep 2006 20:59:52 -0700
User-agent: Thunderbird (X11/20060909)

Maybe I'm missing something here, but I have always seen Octave-forge as an open-source attempt to include the functional extendability that the various Matlab toolboxes provides. As my primary interests lie in signal processing I find myself most concerned with those Octave functions whose Matlab counterparts are found in the Controls, Communications and Signal Processing toolboxes.

I have always been under the impression that to be included in Octave-forge, some requirements must be satisfied, in order to prevent anybody from writing some simple script and submitting it, only to have the rest of us in fits because we don't know how to use it. I am aware of the open source Matlab code provided by so many, having used some of it from time to time.

In the cases I have mentioned, I don't think it would be hard at all to provide more compatibility between Octave and Matlab. For example, Matlab has the series function that performs a multiplication of two cascaded systems. Octave has a function by the same name and with the same functionality, but when it is called displays a warning encouraging its users to use sysmult instead, a function whose name lends itself well to its performance. Yet if sysmult performs the same operation as series, then why not simply upgrade the original series function -- or, as it is now, why not simply rename sysmult to series? They both apparently do the same thing and series is on its' way out as it is, so by doing this I see no harm done and it would take as long to do as it has to write this email. As far as the filter conversion functions are concerned, sftrans could perform the underlying conversion - perhaps rename it __sftrans__ as seems to be convention for the "dirty work" functions - and then write lp2lp, lp2bp, etc. scripts that call __sftrans__. Again, Matlab compatibility is preserved and at very little effort. Heck, I'd do both of these if I knew I wasn't stepping on anyone's toes.

Perhaps a break-off of Octave-forge is needed, some sort of general code repository similar to the Matlab Central exchange. Octave-forge could be preserved with the goal of Matlab toolbox compatibility (again, that's how I've always seen it) and Octave-central (call it what you will) could be a third-party code submission where people submit their task-specific code.

To be honest, I could go on and on about improvements I'd like to see in Octave and its' attendant websites, but you've all heard enough from me.


Joe Koski wrote:
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

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.



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 and WaveLab at

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]