help-octave
[Top][All Lists]
Advanced

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

RE: The future of Octave


From: Ted Harding
Subject: RE: The future of Octave
Date: Sun, 10 Dec 2000 13:48:54 -0000 (GMT)

Dear John,

On 07-Dec-00 John W. Eaton wrote:
> I've now worked on Octave for almost nine years.  During most of that
> time, I have enjoyed the challenge of working on a relatively large
> project.

And during most of that time I have enjoyed using octave for almost
all of my numerical work. I came to octave when I began using Linux
in 1992 and was looking for something that could do what I had been
doing with MatLab on DOS in 1989-1992.

I have nothing bur praise and admiration for your work in maintaining
and developing octave throughout this time. In the beginning it was an
excellent and solid package and it has since grown better and remained
always solid. My congratulations, and sincere and deepest thanks.

May your next venture prosper equally well -- and I am sure I shall
find valuable use for it when it comes into being!

------------------------------------------------------------

Now, addressed to all, some comments.

1. Like John Logsdon, I am primarily a statistician (with interests
in other areas of numerical mathematics). For the most part, the
basic resources of octave supply all the building-blocks needed
for the great majority of cases. Only occasionally have I found
octave's limitations seriously hampering, the main areas being

a) arrays with more than 2 dimensions with corresponding numerical
   and selection operators;

b) a graphics package with two-way communication (e.g. the ability
   to draw a frame round a cluster of points and feed the selection
   back to octave);

c) having certain computations (e.g. contouring) part of octave itself
   rather than relegated (as in the dependence on gnuplot) to the
   graphical "module".

Admittedly, all such things can be worked round in octave though
usually inefficiently and at the cost of slow operation. So I have
not felt under great pressure to urge their development in the past.
Nevertheless, they stand out as developments which could very nicely
round off the final version of octave.

(I have to admit that, when I have looked into the octave code with
such questions in mind, I have been reminded of the advice "Do not
meddle with the affairs of wizards ... ").


2. As to MatLab compatibility, in my own view (and as is clearly
the view of some others) this is nice to have but not essential
in the present state of things. The present near-compatibility has
served me well when I have had PhD students doing their work on
"Student MatLab" with me working in parallel in octave. Only minor
inter-conversions of scripts were required, provided they made sure
to save their results in "MatLab-4" format.

I have to agree that pursuing MatLab compatibility is an unworthy
ambition, for exactly the same reasons that pursuing MS Word
compatibility in document exchange is unworthy, though this point
of view is perhaps a personal philosophy, which I hope you will
excuse me for writing a few words about.

Calling MS Word something like "the de-facto industry standard"
for documents is misleading. In reality, it is simply what most
people use because they don't know better, and do not understand
a proper concept of "interchange". In principle, this remains
fully true even if "most people" means "95 per cent of users".

"Interchangeable" really means "able to be used on all platforms
without requiring purchase of proprietary products before it can be
used". Where MS Word is concerned, this rules out users of UNIX
platforms in the first instance, for example.

True interchangeability lies in adopting common open standards
for the format of the objects to be interchanged, and for the
medium in which they will be conveyed. For documents, the universal
exchange medium is the ASCII text file (applicable even for PDF).
Open standards for formats can be expressed in terms of markup
languages (e.g. I mainly use groff, others TeX, yet others
use XML). Once you have these in place, you can use whatever
software -- proprietary or not -- to interpret and implement them,
so long as it works. There should not be proprietary rights in the
interpretation and implementation of open-standard formats.

Now, a bit like MS Word, MatLab has to some extent got a proprietary
grip on the interpretation and implementation of numerical algorithms,
partly through implementing certain supplementary functions as
pre-compiled "mex" files, partly through storage of results in
a non-disclosed "MatLab-5" format, and partly because of the
possibility (though I am not sure how strongly it can be enforced,
if it can be shown that it was already public knowledge or was
truly independently developed) that even an algorithm can be patented.

It is probably true that octave syntax -- however closely it
resembles MatLab syntax of a certain vintage -- is by now an
"open standard". It is also probably true that chasing developments
in MatLab syntax may encounter legal problems if the MathWorks
claim that their syntax (at any rate in its more recent aspects)
is proprietary. 

Now some may claim that MatLab is, in its own domain, a "de-facto
industry standard". For the reasons above, I do not believe that
this is so. My wish would be for an interchangeable standard for
the expression of numerical operations and algorithms, their
interpretation and implementation being a matter for any software
that can do the job. Octave -- like MatLab -- does an excellent
job in its own terms. The question (which has been raised by other
discussants) is what should this standard be for numerical mathematics
in general. One could regard octave syntax as defining an open standard
for such parts of numerical mathematics as it already applies to;
but what about the rest? Should octave, or its next generation of
descendants, simply be extended as required? Or should we be looking
at a restructuring of the language, just as XML grew out of such primal
markup languages as troff and SGML? Maybe part of the answer to this
may be found when John Eaton's new paths begin to open up.

Enough of this philosophy. Next point:


3. I agree with those who suggest that octave (or any similar package)
should not be tied down to an interface with any particular GUI.

The "dual" of interchangeability is interoperability. As in the classic
UNIX spirit, different packages can cooperate in achieving a task
provided their can communicate both results and commands to each other.
UNIX text-editing tools can be invoked to translate or embellish
the output of one program, if the program itself can not generate
the correct format in the first place. Octave already achieves this
in a limited way with its built-in gnuplot interface, and (as many
have shown) it is quite possible to make similar interfaces with
other graphical packages. On another front, I sometimes use octave's
"sprintf" to generate computed troff code, including "pic", "eqn" and
"tbl" code, and (via gnuplot) EPS files of diagrams, so that the
specifically numerical parts of a technical document are already
written by octave.

It is perfectly possible (though I think few do it) for things to work
the other way: for instance, John Logsdon could use "R" to generate
the output of statistical analyses in text files, which could then
be converted into "m" files which octave could pick up and run.

The same applies to the GUI question. With a suitable GUI package
(Tcl/Tk springs to mind) mouse-clicks could create octave m-files;
octave output could be converted to GUI commands to display results,
which can be selectively "pasted" back into the octave GUI.

However, I believe that it is important to avoid falling into the
"MS Windows trap" (what you can click on is all you can get).
Rather, I believe that -- just as octave is a general-purpose
numerical language for array computations -- so there should
be a general-purpose GUI language "conformal" with octave, so
that users can build their octave GUIs in exactly the same way
as they now build their octave numerical algorithms; of course,
a suitable rich set of primitives needs to be put in place to start
with, but in such a way that there are no arbitrary "no-go areas".

----------------------------------------

Well, those are a few thoughts from a long-time and most appreciative
user of octave, whose working life has been made richer and more
productive thereby. Thanks again, John.

And all best wishes for the future.
Ted.

--------------------------------------------------------------------
E-Mail: (Ted Harding) <address@hidden>
Fax-to-email: +44 (0)870 284 7749
Date: 10-Dec-00                                       Time: 13:48:53
------------------------------ XFMail ------------------------------



-------------------------------------------------------------
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
-------------------------------------------------------------



reply via email to

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