From help-octave-request at bevo dot che dot wisc dot edu Sat Dec 9 18:35:39 2000 Subject: Re: The future of Octave From: Paul Kienzle To: "John W. Eaton" Cc: help-octave at bevo dot che dot wisc dot edu Date: Sat, 9 Dec 2000 22:17:22 +0000 On Sat, Dec 09, 2000 at 01:13:53PM -0600, John W. Eaton wrote: > On 9-Dec-2000, Manuel A. Camacho Q. 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 languages. 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: http://www.octave.org > How to fund new projects: http://www.octave.org/funding.html > Subscription information: http://www.octave.org/archive.html > ------------------------------------------------------------- Paul Kienzle pkienzle at kienzle dot powernet dot co dot uk ------------------------------------------------------------- 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 -------------------------------------------------------------