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: Jaroslav Hajek
Subject: Re: Opinions on Matlab compatibility, Octave development
Date: Mon, 7 Jun 2010 13:08:32 +0200

On Mon, Jun 7, 2010 at 12:00 PM, 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.
>

That depends. For me, the compatibility has a mostly theoretical value :)

> 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).
>

I believe that MathWorks simply ignores any effects of its changes on
Octave or Scilab or FreeMat. 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.
>

Well, I believe you know the answer to this one :)


> 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.
>

I'm not happy for slow code, but if the code can be optimized for
Octave, that makes me reasonably happy. It would, indeed, be better if
Octave could crunch all code fast, but something is better than
nothing. And a good reason for using Octave extensions.


> 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?

See the comment.

> The same is done by
>
>   dim = find(size (a) != 1, 1);
>

No, it isn't. Think again.

> 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.

Oh, what a crime. But I hereby solemnly swear by the Great Queen
Spider and every other deity that might be interested that I didn't
even think of oct2mat when I wrote that line.

>
> 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.
>

But the developers *can* decide, right?

> 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.
>

As far as I'm concerned, you still didn't convince me that there is
any benefit to Octave if free packages are being used with Matlab.

>
> 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.
>

It probably can (or at least almost as efficient, there's a function
lookup), but someone needs to do it first.

> 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.
>

I agree skipping NaNs is almost always better (except for rare cases
like using mean() to get simplex centroid), but unfortunately it makes
code less straightforward and usually slows it down, sometimes
significantly. For instance, it would currently be quite difficult to
get median() skip NaNs while still preserving the O(N) performance for
any dimension.

The interesting thing is that in Matlab mean and std don't skip NaNs
whereas skewness and curtosis do. So I wonder what thinking led to
this situation :)


-- 
RNDr. Jaroslav Hajek, PhD
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz



reply via email to

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