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: Emmanuel FARHI
Subject: Re: Opinions on Matlab compatibility, Octave development
Date: Wed, 2 Jun 2010 22:12:27 +0200 (CEST)
User-agent: SquirrelMail/1.4.16

Hi guys,

I've been using Matlab, Octave, Scilab and IDL for many years now. I
really think it all relates to personal feelings. The main question is:

* how fast and easily can you achieve a task ?
* is the resulting code understandable by somebody else ?
   (that is maintainable)

Coming back to Matlab/Octave compatibility, I think it should be as close
as possible to decide Matlab users to switch for Octave.

In this respect, Scilab is following the same strategy as Octave these
days: get closer. It was not the case in the past, and made code porting a
hard task (grammar, syntax is different). Scilab has a similar
parameter=value non positional argument list in functions, like IDL.

Questions about memory management are in this respect minor issues, as
computers have today vast amount of memory. Of course, whenever possible,
res-use of temporary arrays should be preferred.

One of the good points of IDL is clearly speed with images and large
matrices. Matlab is catching up, but stays behind. The plotting are now
similar, but Matlab has always be in advance w.r.t. IDL (which plotting
was for long really bad). Plotting in Scilab is now very good, including
Java support and uicontrols. Octave is suffering from this (the java stuff
is too hard to install - I never succeeded to use it).

One of the good point of Matlab, and Octave, resides in a cleaner syntax
(for me), and the object definition (class) is far simpler than in IDL. I
really like it, much more than other OO codes as python. Scilab
corresponding mechanism is dramatic and unusable.

All in all, I guess all packages adopt solutions which provide reasonable
- if not optimal - solutions in the frame of the past language history
(habits, keywords, constraints...).

And thanks for making Octave a real challenger to Matlab and IDL (except
for uicontrols ;-) ).

Emmanuel.

> On 6/2/10, Judd Storrs <address@hidden> wrote:
>> 2010/6/2 Jordi Gutiérrez Hermoso <address@hidden>:
>>> 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.
>>
>> Personally I think the Matlab language does many things wrong and
>> sometimes I wish octave users and developers had more exposure to IDL
>> (not that I would wish IDL on my enemies...). IDL also does many
>> things wrong and can be very difficult to learn and way frustrating to
>> maintain, but IMHO the IDL approach is superior in many areas.
>> Mathworks seems to finally be getting around to trying to copy IDL and
>> shellac IDL features onto the Matlab language. Mathworks added
>> JIT--IDL had this way back when it was still called "incremental
>> compiling" and the new OOP style reeks of being copied straight from
>> of IDL. In my mind the major good features that Mathworks has not yet
>> gotten around to stealing from IDL are:
>>
>> 1) Vastly better handling of optional parameters and flags. Octave
>> added defaults which is a step in the correct direction. Matlab's
>> "property",value pairs are ridiculously stupid in comparison to the
>> IDL approach.
>>
>
> I don't think it's that bad. Surely, the necessity to parenthesize the
> keywords is a bit of burden, but otherwise the approach is basically
> equivalent, from a user point of view, to other languages with
> explicit keyword arguments, like Python (I don't know IDL but I assume
> it's similar there). The positive is that it doesn't need a special
> syntax, and using runtime-constructed argument lists is natural. A
> disadvantage is that parsing is difficult, but a lot can be handled by
> extra funcs (cf. Octave's new parseparams).
>
>> 2) Pointers. Matlab's response to pointers was cell arrays--which
>> really isn't really much of a response if you're trying to build
>> something like a doubly linked list.
>>
>
> I believe that Octave and similar languages are totally unsuitable for
> low-level stuff like this. Cells should cover most usages you could
> need a list for, and if you need something special, it's probably
> better to make a C++ extension. Python is perfectly capable of
> implementing a doubly linked list yet I never ever needed to do it in
> there. It's not C.
>
>
>> 3) Pass by reference semantics. I know this seems to be a holy war.
>> Apparently octave users/developers have swallowed Matlab's FUD.
>
> Again, I don't know how IDL's pass-by-ref works, but if it's like
> Python, then that is one of the strongest pluses of Octave/Matlab. In
> Octave, you never need to ask "can I write to this object?" because
> you always can, anything in your scope is truly yours. So you can
> clear NaNs on input with x(isnan(x)) = 0, and Octave will make a copy
> of x for you if needed.
>
>> IDL's
>> interpreter knows about intermediate or temporary values and will
>> operate on them in place if possible.
>
> I tried to do something along these lines last year, so that (a+b) + c
> uses just one temporary, but eventually I reverted most of the change
> back. It spawned an awful lot of problems involving decisions when and
> how this can be done, and confused error messages, and I still seemed
> to be able to reuse intermediates better by hand using the in-place +=
> et al. operators. Besides, the true ultimate optimization of such an
> expression is to do it in just one loop (which needs a JIT). So, the
> only thing left from that experiment is that unary - and ! will
> operate in-place when applied to a temporary.
>
>> Matlab seems to be adding crap
>> extensions that can be used to emulate this such as shared memory
>> segments. I believe Jaroslav has added this sort of thing now for the
>> ++ and -- octave extensions so maybe we're moving in the right
>> direction here.
>>
>
> Yes, like +=, ++ will now attempt to operate in-place.
>
>> 4) Powerful generic visualization utilities. Matlab's efforts in this
>> realm are pathetic.
>>
>> That's not to say that IDL doesn't have problems and annoyances--it
>> has probably more than it's fair share. At this point I prefer to use
>> octave over Matlab and IDL because octave sucks way less than either
>> Matlab or IDL.
>>
>> Anyway, all I'm trying to say is that Matlab is a pile of populist
>> crap so I also wouldn't place too much weight on compatibility.
>>
>>
>> --judd
>>
>> _______________________________________________
>> Help-octave mailing list
>> address@hidden
>> https://www-old.cae.wisc.edu/mailman/listinfo/help-octave
>>
>
>
> --
> RNDr. Jaroslav Hajek, PhD
> computing expert & GNU Octave developer
> Aeronautical Research and Test Institute (VZLU)
> Prague, Czech Republic
> url: www.highegg.matfyz.cz
>
> _______________________________________________
> Help-octave mailing list
> address@hidden
> https://www-old.cae.wisc.edu/mailman/listinfo/help-octave
>


--
FARHI Emmanuel <address@hidden>
Groupe DS/CS, ILL4/156, Tel 04 76 20 71 35
ILL, Grenoble




reply via email to

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