[Top][All Lists]

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

Re: The future of Octave

From: Paul Kienzle
Subject: Re: The future of Octave
Date: Sat, 9 Dec 2000 22:17:22 +0000
User-agent: Mutt/1.2.5i

On Sat, Dec 09, 2000 at 01:13:53PM -0600, John W. Eaton wrote:
> On  9-Dec-2000, Manuel A. Camacho Q. <address@hidden> wrote:
> | Yep. I think that's the point. Instead of making Octave "ML compatible",
> | we can better think of a file translator, made with an scripting tool to
> | convert .m files to Octave files.
> If you want to head down that path, then I think it makes more sense
> to use a translator to convert Matlab code to a more full-featured
> scripting language.  A similar translator would be written for Octave
> (or whatever the new environment that does not attempt Matlab
> compatibility is called).  Both translators would share the same
> underlying library and interpreter, so both could be used together,
> along with any code written for the underlying scripting language.

There are some subtle low level semantic issues that could prove
difficult.  For example if you were to switch to using C-style matrix
layout, then x(:) which is currently free would become rather more
expensive.  I agree that the dependence on fortran based blas and solvers
makes such a change unlikely, but similar low-level changes would have
to be addressed in the compatibility layer.  Note that this already
happens: matlab is 1-origin but liboctave is 0-origin.  This translation
is currently done in liboctave (I think), but if the new environment
chose to use 0-origin indices, then this translation would be stripped
from liboctave, and would have to be added to the compatibility layer
(where it would almost certainly be more expensive).

At a higher level, the new environment is likely to have builtin solvers
with a different interface (e.g., using fitpack rather than pppack for
spline tools), but these too can be addressed in the compatibility
layer (by interfacing to pppack if necessary).

> If you agree with this approach, at least in principle, then you will
> probably want to have your favorite scripting language at the core.
> People will probably argue that one language is more popular or has
> more add-ons than another, so it should be used.  There will be Python
> and Perl advocates, and people who just like Tcl, or Java.  But my
> choice would probably be something like Scheme, which is powerful, and
> should be relatively easy to use as a target for translation.

Please, please consider an underlying language which has an available
compiler, preferably a just-in-time compiler.  A factor of 1000 speedup
for a builtin function over the for-loop version is a lot:

        > x=rand(100000,1); 
        > tic; total=0; for i=1:length(x), total+=x(i); end; t1=toc
        t1 = 28.342
        > tic; total=sum(x); t2=toc
        t2 = 0.026243
        > t1/t2
        ans = 1080

Writing a fast compiler which produces fast and correct code is hard
work --- let's leave it to the people who specialize in compilers and

This will presumably leave us with a serial interpreter and parallel
solvers since finding a free environment with an interpreter and compiler
which is fast, flexible and parallel is a tall order.  Or is parallelism
a minor target for the new Octave?

BTW, isn't there a Scheme -> JVM compiler available?  And hasn't IBM
recently freed a JIT compiler for JVM code?  I wonder how well these
work together.

> Using such an approach, you don't have to write Scheme code if you
> don't like it, you can write Octave code and pass it through the
> translator, and people who want to use the strict Matlab translator
> can still have access to your code.  Likewise, people who use Octave
> have access to all the Matlab code, via the translator.  And both have
> access to any other modules written for the Scheme interpreter.

Presumably things like infix operators, element-wise vs.  matrix
operations, infix operators and structured data types would exist in
the new octave translator and but not in the underlying interpreter?

Note that we will need C/C++ access to this syntactic sugar as well to
create interfaces to pre-existing Fortran and C solvers.  I'm a fan of
sugar in its myriad forms, including syntactic sugar :)

> I passed this idea by the Guile maintainers and users several months
> ago, and they were enthusiastic about it.  I'm not sure it is the path
> I will eventually choose, but it is interesting to me.  In any case,
> arguments about the popularity of the underlying scripting language
> are not likely to sway me.  I am much more interested in the technical
> merits.
> If I attach Octave to Guile, I will almost certainly jettison almost
> all of the Matlab compatibility gunk so that I can simplify the
> translator.
> I have no plans to write or maintain a Matlab translator myself.  That
> task will have to be left to someone who is interested.  And, if you
> are going to tackle a project like this, I would recommend trying for
> strict bug-for-bug compatibility, so that you don't have to worry
> about your innovations clashing with future Matlab features.

That makes good sense.  Then I won't have to guess anymore if I should
use is_X or isX in my conditionals ;)

> jwe
> -------------------------------------------------------------
> Octave is freely available under the terms of the GNU GPL.
> Octave's home on the web:
> How to fund new projects:
> Subscription information:
> -------------------------------------------------------------

Paul Kienzle

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]