help-octave
[Top][All Lists]
Advanced

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

Re: Opinions on Matlab compatibility, Octave development


From: Alvin Wibowo
Subject: Re: Opinions on Matlab compatibility, Octave development
Date: Mon, 7 Jun 2010 19:34:47 -0700

On Mon, Jun 7, 2010 at 3:00 AM, Alois Schlögl <address@hidden> wrote:

First, Octave is currently the most compatible alternative to Matlab. If
I should but a number on it, 95% of the code is compatible, and it is
possible to write code that is compatible with both. I think, this is
the main advantages of Octave over alternatives languages.

Within the family of mostly Matlab compatible tools (Scilab, Freemat,
Octave), comes octave with the best compatibility and performance ratio.
I think performance and compatibility with Matlab are the main
advantages of Octave over alternative tools. It is no fun that  Matlab
is currently setting the standard of the m-language alone, and break
backwards compatibility. But so far I've not observed a willful change
in the interface in order the exclude others; for the lack of evidence,
we should assume that changes were a made in order to improve the tech.
(If you have information to the contrary, that would be interesting).

So compatibility is an important issue for Octave. If this aim is lost,
some other project will take over the position of the "most compatible
project". Octave is doing quite well but still it could do better. Here
are a view examples from my personal view:

1) There are a number of functions missing:
I wanted to port some legacy code to octave and was missing uimenu and
uicontrol, uigetfile, etc.. This is one reason why people still keep
using Matlab.

2) Performance for standard m-code, I mentioned this already, is
important. Nobody is happy, if the same code is much slower. That's very
important for the large amount of legacy code that people have developed.

3) Code obfuscation is not helpful. Here is an example:

  dim = [find(size (a) != 1, 1), 1](1); # First non-singleton dim.

What is the purpose of such constructs? The same is done by

  dim = find(size (a) != 1, 1);

The only reason for doing this is to make it more difficult to use it
within Matlab - because Oct2mat does not support the translation. You
can find this example in the code of center.m, and the same code was
also part of median.m until a few day ago.

4) Octave - specific language elements like: k++, a+=b, fun(x)(:), etc.
I understand that there might be an advantage of these constructs, in
terms of performance. However, it comes at the cost of incompatibility.
Here, I'd like to see performance tests that are really demonstrating
the advantage, so the application developers can decide themselves
whether its worth using these constructs.

These octave-specific language elements are mostly an issue of
application programmers, I think it is also a success for Octave, when
people start using free toolboxes on top of Matlab (like
oct2mat/freetb4matlab is aiming at), instead of proprietary ones. In
order to achieve this, the code must be compatible, at least the
approach of oct2mat/freetb4matlab should be supported.

Octave should not make it difficult but easy to write compatible code.
The main idea should be that Octave should aim for compatibility AND
performance. For example, fun(x)(:) can not easily translated, using
vec(fun(x)), does the some thing and can be easily made compatible. And
I'm sure that supporting vec as builtin implementation can be made as
efficient as the (:) operator.

Having said this, I also agree (partially) with the cited statement from
jwe[2001]. I'm too, not always in favor of maintaining compatibility.
One example is how missing values are handled in the statistical
functions toolbox. In statistics, missing values can be just ignored.
The NaN-toolbox has  implemented this idea. This has several advantages:
(i) one does not need to think about whether MEAN, STD, VAR etc. or
NANMEAN, NANSTD,  NANVAR etc. should be used. (ii) One gets more often
reasonable and meaningful results instead of "no result" indicated by
NaN. This is an example were some of the legacy need to be overcome.
However, it is also important that users of matlab have a way to use
these new features. Only then, it will be possible to have an influence
on the "standard" of the m-language.

These are few thoughts of mine about the issue of Matlab compatibility
and Octave development.


   Alois



> I was reading an old article of jwe's from 2001[1] and was
> particularly interested in section 4, which I briefly cite here:
>
>> I no longer believe that compatibility is a reasonable goal. It
>> stifles innovation and places the project in the position of never
>> being a leader, always being a follower, and quite far behind almost
>> all the time.
>
>> If compatibility is a goal, almost no innovation is allowed, because
>> there is the potential for any new feature to be incompatible with
>> future versions of Matlab. (This is not just an imagined problem—it
>> has happened in the past, and I expect it will happen again.)
>
> I am wondering, how do people feel about this at the moment? Playing
> the compatibility game does seem quite boring, but it's a very
> frequent request from Octave users. Furthermore, Octave has been
> listed in GNU's high priority project list[2] for some time as a
> replacement for Matlab.
>
> Further down he laments:
>
>> Octave has never developed a strong core of dedicated and competent
>> developers.
>
> This certainly seems to have changed since 2001, hasn't it? I would
> have to generate a code swarm or look at it with gource, but at least
> in the old one from a couple of years ago[3], there does seem to be
> quite an explosion approximately in the middle the 2000's. I think
> there's even a greater speedup around the time when the sources moved
> to hg.
>
> Thoughts?
> - Jordi G. H.
>
> [1] http://www.ci.tuwien.ac.at/Conferences/DSC-2001/Proceedings/Eaton.pdf
> [2] http://www.fsf.org/campaigns/priority-projects/index_html/#gnuoctave
> [3] http://jordi.platinum.linux.pl/movies/octave-swarm-fast-take3.ogg


_______________________________________________


I agree. As long as it doesn't involve simulink or control package commands, Octave has the best compatibility to Matlab compared to other Matlab-like software, such as Scilab.

Kudos to Octave team.

--
"Procrastination is the art of waiting."

reply via email to

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