Re: embedded octave: how to define new functions?

[Przemek Klosowski]

   At the moment, for historical reasons, we rely on Tcl/Tk for a
   programmable user interface but, as anyone here can imagine, this
   language is clearly not optimal for any complex scientific task
   (actually, it is a pain). So here comes my idea: we replace this old,
   painful, Tcl/Tk interface with a new one based on octave.

Ah, Tcl/Tk. Can't live with it, can't live without it. It is great for
creating graphical user interfaces, but indeed sucks when you try to
use it as a command language for driving a computation; Tcl makes you
do unnatural things like:

        set end [expr 2*(atan(1) * 4)]; calculate 3  {{1 2} {3 $end}} 
vs octave:
        end=2*pi; calculate 3 [1 2; 3 end]

On the other hand, you can do GUIs like this:

       pack [entry .from -textvar from] [entry .to -textvar to] [button .b 
-command calculate]

which is much harder in Octave. That's why Paul Kienzle wrote the Octave-Tcl
interface: it's nice to do calculations in Octave and write the GUI in Tk.
Both processes have their own command loops, and communicate data over sockets.

   But, I cannot imagine to spread our code into many octave functions
   and it wouldn't make any sense to redesign it for octave (it is highly
   optimized C/C++). Rather, I think that our code could be easily
   "hidden" behind some nice octave commands, while octave would allow us
   to control it through its excellent interface, which is perfect for
   our simulation programs.

Exactly---you neither want nor need to rewrite your existing code in
the .m language; you want to wrap your calculation routines and insert
them as Octave commands into the Octave interpreter, which is
relatively easy because of the nice API octave provides.

At runtime you invoke them from Octave command line or from .m
scripts; Octave then converts your input parameters from Octave
objects to your own data structures and invokes your compiled
code. When the calculation is done, your code returns to the Octave
interpreter, which gets another .m command from the commmandline or
the script file. Note that your code can be arbitrarily complicated
and may take long time to complete---it's OK, octave can wait. 

It is tempting to split up long calculations into component
operations, so that the interpreter can regain control, to e.g. peek
at intermediate values, graph the progress, etc---but the degree to
which you split things up is entirely up to you; it's a tradeoff of
flexibility vs. simplicity.