QuantLib › quantlib-dev

Surface interface

Classic

List

Threaded

10 messages Options

Joseph Wang-2

Surface interface

Unless someone objects, I'd like to check in a set of classes that provide a
standardized interface to surfaces in quantlib. The basic interface is a
Surface class that returns a real in return to two real inputs and provides
information about the domain the Surface is valid. The idea behind this is
to provide a standard interface for external plotting packages.

The goal in three or four months time is to make this work with Python and VTK
to provide the sort of visualization which is standard in CFD, medical and
petroleum, but which I haven't seen yet in QF.

The other thing that we probably should look at before 1.0 is to look at the
classes and see if there are any that are redundant.

--
-------------------------------------------------------------------------------
Joseph Wang Ph.D. - [hidden email]
China Derivatives Researcher and Software Developer - QuantLib
http://en.wikiversity.org/wiki/User:Roadrunner

Gheorghe Postelnicu

Re: Surface interface

Hi,

I have been thinking for a while to get back to doing some finance.
Right now I'm doing medical imaging and I am posting this because I
have already done a number of applications that follow the pattern
indicated by Joseph. If I can be of any help, I'd be glad to assist.

On 11/27/06, Joseph Wang <[hidden email]> wrote:

> Unless someone objects, I'd like to check in a set of classes that provide a
> standardized interface to surfaces in quantlib. The basic interface is a
> Surface class that returns a real in return to two real inputs and provides
> information about the domain the Surface is valid. The idea behind this is
> to provide a standard interface for external plotting packages.
>
> The goal in three or four months time is to make this work with Python and VTK
> to provide the sort of visualization which is standard in CFD, medical and
> petroleum, but which I haven't seen yet in QF.
>
> The other thing that we probably should look at before 1.0 is to look at the
> classes and see if there are any that are redundant.
>
>
> --
> -------------------------------------------------------------------------------
> Joseph Wang Ph.D. - [hidden email]
> China Derivatives Researcher and Software Developer - QuantLib
> http://en.wikiversity.org/wiki/User:Roadrunner
>
>
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> QuantLib-dev mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

--
Gheorghe Postelnicu, PhD
MGH, Harvard Medical School

Joseph Wang-2

Re: Surface interface

In reply to this post by Joseph Wang-2

There is something that would be very useful would be if you could find or
point me to an example using VTK or mayavi which draws a surface and a
scatterplot using the python interface.

VTK has a really steep learning curve, and if you can post "hello world" in
VTK that would be very useful.

Thinking though the design a bit. What I was thinking of doing is to use the
TimeSeries template and create a TimeSeries of sampled curves or a TimeSeries
of functions. This could then be inserted into an interpolator which would
return a surface which could be plotted by an external function.

There also may be a need for a Curve object that does the same thing as
Surface (i.e. provide an external standard interface for 1-d objects). Curve
would require an Interval.

The way that I was thinking of moving forward was to create a TestSurface
object which just plots a 2-d sinusodial function. Get the SWIG bindings
working, and then try to use that Surface to plot a hello world surface.
Once I can see what I'm doing, then we can attach the Surface object to the
rest of QuantLib and start ploting volatility surfaces or interest rate yield
curves.

--
-------------------------------------------------------------------------------
Joseph Wang Ph.D. - [hidden email]
China Derivatives Researcher and Software Developer - QuantLib
http://en.wikiversity.org/wiki/User:Roadrunner

Gheorghe Postelnicu

Re: Surface interface

That sounds great. I have experienced a part of the VTK "steep" curve
and I already have applications using the SWIG bindings for VTK and
Python. The only tricky thing for me there is that if code other than
the VTK one is needed in C++, then indeed SWIG is needed, but I
couldn't find a way to pass objects from the VTK bindings (which are
not exactly SWIG) and my own SWIG library. My solution in the past was
to write wrappers that would perform the data transfer in Python.

Just a question: why do you think SWIG would be needed in this case?

Thanks,

On 11/27/06, Joseph Wang <[hidden email]> wrote:

> There is something that would be very useful would be if you could find or
> point me to an example using VTK or mayavi which draws a surface and a
> scatterplot using the python interface.
>
> VTK has a really steep learning curve, and if you can post "hello world" in
> VTK that would be very useful.
>
> Thinking though the design a bit. What I was thinking of doing is to use the
> TimeSeries template and create a TimeSeries of sampled curves or a TimeSeries
> of functions. This could then be inserted into an interpolator which would
> return a surface which could be plotted by an external function.
>
> There also may be a need for a Curve object that does the same thing as
> Surface (i.e. provide an external standard interface for 1-d objects). Curve
> would require an Interval.
>
> The way that I was thinking of moving forward was to create a TestSurface
> object which just plots a 2-d sinusodial function. Get the SWIG bindings
> working, and then try to use that Surface to plot a hello world surface.
> Once I can see what I'm doing, then we can attach the Surface object to the
> rest of QuantLib and start ploting volatility surfaces or interest rate yield
> curves.
>
> --
> -------------------------------------------------------------------------------
> Joseph Wang Ph.D. - [hidden email]
> China Derivatives Researcher and Software Developer - QuantLib
> http://en.wikiversity.org/wiki/User:Roadrunner
>
>
>
>
>

--
Gheorghe Postelnicu, PhD
MGH, Harvard Medical School

Joseph Wang-2

Re: Surface interface

> That sounds great. I have experienced a part of the VTK "steep" curve
> and I already have applications using the SWIG bindings for VTK and
> Python.

If you can post information about this onto the wiki page at

http://en.wikiversity.org/wiki/QuantLib/VtkIntegration

that would be useful. Also in general I'm trying to get more and more people
onto Wikiversity to use that as a research hub for these sorts of things.

> Just a question: why do you think SWIG would be needed in this case?

Because there are already working bindings for QuantLib to SWIG. Also, I
think I can test the Surface interface through the R module before the VTK
gets integrated.

-------------------------------------------------------------------------------
Joseph Wang Ph.D. - [hidden email]
China Derivatives Researcher and Software Developer - QuantLib
http://en.wikiversity.org/wiki/User:Roadrunner

Ferdinando M. Ametrano-3

Re: Surface interface

In reply to this post by Joseph Wang-2

Hi Joseph

it would be nice if you could give us a more detailed idea about how
this class would be used, especially from the financial point of view.

we're in the middle of some major refactoring of interest rate
volatility surfaces, and I would prefer to have a clear idea about
overlapping, if any.

ciao -- Nando

On 11/28/06, Joseph Wang <[hidden email]> wrote:

Joseph Wang-2

Re: Surface interface

The three abstract interfaces that I'd like to define are

class Surface : public std::binary_function<Real, Real, Real> {
public:
virtual Real operator()(Real x, Real y) const = 0;
virtual Domain* domain() const = 0;
virtual ~Surface() {};
};

class Domain : public std::binary_function<Real, Real, bool>{
public:
virtual bool includes(Real x, Real y) const = 0;
bool operator()(Real x, Real y) {return includes(x, y);}
virtual ~Domain() {};
};

class Curve : public std::unary_function<Real, Real> {
public:
virtual Real operator()(Real x) const = 0;
};

The rationale behind defining these classes is more computational than
finance. Basically if these three classes exist, then when I write a
external plotting function, I need only have the function understand
surfaces, domains, and curves, and it doesn't need to know about any of the
details behind the class.

Also you can do things like:

class RFunction : public Curve {
public:
RFunction(SEXP *);
}

class PythonFunction : public Curve {
public:
PythonFunction(Handler *);
}

One subclass in particular is

class TimeIndexedSurface : public Surface, public TimeSeries <Curve> {
public:
TimeIndexedSurface (Date referenceDate &);
void addCurve(Date, const Curve &);
}

What this would do in combination with the PDE code is that as the PDE is
calculating, it can add results to this class, and from QuantLib's point of
view it is seeing a TimeSeries of curves. An external plotting application
sees that this class is also of type Surface and can run through that
interface to plot the surface generated by a finite difference run.

The other use for this is that I have data from Shanghai warrants and I want
to see if the volatility smile evolves. So I want to slice up the data into
time bins, do a regression on each bin, and then plot the surface. For this
I need an object that could store the regressions. Most scripting languages
don't have data structures that are flexible enough (or are too flexible) to
do this.

在 Tuesday 28 November 2006 02:52，您写道：

> Hi Joseph
>
> it would be nice if you could give us a more detailed idea about how
> this class would be used, especially from the financial point of view.
>
> we're in the middle of some major refactoring of interest rate
> volatility surfaces, and I would prefer to have a clear idea about
> overlapping, if any.
>
> ciao -- Nando
>
> On 11/28/06, Joseph Wang <[hidden email]> wrote:
> > Unless someone objects, I'd like to check in a set of classes that
> > provide a standardized interface to surfaces in quantlib. The basic
> > interface is a Surface class that returns a real in return to two real
> > inputs and provides information about the domain the Surface is valid.
> > The idea behind this is to provide a standard interface for external
> > plotting packages.
> >
> > The goal in three or four months time is to make this work with Python
> > and VTK to provide the sort of visualization which is standard in CFD,
> > medical and petroleum, but which I haven't seen yet in QF.
> >
> > The other thing that we probably should look at before 1.0 is to look at
> > the classes and see if there are any that are redundant.
> >
> >
> > --
> > -------------------------------------------------------------------------
> >------ Joseph Wang Ph.D. - [hidden email]
> > China Derivatives Researcher and Software Developer - QuantLib
> > http://en.wikiversity.org/wiki/User:Roadrunner
> >
> >
> >
> >
> >
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share
> > your opinions on IT & business topics through brief surveys - and earn
> > cash
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > QuantLib-dev mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/quantlib-dev

--
-------------------------------------------------------------------------------
Joseph Wang Ph.D. - [hidden email]
China Derivatives Researcher and Software Developer - QuantLib
http://en.wikiversity.org/wiki/User:Roadrunner

Gheorghe Postelnicu

Re: Surface interface

In reply to this post by Joseph Wang-2

Hi Joseph,

I added a first example on displaying a surface using a VTK Python
script on the page in question.

I seem to have a problem with the upload of the source surface used to
generate the display output I posted. Namely, I get a warning when I
try to load the .vtk file (not an error), but then the file doesn't
seem to exist.

Anyway, no SWIG just yet - I am not really sure on second thoughts
what I can contribute about SWIG, since you guys already use it in the
library.

Let me know if this helps at all,

On 11/28/06, Joseph Wang <[hidden email]> wrote:

> > That sounds great. I have experienced a part of the VTK "steep" curve
> > and I already have applications using the SWIG bindings for VTK and
> > Python.
>
> If you can post information about this onto the wiki page at
>
> http://en.wikiversity.org/wiki/QuantLib/VtkIntegration
>
> that would be useful. Also in general I'm trying to get more and more people
> onto Wikiversity to use that as a research hub for these sorts of things.
>
> > Just a question: why do you think SWIG would be needed in this case?
>
> Because there are already working bindings for QuantLib to SWIG. Also, I
> think I can test the Surface interface through the R module before the VTK
> gets integrated.
>
>
>
> -------------------------------------------------------------------------------
> Joseph Wang Ph.D. - [hidden email]
> China Derivatives Researcher and Software Developer - QuantLib
> http://en.wikiversity.org/wiki/User:Roadrunner
>
>
>
>
>

--
Gheorghe Postelnicu, PhD
MGH, Harvard Medical School

Joseph Wang-2

Re: Surface interface

In reply to this post by Ferdinando M. Ametrano-3

I just realized that my e-mail didn't seem to have made it to the list.
Apologies if this is a duplicate....

The idea is to recreate three classes that would abstract the details of
quantlib from external plotting applications that would access things classes
through SWIG or straight c++.

The three classes are

class Curve : public std::unary_function<Real, Real> {
public:
virtual Real operator()(Real x) const = 0;
};

class Surface : public std::binary_function<Real, Real, Real> {
public:
virtual Real operator()(Real x, Real y) const = 0;
virtual Domain* domain() const = 0;
virtual ~Surface() {};
};

class Domain : public std::binary_function<Real, Real, bool>{
public:
virtual bool includes(Real x, Real y) const = 0;
bool operator()(Real x, Real y) {return includes(x, y);}
virtual ~Domain() {};
};

The way that these classes would work is suppose I want to plot the result of
a PDE calculation. I create a class

class TimeIndexedCurve : public TimeSeries <Curve>, public Surface {
public:
add(SampledCurve &c);
}

In my code, I add curves to this structure as I'm calculating them, and then
the plotting program takes a pointer to surface and they plots the surface.
If the curves and surfaces inherit this interface, then I just have to write
one plotting routine in the external program and it will plot anything that
implements the interface.

Another example of using these items is to pass curves from an external
program to QuantLib

class RFunction : public Curve;
class PythonFunction : public Curve;

These can then be used for things like payoff functions.

On Tuesday 28 November 2006 02:52, Ferdinando Ametrano wrote:

Joseph Wang-2

Re: Surface interface

In reply to this post by Gheorghe Postelnicu

Just to let you know where I am with this. I'm trying to get tvtk and mayavi2
installed before proceding further with trying to interface this all with
quantlib. tvtk and mayavi2 are open source enhancements made to vtk by the
Austin company enthought, which you can read about at
http://www.enthought.com/

I figure that it will be about a month before I get completely acclimated with
the tools. Right now a high priority for me is to figure out how to get
these tools built with RPM.

--
-------------------------------------------------------------------------------
Joseph Wang Ph.D. - [hidden email]
China Derivatives Researcher and Software Developer - QuantLib
http://en.wikiversity.org/wiki/User:Roadrunner