Re: Opinions on Matlab compatibility, Octave development

[Alois Schlögl]

Jaroslav Hajek wrote:
> On Mon, Jun 7, 2010 at 11:02 PM, Alois Schlögl <address@hidden> wrote:
> > Jaroslav Hajek wrote:
> > > 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 few 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 :)
> >
> > It was not a question, but a statement.
>
> Even statements can have answers :) Seriously, there will always be
> many Matlab functions missing in Octave. I think the Octave community
> simply doesn't have enough contributing potential to catch up with
> Matlab. So we only select some functions, according to our needs. GUI
> funcs consistently lose in this match because the most active
> contributors tend to not use them.
>
>
> > > > 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.
> >
> > Ok, you got me.
> >
> >
> > > > 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?
> >
> > Its free software. But to be honest, I do not see an advantage of these
> > octave-specific constructs.
>
> *You* don't, because your primary tool is Matlab, and you need
> compatibility. If you ever ditch Matlab and switch to Octave, you
> probably will see it.


Even if I would ditch Matlab, the users of Biosig and other legacy 
software will not switch. As explained already, there are valid reasons 
for not switching - ignoring these is short-sighted.


> > Performance advantages are disputed,
>
> Only in some cases. For instance, the performance advantage of a += b
> when a is a matrix is easily demonstrated.
> The advantage of f(x)(:), num2cell (a){:} and similar constructs is
> that the intermediate value is readily cleared when no longer needed,
> without explicit clear.
>
> Btw, it would be *really* difficult to make the interpreter
> automatically clear temporary variables, because of functions like
> clear, save or eval, which make indirect references to variables.
>
> > and
> > incompatibilities come with significant costs (either two different
> > implementations, one optimized for O and the other for M, or living with
> > suboptimal performance at least for some users). The benefit-cost difference
> > of these extensions seems to be mostly negative.
>
> Again, that is subjective.


This thread is about opinions. And its the nature of opinions that tehse 
are personal and subjective. Nevertheless, belittling my arguments does 
not change the facts.


> > > > 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.
> >
> > I do not know whether there would be any benefit for you personally. But I'm
> > pretty sure that the Octave-project-at-large (including e.g. octave-forge),
>
> Yes, I agree that the packages in question can benefit, I just don't
> think that Octave benefits.
>
> > and the idea of free software would benefit if more people would use free
> > software. This is certainly also one of the key aims of GNU/FSF, to which
> > Octave is a part of.
>
> However, this may not always be best achieved by making the software
> available to the widest audience, incl. compatibility with proprietary
> software. By words of R.M. Stallman,
> "Proprietary software developers have the advantage of money; free
> software developers need to make advantages for each other."
> (cf. http://www.gnu.org/licenses/why-not-lgpl.html)


This discussion is not about GPL-vs-LGPL. I've licensed my software 
(biosig, TSA-tb, NaN-tb, etc) with GPL. I've put additional effort into 
my software to make it work with Octave, too.

Making something work with Matlab is not about supporting Mathworks, its 
about supporting the *users* of Matlab, and showing *them* the 
advantages/beauty/any-other-benefit of free software.


> > > > 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.
> >
> > Come on, with your abilities, you can do it blindfold.
>
> Yes, I probably could, and I would be even relatively happy to see it
> done, but I'm specifically leaving this project to someone else as a
> warm-up :) 


This is childish - grow up.


> But even if it's done, I won't stop using (:), it's just
> more elegant.
>
> > Moreover, it might be
> > a tool were the user experience (running the same code from some octave
> > toolboxes) shows an advantage of Octave over Matlab because Matlab will have
> > only an m-file implementation of vec(). Or if Mathworks is going to
> > implement a builtin vec(), than Octave has been leading.
>
> Er, I'm not sure, but I think Matlab has no vec() at all...?


Unlike the functionality of (:) in fun(x)(:), vec.m can be easily 
provided to the users of Matlab.


> > > > 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.
> >
> > If Matlab is inconsistent, why not make it consistent in Octave? There is
> > neither a good reason nor the need to mimic such inconsistencies.
>
> Except compatibility, which is often a good reason. Personally, I
> wouldn't object to making it consistent, though.
>
> > Concerning median(): there is just an extra copy of all none-NaN values
> > needed. This takes only O(N) effort. Then call nth_element; the overall
> > effort would still be O(N).
>
> Yeah, for a vector, this is trivial, but median is supposed to work on
> arrays, along arbitrary dimension. And please keep it vectorized and
> efficient :)
>
> > > 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 :)
> > Perhaps, there was too little thinking. :-)
> >
> >
> >  A.