The future of Octave

classic Classic list List threaded Threaded
75 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: The future of Octave

Etienne Grossmann-3

  Hello,

  Sorry for the spelling mestayke :-(

>From [hidden email] Fri Dec  8 21:16:14 2000

# "which"

  (I had written "wich", which, as the teacher told me many, many
times, is incorrect). The corrected patch is :

======================================================================
--- Octave-FAQ.texi.orig Fri Dec  8 14:34:00 2000
+++ Octave-FAQ.texi Fri Dec  8 14:54:16 2000
@@ -537,7 +537,8 @@
 
 @cindex Octave, version date
 
-The latest version of Octave is 2.0.10, released February 6, 1998.
+The latest version of Octave is 2.0.16, released January 30, 2000. The
+latest development version -which is quite stable- is 2.1.31.
 
 @node Installation, Common problems, Getting Octave, Top
 @chapter Installation Issues and Problems
======================================================================

 Etienne




-------------------------------------------------------------
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 | Threaded
Open this post in threaded view
|

Re: The future of Octave

Trond Eivind Glomsrød-2
In reply to this post by Michele-20
Michele <[hidden email]> writes:

> Trond Eivind GlomsrØd wrote:
> >
> > Michele <[hidden email]> writes:
> >
> > > I prefer the Unix, Linux philosophy to have small programs that do
> > > different things.
> >
> > A component approach using e.g. bonobo would probably be the best
> > thing...
>
> Sorry but I don't understand the last part of your letter.

http://www.helixcode.com/tech/bonobo.php3

"Bonobo is the GNOME architecture for creating reusable software
components" and is based on CORBA.

--
Trond Eivind Glomsrød
Red Hat, Inc.



-------------------------------------------------------------
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 | Threaded
Open this post in threaded view
|

Re: The future of Octave

Kevin Straight
In reply to this post by David Doolin
On Fri, 8 Dec 2000, David Doolin wrote:

>
> Obviously, I intend on developing my "customer" base as much as possible,
> and using win32 gui makes an emininent amount of sense [1].  It is
> resources in terms of development time that has been very well spent. Why
> would having a "fancy gui" for octave be a bad thing?  Would make the
> barrier to entry too low?
>
> Dave D
>
Two points (keeping in mind that I am obviously prejudiced because I'm
working on a GUI right now)

1) Of course a GUI would take a lot of our "limited resources".  Our
resources are limited because for 9 years one person has been having to
run the whole show.  We need a "Core Team" and a "GUI Team" who do there
own think (but talk to each other enough to avoid problems)

2) A _PROPERLY DESIGNED_ GUI is abstracted from the numerics.  This is
something that the Windows bunch never has understood.  The GUI dosn't
have to slow Octave down because it dosn't even have to run on the same
machine as Octave.  What's more, if we do it right we could write LOTS of
different GUIs that plug into the same back-end (ie the octave we already
know and love)

3) I'm not trying to start the old OS war, but it is stupid to write a GUI
that only runs on Win32, when most of us are using Linux or Unix.  Why not
use some widget set, gtk or athena perhaps, that is available and several
of the platforms that Octave runs on?



==========================
Kevin Straight
University of Idaho
www.uidaho.edu/Šþstra9456
==========================



-------------------------------------------------------------
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 | Threaded
Open this post in threaded view
|

Re: The future of Octave

Michele-20
In reply to this post by Alfredo Tomasini
Alfredo Tomasini wrote:

>
> I am using Octave since 96 and I used matlab before, I do not see the
> compatibility
> problem with matlab as a real issue.
>
> I basic scripting is the almost similar and people that know matlab should easily
> migrate
> to octave, if they like it.
>
> My feeling is, if you like octave make a effort to learn it as it is, otherwise
> buy matlab.

Yes, I exactly agree with this.

>
> GUI interface.
>
> Spending resource on GUI is not something that a consider high priority. For
> instance
> a tools for symbolic analysis sound to me more interesting.
>
> "interesting book"
> In the Beginning was the Command Line
>
> by Neal Stephenson
>
> http://econ161.berkeley.edu/oped/virtual/stephenson_beginning.html
>
> alfredo
>
> -------------------------------------------------------------
> 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
> -------------------------------------------------------------



-------------------------------------------------------------
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 | Threaded
Open this post in threaded view
|

Octave & Matlab

Julian A. de Marchi, Ph.D.
In reply to this post by Rafael Laboissiere-5
I'd like to expound tersely upon my earlier email.

I think it's fine that Octave continue developing without using Matlab as a
frame of reference.  Its strength as an independent, community-owned (and it
seems, often much improved) numerical processing tool shouldn't be fettered
by concerns of compatibility with a flashier, but not necessarily superior,
de-facto commercial tool as Matlab basically is.

I also think it must be possible to produce compatibility with Matlab at an
interface level without too much compromise in terms of either performance or
fundamental principles (be they scientific or philosophical).  This seems
especially true since Octave is as yet still a hard-core numerical engine,
without a graphical user interface.  I hope that Octave contributors maintain
their awareness of Matlab interface compatibility when possible and in those
instances when it does not compromise performance or usability.  However, I
also agree that it needn't be the driving factor in new design and extension
of Octave features.

Rather than forking Octave, for better or worse, to satisfy both parties in
the debate, I hope that some enterprising contributors (those who are
interested, myself included), can toil together to maintain and improve
Octave compatibility with Matlab in the form of an abstraction layer or babel
fish.  Rather than argue about the two options, perhaps we can, as a
community, agree upon an API or interpreter interface which  facilitates this
option while freeing Octave from the fetters of selective low-level
compatibility.  I'm not even sure that such an interface need specify
anything further than full functional compatibility, as most of the
differences between the two languages are merely syntactic at worst.

And this of course makes further argument on the topic rather moot.  Why not
simply drop the case and work on a Matlab-compatible layer, that uses Octave
as the driving engine?  This would, I believe, encourage more intelligent
folks to get into Octave and help the project grow, and obviate the need for
further argumentation on the merits or pitfalls of one course exclusively
over the other.

Cheers,
Julian




-------------------------------------------------------------
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 | Threaded
Open this post in threaded view
|

Re: The future of Octave

Andy Adler-2
In reply to this post by Andy Adler-2
Some opinions on MATLAB compatibility.

1. Lots of people ask about Matlab compatility on this list.
   While some of the questions are about syntactical
   differences, these are the minority.

   Most questions are about functionality. People want
   sparse, fmins, spline, handle graphics, etc.
   I feel that these are legitimate issues: it
   would be great for octave to have this functionality.

2. If the functionality were available, then building
   a translator would be easy. Any DPH (desperate
   Perl Hacker) could whip one up in days.

3. In fact, one possible approach would be to hook
   liboctave onto Perl or Python. This would have
   several advantages.

   a. The syntax is more powerful and flexible.
      especially with OO. I have often found
   myself writing convoluted algorithms to
   compensate for lacking language constructs
   in Matlab syntax.

   b. Interfaces to Graphical toolkits, such as
      Tk, Win32, GTK, Qt are already implemented.

   c. Automagical Matlab syntax conversion (including
      warnings for missing features) could be
   built in. Even an interactive mode wouldn't
   be hard too hard to build.

   (NOTE: I realize that there do exist Math subprojects
    for both Perl and Python. From my limited viewpoint,
 I don't think these are have anything like the
 power of octave)

This also has disadvantages. Neither Perl nor Python
syntax is ideal for Math. And joining a large community
that does not care about math would dilute the "focus"
that the octave community has.

For example, the otherwise excellent "Perl Cookbook"
says (p 44):
   These ... do not catch the IEEE notions of Inf and Nan, but
   unless you're worries that IEEE ... will beat you over the
   head with the standards documents, you can probably forget
   about these strange numbers.

Since we're putting all the options on the table,
we may as well consider these ideas, too.

andy
_______________________________________________
Andy Adler                        [hidden email]






-------------------------------------------------------------
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 | Threaded
Open this post in threaded view
|

F**king matlab!

Douglas Eck-2
In reply to this post by David Doolin
Does the code have to fork to have matlab compatibility
and next-generation growth? I don't think so.

I agree with John that true compatibility is a myth... we'll always
be chasing. But at the same time it is at least theoretically
possible to have a  matlab compatibity *layer* at some level in the code.

I recommend that at the lowest level, the next
generation GPL numerical analysis software pacakge
make no attempt to be a matlab clone. *But* I recommend
that it be desiged so that at a fairly low level,
it can interpret code from other languages. Primarily
matlab. This should free up those who want to build
something cool while leaving the door open for matlab-like
behavior.

Problem is, I only passed graduate progamming languages at
Indiana University because fellow-student Paul Kienzle
basically gave me his homework. Ok not quite, but close.
So this might be completely wrong.

What do you think?

Doug



-------------------------------------------------------------
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 | Threaded
Open this post in threaded view
|

Re: The future of Octave

robert.butora
In reply to this post by Trond Eivind Glomsrød-2
The discussion is mainly around 2 features,

1, Matlab compatibility
2, GUI

with the limited resources.

Just a comment on the issue of sw-quality:

There is a lot of sw already on the net (and unfortunatelly
also in the shops for your money) which promises the Paradise itself
and then you have to reboot your machine x-times until you get your
job done.

To write GUI is very difficult (try to write down only a
clear set of requirements ...) + it brings with it
all those external graphical libraries which you did not
design, i.e. you have no control on their quality
(their bugs, and constantly changing version numbers).
All of this into doing numerical mathematics.
I'm afraid there is a lot of positive enthusiasm on the begining
and some (or a lot of) effort spent and then ... see my previous
paragraph.  

I'd like to see Octave continued as a software
which does primarly mathematics. I need NUMBERS
and I'd like to be sure that they are _correct_.

I prefer a software which does less but that without bugs.
Making GUI is much effort and also I'm afraid, compatibility
would mess up internals of Octave. So you end up doing
constantly trade offs when trying to implement a new
feature; an effort which could be spent rather on
testing a new num. library or improving its efficiency etc...  

Please, be modest and rather conservative and keep Octave
doing first of all mathematics correctly and efficiently.
Thanks

Robert Butora
Helsinki University of Technology
Laboratory of Space Technology
e-mail: [hidden email]







-------------------------------------------------------------
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 | Threaded
Open this post in threaded view
|

Re: The future of Octave

Manuel A. Camacho Q.
In reply to this post by Andrew Bainbridge-Smith
Hi!

I am not a programmer, nor scientist. I am an Electromechanical Engineer
who is trying to use Octave as an everyday tool.

Thinking why do ppl want MathLab compatibility, well, I guess it is due
to the quantity and quality of the documentation available for MathLab,
and the few (if almost none) available for Octave.


> has everything in it I want --- just need to convert my *.m code base.

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.

I am finishing my grad work, and although I have been in the list for a
while, I am able to help some other guys to make a compliment "How to"
guide for Octave.

John, thanks a lot for all you have done.

-Manuel.



-------------------------------------------------------------
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 | Threaded
Open this post in threaded view
|

Re: The future of Octave

Manuel A. Camacho Q.
In reply to this post by Kai Mueller-2

> I don't agree that Octave is yesterday's technology just because
> of its user interface or its structure. A state of the art software
> solves problems numerically exact and with *** great efficiency ***.
> That's exactly what Octave does.
>
> Again, to me great efficiency is important not an intuitive user
> interface. I guess you can't have both.

I don't agree either. The text mode interface allow work to be still
done on very cheap dedicated machines at high speed. Try, for instance,
running a large script file within a shell console under X and just in
text mode. You will certainly notice the difference.

-Manuel.



-------------------------------------------------------------
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 | Threaded
Open this post in threaded view
|

Re: The future of Octave

Manuel A. Camacho Q.
In reply to this post by John W. Eaton-6

> Just because something is the latest fad doesn't mean it is worth
> following, particularly if you have very limited resources.

You are right. One of the things that amazes me is that I can do math
computing on my just-out-of-the-closet 486 with 24 MB, a $2 linux distro
and Octave, and getting results on my just-out-of-the-trash 9 pin Cannon
dot matrix printer.

If I need windows, I can run Octave under Emacs, and not using the
resource-killer graphic environments.

-Manuel.



-------------------------------------------------------------
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 | Threaded
Open this post in threaded view
|

Re: The future of Octave

Paul Kienzle-5
In reply to this post by Stef Pillaert-3
I've been hesitant to pursue this option for three reasons.  

    1) The need to learn a second language for programming callbacks
    2) The overhead of installing and running a second large interpreter
    3) The ungainliness of tcl/tk

It occurs to me, though, that we can apply the same approach that I would
recommend for an embedded GUI, which is a widget register defining the
range of widgets available, and their properties and callbacks (including
some packing widgets).  The widget definition can include all the bits
of the foreign interpreter that are needed, leaving your Octave scripts
with pure Octave code.

The overhead of the second interpreter is offset by the benefit of having
the GUI in a separate process.  Even if we did our own specialized
GUI in a separate process, we would still have to incur that overhead
(though presumably the specialized interpreter would be very simple).

Every TclTK application of any size that I've seen has been slow and ugly.
Maybe pythonGTK or perlGTK would work, but I've never used either.
I don't know if this allows us to use non-standard GTK widgets, such as
gtkplot or gtkglarea.  Any idea?

Paul Kienzle
[hidden email]

On Fri, Dec 08, 2000 at 09:18:45AM +0100, Stef Pillaert (KAHO) wrote:

> > 0. First, how important is keeping octave development alive anyway?
> >    Do enough people care?
> >
> Well, I certainly care. I use octave every day, and couldn't imagine how to
> do my research without it anymore! A great thanks to John! I hope the
> development goes on! I do have plans to use octave even more for some demo's
> for our students, since I'm getting very at ease in coupling octave with
> some Tcl/Tk GUI.
> BTW, what is this "Matlab" everyone keeps talking about? ;-)
>
> Stef.
>
>
>
>
>
> -------------------------------------------------------------
> 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
> -------------------------------------------------------------
>
>



-------------------------------------------------------------
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 | Threaded
Open this post in threaded view
|

Re: The future of Octave

Paul Kienzle-5
In reply to this post by Kevin Straight
On Fri, Dec 08, 2000 at 02:49:48PM -0800, Kevin Straight wrote:
<snip>
> 1) Of course a GUI would take a lot of our "limited resources".  Our
> resources are limited because for 9 years one person has been having to
> run the whole show.  We need a "Core Team" and a "GUI Team" who do there
> own think (but talk to each other enough to avoid problems)

Another point about the myth of "limited resources": we are not
interchangeable.  Those who have time do not necessarily have the
specialized knowledge that it takes to write missing routines such as
conjugate gradient minimization.  I spent a good hunk of time in
the library learning enough signal processing to attempt the signal
processing toolbox.  Sure I learned a lot in the process, but I'm not
about to become enough of an expert in spline fitting to write a spline
toolbox because it won't help me when I'm studying speech.  More
particularly, I don't need sophisticated spline functions.

Given an existing GUI framework, though, and a need for some specific
GUI feature, general programming knowledge ought to be enough for
you to contribute something useful, especially if the appropriate
widget already exists in the toolkit/application that we use.  Or am I
underestimating the amount of specialized programming knowledge one
gets with a couple of degrees in computer science ;)

>
<snip>

Paul Kienzle
[hidden email]



-------------------------------------------------------------
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 | Threaded
Open this post in threaded view
|

Re: The future of Octave

John W. Eaton-6
In reply to this post by Manuel A. Camacho Q.
On  9-Dec-2000, Manuel A. Camacho Q. <[hidden email]> wrote:

| > Just because something is the latest fad doesn't mean it is worth
| > following, particularly if you have very limited resources.
|
| You are right. One of the things that amazes me is that I can do math
| computing on my just-out-of-the-closet 486 with 24 MB, a $2 linux distro
| and Octave, and getting results on my just-out-of-the-trash 9 pin Cannon
| dot matrix printer.
|
| If I need windows, I can run Octave under Emacs, and not using the
| resource-killer graphic environments.

When I wrote about limited resources, I was thinking about developer
resources, not computing resources.

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


Reply | Threaded
Open this post in threaded view
|

Re: The future of Octave

John W. Eaton-6
In reply to this post by Manuel A. Camacho Q.
On  9-Dec-2000, Manuel A. Camacho Q. <[hidden email]> 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.

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.

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.

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.

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


Reply | Threaded
Open this post in threaded view
|

Re: The future of Octave

Paul Kienzle-5
On Sat, Dec 09, 2000 at 01:13:53PM -0600, John W. Eaton wrote:

> On  9-Dec-2000, Manuel A. Camacho Q. <[hidden email]> 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
[hidden email]



-------------------------------------------------------------
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 | Threaded
Open this post in threaded view
|

Re: The future of Octave

Rafael Laboissiere-5
In reply to this post by Paul Kienzle-5
On Sat, Dec 09, 2000 at 04:54:13PM +0000, Paul Kienzle wrote:
> I've been hesitant to pursue this option for three reasons.  
>
>     1) The need to learn a second language for programming callbacks
>     2) The overhead of installing and running a second large interpreter
>     3) The ungainliness of tcl/tk
>
> [...]

Is not this thread more appropriate for the octave-graphics list?  There has
been there a recurrent discussion about GUI implementation for Octave that
resurfaces every year or so.

--
Rafael



-------------------------------------------------------------
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 | Threaded
Open this post in threaded view
|

Re: The future of Octave

John Logsdon-4
In reply to this post by Paul Kienzle-5
jwe has carried the load for far too long and has every right to call a
break.  He clearly deserves all our thanks.

It will in the long run be better for both John and Octave if he steps
back and lets someone else - or better a group - to take the lead but why
have things got to this level?

I don't really want to use too much bandwidth but while I still use Octave
on occasion, for most of my work I now use R - the statistical program.
Mainly this is because I do statistical work although the syntax is not as
natural as Octave's.

The comparison is interesting since R is an open source implementation of
the S language.  The comparable closed-source program is S-Plus which
curiously is also (now) owned by MathSoft.  Like Matlab, it is expensive
for a single user to buy (particularly on a Linux box). Are Mathsoft
profiteering?  Is too much of the licence fee going to sales and marketing
junkets chasing a rather difficult set of prospective purchasers rather
than slashing the cost?  The high (relative) cost of Matlab in a general
purpose environment means that there remains an important section of the
world community that needs a program like Octave (or Scilab or tlab or
...).

Since R is a program or environment for statistical calculations rather
than an operating system, this is a better comparison I think than the one
already mentioned of Linux.  

The R core team has managed to avoid overloading one member (actually it
started with two people anyway) and is spread world wide.  The program
continues apace and in a number of respects is faster and better than it's
commercial counterpart while missing some of the addons.  Most of the
libraries written (openly) for S-Plus have now been ported to R.

Why has the R approach worked and Octave one not?  Is it because there is
a clear target language, in which most libraries etc are written, rather
than a moving target where the target calls the shots?  Is it because
there is a better defined user-group (ie statisticians rather than anyone
who uses matrices from time to time)?  Is it because it is a higher level
language?

There are many other questions but the big problem is - what can be done
to bring Octave development closer to the R model?  Is it worth trying?
How do these groups develop?  This is really a problem I think for a
sociologist to answer but perhaps there are some thoughts on the list.

John




-------------------------------------------------------------
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 | Threaded
Open this post in threaded view
|

RE: The future of Octave

Ted.Harding
In reply to this post by John W. Eaton-6
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.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------


Reply | Threaded
Open this post in threaded view
|

GUI (Was: The future of Octave)

Kevin Straight
In reply to this post by Paul Kienzle-5
First of all, I want some clarification.  ARe we talking about a GUI on
Octave itself, or a GUI API that we can call from Octave?  I think both
would be nice to have, but the certainly aren't the same thing.

For the former, well, the people who want it should write it, but do it in
such a way that OCtave still runs fine without it.  (And I'm already
working on one solution to that, but I think others should tackle it in
their own way)

For the later, all we have to do as a group is to agree on a basic
framework, then someone needs to write bindings for some basic
widgets.  From then on, if anyone needs something complicated, they can do
it themselves.  At the minimum, we need to decide what toolkit we are
going to use.  We also need to decide some things like how we are going to
deal with signals and mainloop handling.

Heck, even someone like *me* could rough out a basic API if we could agree
on that much (not that I'm neccessarily volanterering <smile>), and I am
an indifferent programmer at best.  :-)

On Sat, 9 Dec 2000, Paul Kienzle wrote:

> On Fri, Dec 08, 2000 at 02:49:48PM -0800, Kevin Straight wrote:
>
> Another point about the myth of "limited resources": we are not
> interchangeable.  Those who have time do not necessarily have the
> specialized knowledge that it takes to write missing routines such as
> conjugate gradient minimization.  I spent a good hunk of time in
> the library learning enough signal processing to attempt the signal
> processing toolbox.  Sure I learned a lot in the process, but I'm not
> about to become enough of an expert in spline fitting to write a spline
> toolbox because it won't help me when I'm studying speech.  More
> particularly, I don't need sophisticated spline functions.
>
> Given an existing GUI framework, though, and a need for some specific
> GUI feature, general programming knowledge ought to be enough for
> you to contribute something useful, especially if the appropriate
> widget already exists in the toolkit/application that we use.  Or am I
> underestimating the amount of specialized programming knowledge one
> gets with a couple of degrees in computer science ;)
>
> >
> <snip>
>
> Paul Kienzle
> [hidden email]
>

==========================
Kevin Straight
University of Idaho
www.uidaho.edu/Šþstra9456
==========================



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


1234