Hi Pavel,
about 2 years ago I started a matlab extension and even posted a
message to the quantlib users group but now searching the archive I
can't find the email (maybe that's why I never heard responses from
anyone). You can download the file from
"
http://www.eng.uwaterloo.ca/~mrtreibe/Quantlib-Matlab-0.0.1.zip".
Even though the file says its GPL I'm now a BSD believer so consider
it BSD licensed. After I made that version I re-wrote it based on
what I learnt developing that version before later abanding it. That
version was much nicer than the one I attached (which is basically a
proof of concept based on ql 3.2 I beleive) Unfortunately I had a
hard drive failing 8 months ago and I lost that newer version.
In general I came to the conclusion that a quantlib/matlab extension
isn't really feasible because you have to make huge concessions
because of matlab's interface. Most of the comments I'm going to make
are based upon 6.1 (and probably 6.5) but I havn't checked whether
they've been corrected for 7.0.
1) You have to use a single mex function with a parameter that
specifies which quantlib function your actually calling because matlab
only supports one mex function per shared library. This is a pretty
common workaround that I've seen others use for matlab.
2) There exists a cmex glue library for octave that allowed me to
provide octave support. However I found that there was a memory leak
somewhere in either the glue library or octave's interface that make
it unstable. The matlab interface was pretty stable. Also there were
several other incapatibilities between matlab and octave which
unfortunately I forget. That being said the native octave c interface
is a lot nicer than the matlab one but unfortunately I couldn't use
it.
3) The biggest limitation with the matlab interface is that while the
matlab m-language does provide object oriented capabilities, the mex
interface does not. The mex interface is purely procedureal. In fact
you cannot even create a new object through the mex interface, you
would have to describe the interface using m-files (basically how you
would normally do it through the m-language). And then you would can
that object through the mex interface.
4) If you absolutely must write a matlab interface, I would suggest
writing developing swig support for matlab first and then using that
to develop the matlab interface. That would conceivably automate a
lot of the mundane workarounds that have to be done everywhere.
I hope this helps...
Mark.
On 6/28/05, Pavel Tugarin <
[hidden email]> wrote:
> To whom it may concern:
>
> I am writing regarding the proposed MATLAB extension. I am interested
> in this project, and potentially could work on it ( Please see my
> resume attached. What is not in the resume, however, is that I am
> starting my job as a software engineer at Teradyne in North Reading,
> MA on July 25).
>
> For now, I am doing research for Writing for Professions regarding
> financial modeling in MATLAB. I would like to talk to someone at
> Quantlib team and have some questions answered:
>
> 1) How long could MATLAB Extension project take (specific deadline
> yet?) to complete and how much workforce could it require?
>
> 2) What is the performce of MATLAB/Quantlib system compared to
> Quantlib-based framework built in C++.
>
> I would appreciate if someone could answer these. Also, I may be
> interested in contributing to this project in the near future.
>
> Thanks,
> Pavel
>
>
>
Locked
PavelResume.doc (64K)