Re: Opinions on Matlab compatibility, Octave development

[Jaroslav Hajek]

On Tue, Jun 8, 2010 at 11:14 AM, Alois Schlögl <address@hidden> wrote:
> 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.
>

Yes, of course, nobody says that those who don't switch to Octave are
a bunch of idiots. There are valid reasons for switching as well, so
it is up to everyone to decide for himself which reasons are more
important.

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

Exactly, opinions and facts. I just wanted to make sure we both
realize the difference :D

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

No, of course not, I just pointed out that I can make analogous arguments.

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

That's great.

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

Free software, yes, but not Octave in particular. By Matlabizing an
Octave package, you remove one (however small) direct incentive for
people out there to use and contribute to Octave. Demonstrating the
advantages and beauty of free software to them is, at best, an
indirect incentive for using Octave, and you can hardly measure
whether the latter outweighs the former. Personally, I believe that in
most cases it doesn't.

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

No! :-P

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

Aha. So even Octave's current vec() implementation is better than
Matlab's. Though a built-in would of course be yet better. I'll create
it for 10 EUR. Anyone interested? :D


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