Re: The future of Octave

[Paul Kienzle]

On Thu, Dec 07, 2000 at 10:09:51PM -0800, Kevin Straight wrote:
> Long-winded ramble follows:
> 
> jwe's point is well taken.  Octave is a very solid and useful application,
> but it is impossible to escape the fact that it is based on yesterday's
> technology, not today's.  It does what it does very well, but it is
> inherently limited by design considerations.  Working on my degree in
> applied math over the last three years I have become increasingly
> convinced that we are long overdue for the next evolution in
> mathematical software.  I think we-the open source community-should be the
> ones to come up with it, and let the commercial teams scramble for
> bug-for-bug compatibility with US.  
> 
> What form will this revolutionary new application take?  I don't know, but
> here are some ideas I've come up with:
> 
> 1) Flexibility.  If you're like me, you own at least one each of the
> following:  numeric software (ie octave), statistical software (minitab or
> whatever), CAS/symbolic software (maple, derive, etc), technical document
> prep software (ie latex), and spreadsheet.  If you're in engineering you
> also probably have CAD and flowcharting software.  All of these duplicate
> features found in some or all of the others.  NONE of them interoperate
> worth beans.  They all use different interfaces and commands to accomplish
> the same thing.  

The existing Octave framework can handle these, and to some extent,
aleady does.  But these projects NEED YOUR HELP.  Most of base matlab and
some of the toolboxes are there.  That includes a goodly portion of the
statistics toolbox (distributions, tests, and descriptive stats, but not
parameter estimation, experimental design, process control or principle
components analysis).  Ben Sapp has started an interface to GiNaC,
which is a symbolic algebra package.  Ask him what needs to be done.

The gtk-extra package has a spreadsheet interface which could be handled
if someone could find the time to interface to the GTK widget set in an
extensible way.  That is, you must be able to register new widgets from
an .oct file, or if the GTK interface is a separate process, by its own
shared object loading mechanism.  Once this framework is in place, then
individuals can start to contribute widgets and buttons independently and
real distributed development can occur.

This doesn't get you a Mathematica-style notebook (which is presumably 
the sort of technical documentation interface you want?), nor does it
get you simulink, but in the case of simulink, there are people who are
working on that as well.

> 
> I submit that the world is ready for a well integrated SUITE of
> open-source technical applications--designed to work together and have the
> same (highly customizable) look-and-feel.  I DO NOT think we should simply
> take existing applications and glue them together--but instead design the
> whole thing from the top down.

There is a lot to be said for using others people work rather than reproducing
it for yourself.

> 
> 2) Innovative Interfaces:  Octave's command-line interface is fast (for
> all of us who have been using it for years) and takes few
> resources.  Those are the only good things that can be said about it.  The
> new application should have both modern graphical worksheet interfaces and
> the old standby command line.  The worksheet should be fast and bug-free
> (which is more than can be said of Maple, for instance).  It should also
> be intuitive.  Lets face it...we're the old guard.  Most of my students
> have never seen a command line, and they're the ones who will be using
> this thing 9 years from now, so we should make it "pretty".

So do your students a favour and introduce them to the command line :)  They
will need to know it anyway if they are going to be doing any scripting.
But I agree that for certain applications, having a spreadsheet interface
to the matrices would be useful.  And for some things, it is nice to have
buttons and menus, though only if those same facilities are available to
your scripts, and only if those facilities can be accessed without having
to mess with the mouse.  GUIs are okay for learning a new application, but
horrible if you have to use it regularly.

> 
> 3) Distributed Computing:  Now that MPI, clustering, and other kinds of
> distributed computing are finally coming of age, it would be stupid to
> design mathematical software without planning to take advantage of them
> from the very beginning, while still being usable on the old
> "one-station, one processor, one user" model.

A partial solution is to use existing parallel blas and solvers.
Some people are already doing this with Octave.  The complete solution
would implement parallelizable scripts.  This will certainly require a
different scripting language and should not be done without a thorough
analysis of the existing parallel languages.  Better yet, let the language
and compiler experts design your language, the application experts design
your solvers, and bring the lot together for an ideal numeric environment.

> 
> 4) Native high quality graphics:  I think the next project should draw its
> own graphics, and draw them well, instead of using an external program
> like gnu-plot.  

The advantage of an external program is that someone else is doing all
the work of maintaining it.  Admittedly, though, it would be nice if
your scripts knew a little more about the graphics were being rendered.
Improving existing third party applications so that they can give Octave
the feedback they need is also a reasonable approach.  The big problem
that I see is that people want to construct pretty interfaces to their
data, and none of the scientific graphing applications that I know of
provides any GUI facilities.

> 
> 5) Portability:  This goes without saying, but obviously we want it to run
> on everything octave runs on, plus emerging systems.
> 
> Well, there you go.  Maybe all of that is impossibly big.  Surely no one
> person could even design it, much less do the programming.  Maybe I'm the
> only one who wants it.  If it was to happen, though, I can't think of
> anyone more able to do it than the readers of this list, especially
> jwe.  There, would that be enough of a challenge for you?
> 

Paul Kienzle
address@hidden



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

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------