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

[hidden email]>

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.orgHow to fund new projects:

http://www.octave.org/funding.htmlSubscription information:

http://www.octave.org/archive.html-------------------------------------------------------------