Matlab Port

[mrtreibe]

Hello everyone.

I'm going to be taking a crack at a matlab port of QuantLib and I wanted
to see if anyone had any thoughts.

The largest item nagging at the back of my mind is the exact method of
binding in the Quantlib library.  SWIG doesn't (yet) support Matlab so
this will have to be handwritten.  Unfortunately the best way that I
know of doing this is with a large switch statement inside a cmex file
(c implemented matlab file).  For those that don't know matlab, I'll
explain:

Matlab requires that each function be implemented in a separate file
(with classes implemented in a special directory structure).  If each
Quantlib function were implemented as a separate cmex file (which are
compiled as .dlls), they would also require an accompanying m-function
file to provide the function prototype and help information.  

Because of this nature the only way that I know of to manageably work
with lots of external functions within matlab is to group them together
inside one large cmex file.  I was thinking of writing one cmex function
for each major Quantlib class.  This way it keeps the cmex side of the
operation down to about 15 or so files to manage instead of hundreds.
If anyone can suggest a better way I'd be grateful; one large switch
statement just makes me feel dirty.


Apart from that I'm going to look at how the Ruby and Python ports are
implemented.  Although matlab does support a class structure it is quite
common (and useful) for function calls to also allow many parameters.
Perhaps an implementation that allows pre-defined class variables to be
temporarily overwritten during a function evaluation would keep both the
nature of QuantLib and Matlab intact.

Mark.

[Dirk Eddelbuettel]

> Hello everyone.
>
> I'm going to be taking a crack at a matlab port of QuantLib and I wanted
> to see if anyone had any thoughts.
>
> The largest item nagging at the back of my mind is the exact method of
> binding in the Quantlib library.  SWIG doesn't (yet) support Matlab so
> this will have to be handwritten.  Unfortunately the best way that I

But there is matwrap -- I have used it with both Matlab and Octave. See
http://lnc.usc.edu/~holt/matwrap/ and if you're using Debian then simply
install the matwrap package.

> know of doing this is with a large switch statement inside a cmex file
> (c implemented matlab file).  For those that don't know matlab, I'll
> explain:
>
> Matlab requires that each function be implemented in a separate file
> (with classes implemented in a special directory structure).  If each
> Quantlib function were implemented as a separate cmex file (which are
> compiled as .dlls), they would also require an accompanying m-function
> file to provide the function prototype and help information.  
>
> Because of this nature the only way that I know of to manageably work
> with lots of external functions within matlab is to group them together
> inside one large cmex file.  I was thinking of writing one cmex function
> for each major Quantlib class.  This way it keeps the cmex side of the
> operation down to about 15 or so files to manage instead of hundreds.
> If anyone can suggest a better way I'd be grateful; one large switch
> statement just makes me feel dirty.
>
> Apart from that I'm going to look at how the Ruby and Python ports are
> implemented.  Although matlab does support a class structure it is quite
> common (and useful) for function calls to also allow many parameters.
> Perhaps an implementation that allows pre-defined class variables to be
> temporarily overwritten during a function evaluation would keep both the
> nature of QuantLib and Matlab intact.

You could also look at my nascent RQuantLib project of attaching QuantLib
to GNU R. R, as an implementation of the ACW-award winning S language, has
a rich class structure, but it would require some work to map from C++ into
S.

What I've done so far is to simply provide some wrappers for some (equity)
option functions.

Dirk

--
According to the latest figures, 43% of all signatures are totally worthless.  

[mrtreibe]

> But there is matwrap -- I have used it with both Matlab and Octave.
See
> http://lnc.usc.edu/~holt/matwrap/ and if you're using Debian then
simply
> install the matwrap package.

        I saw that before but I disregarded it since it hadn't been
updated for 2 years and was for Matlab 5.  It doesn't appear to let you
make your own prototypes.  I'll take a second look at it.

Mark.