From help-octave-request at bevo dot che dot wisc dot edu Sun Dec 10 08:03:15 2000 Subject: RE: The future of Octave From: (Ted Harding) To: help-octave at bevo dot che dot wisc dot edu 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) 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 -------------------------------------------------------------