Re: embedded octave: how to define new functions?

[Andrea Latina]

> > As I didn't want to write any command line interface or a main's-argv
> > parsing routine (the octave's ones are ok and I actually need only to
> > extend the octave's instruction set with my own functions and data
> > structures, not more)
>
> If you only want to extend octave, then you don't need to embed it.
> You've already got your functions callable from octave so it will
> be easy to turn them into oct-files.  Initialization and finalization
> can be handled in a number of ways.

I've considered this possibility but, as our simulation code is
already productive and working fine with its -rather complicate- data
structures, I thought that the embedding is the best solution. (But
maybe I'm wrong.)

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.

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.

Therefore, I've thought that the role for octave could be:

1) acting as a programmable interface to the simulator (we use scripts
to control the simulations)

2) offer its excellent tools for on-line data analysis and
manipulation (extending infinitely the possibilities offered by Tcl,
for instance!)

I think I'm not, but I might be taking a wrong way to do this. What do
you think?

Thanks.

Cheers,
Andrea


> - Paul