[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: octave to matlab conversion

From: Julius Smith
Subject: Re: octave to matlab conversion
Date: Sat, 8 Oct 2005 00:46:05 -0700

On 10/7/05, Tom Holroyd <address@hidden> wrote:
> > ML survives (and thrives) because it
> > posesses advantages and capabilities over other languages
> Bzzt.  From a language perspective, ML sucks.  Python, with its
> numerical extensions, is much, much superior.  I can think of NO
> advantage for ML, language-wise.  ML's syntax is inconsistent,
> awkward, and frankly Fortran-like (no mystery there).

>From a quick look at the SciPy level of Numerical Python, I would say
Matlab (Octave) is generally more concise syntactically.  For example,
instead of
as in Matlab, one seems to have to type
x = arange(0,1,0.1)
in SciPy.

It also appears that the ':' operator is not generally available in
matrix/vector expressions, and matrix transposition with ' has no
counterpart, etc.  In summary, one is really just working in Python
with some objects defined to bring linear-algebra sorts of things to a
higher level.  There is no real math-syntax support on the level of
Matlab at all.

(I'm just now looking at for the first time, so
apologies if I'm overlooking anything.)

For matrices, I find it humorous that they are most easily entered
using Matlab syntax embedded in function arguments, such as

A = mat('[1 2 3; 4 5 6; 7 8 9]')
b = mat('[10 11 12]')

Then, to solve "A x = b", one says

x = linalg.solve(A,b)

instead of "x = A\b".

The *only* advantage I can find to SciPy syntax is being able to break
out vectors into variables with constructs such as

x0,x1,x2  = x

I don't think Matlab has any concise way to do this.

I don't see being in a "real programming environment" as an issue,
since I can always write dynamically loaded compiled extensions when I
need to write fully general and fast routines.  I also find it quite
easy to run external command-line tools with the system() command.

I never have any problems with "inconsistencies" in Matlab syntax, so
how bad could they be?  Also, what's so bad, from a users's
perspective, about being a "vectorized Fortran"?  Fortran stands for
"formula translation", which is a fine design goal in my book.  I
think the true measure of the quality of a language is how intuitive,
easy to learn, and expressive it is.  Another great language is Perl
(Pathologically Eclectic Report Language).  Matlab and Perl are the
only languages I know in which sizable programs have a good chance of
working on the first try.  That's what makes a great language, in my
opinion: minimized software development time, and maximum readability.
 Based on my initial look, Matlab/Octave wins.

Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:
How to fund new projects:
Subscription information:

reply via email to

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