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: Wed, 2 Jun 2010 20:20:31 +0100

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



reply via email to

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