https://letyourmoneygrow.com/2017/05/25 ... o-finance/

Statistics: Posted by finanzmaster — May 25th, 2017, 9:32 pm

]]>

I meant something else, if some set of models have constant vol then it doesn't make sense to demand (in the overall interface of the design) that those models implement a vol(S,t) member function -since the vol doesn't depend on S and t-.

At the same time the PDE solver also needs to know if a specific mode has a vol that depends of S and t or not. If it doens't then it can optimize calculations, e.g. it would be pointless to call vols(S,t) many times as it traverses the discretised S,t grid. One time is enough for constant vol models.

So, I would first try to define the various interfaces that SDE models can have. Some models have constant vol, others have a surface, of stochastic vol.. each type would need to capture different data inside the object, and provide different member functions to extract that data. Once that's settled and when you have "types" defined, you can then use overloading or type traits to dispatch compile time?

Overloading is very readable and simple but traits are more flexible. E.g. maybe your PDE solver will want pick the same algorithms for a range of model types. You don't want to write the same overloader for all those types, it's more elegant to associate some common trait to all those model types.

Statistics: Posted by outrun — May 24th, 2017, 2:39 pm

]]>

One solution is variadics. Would this be a solution for everything? I like variadics.

In any solution, a clear interface between server and client is needed, at the very least.

Statistics: Posted by Cuchulainn — May 24th, 2017, 2:07 pm

]]>

The traits (model_trait<T>::has_const_vol) could e.g. be implemented based on tag dispatching (the mode writer has to explicitly add member types to the VolModel class which the PDE solver recognises, and can use to inspect the model type using the traits mechanism). You can also encode the information not via tags, but via member function names or member function signatures. E.g. you can demand in your design that a constant vol model needs to have a public "vol" member variable and that a time dependent vol model needs to have a vol(double t) member function (encoded in arg) or a vol_t(double t) member function (encoded in function name). The tag dispatching scales better though. You can explicitly tag groups of models with all sort of info like "has stochastic vol" without abusing the interface.

Code:

`template <typename VolModel>`

double diffusion(VolModel& vm, double S, double t)

{

return vm(S, t);

}

Statistics: Posted by outrun — May 24th, 2017, 9:04 am

]]>

Code:

`// TestVolatilityAndPde.cpp`

//

// Introducing various volatility into PDE

//

// 1. Policy (ducks)

// 2. Signature-based

// 3. Other approaches ??

#include <iostream>

#include <cmath>

#include <functional>

struct Pde

{ // signature

std::function<double (double S, double T)> diffusion;

// etc.

};

struct PdeII

{ // duck

template <typename VolModel>

double diffusion(VolModel& vm, double S, double t)

{

return vm(S, t);

}

// etc.

};

struct MyVolModelI

{

double ComputeVol(double S, double t)

{

return 1.0 + std::sin(t);

}

double operator ()(double S, double t)

{

return ComputeVol(S,t);

}

};

int main()

{

Pde pde;

MyVolModelI vm;

using namespace std::placeholders;

pde.diffusion = std::bind(&MyVolModelI::ComputeVol, vm, _1, _2);

std::cout << pde.diffusion(100, 0.5) << '\n';

auto lambdaDiffusion = [](double S, double t)

{

// Call a yuge solver, answer is 42

return 42;

};

pde.diffusion = lambdaDiffusion;

std::cout << pde.diffusion(100, 0.5) << '\n';

{

// Ducks in a row

PdeII pde2;

MyVolModelI vm;

std::cout << pde2.diffusion<MyVolModelI>(vm,200.0, 0.5) << '\n';

}

}

outrun:define a non-member function like:

double get_sigma(vol_model, S, t)

this would be the interface that all things vol need to implement for PDE. The PDE code will call this function, and any model that want to support being fed to the PDE solver would need to implement this.

depending of the *type* of vol_model (or type traits) you can make it return vol_model.sigma (for those types that have a public vol sigma parameter)

or return bilinear_interpolate(vol_model, ..) for the types where vol model is some surface definition

or return 1.0 + sin(t) is that's what your vol_model is defined as..

I have produced 2 solutions based on my understanding. Ideally, I don't want PDE to know what vol is because it make the interface less generic. I also give a 2nd option. In that case the PDE knows nothing about vol; a 'diffusion factory' does the job on behalf of PDE.

Maybe there are more options. What do you think?

Or somebody could bring what is needed to the PDE; then the PDE does not have to know nothing?

Statistics: Posted by Cuchulainn — May 24th, 2017, 6:48 am

]]>

]]>

]]>

double get_sigma(vol_model, S, t)

this would be the interface that all things vol need to implement for PDE. The PDE code will call this function, and any model that want to support being fed to the PDE solver would need to implement this.

depending of the *type* of vol_model (or type traits) you can make it return vol_model.sigma (for those types that have a public vol sigma parameter)

or return bilinear_interpolate(vol_model, ..) for the types where vol model is some surface definition

or return 1.0 + sin(t) is that's what your vol_model is defined as..

Statistics: Posted by outrun — May 22nd, 2017, 12:34 pm

]]>

oops!

Python uses duck typing and has typed objects but untyped variable names. Type constraints are not checked at compile time; rather, operations on an object may fail, signifying that the given object is not of a suitable type. Despite being dynamically typed, Python is strongly typed, forbidding operations that are not well-defined (for example, adding a number to a string) rather than silently attempting to make sense of them.

Statistics: Posted by Cuchulainn — May 22nd, 2017, 12:34 pm

]]>

This is a good trick in some cases. But not here. e.g. take BS diffusion [$]\frac{1}{2} \sigma^2 \: S^2[$] where does [$]\sigma[$] fit in?

Statistics: Posted by Cuchulainn — May 22nd, 2017, 12:16 pm

]]>

Could be the default, when called with the Heston type you could make it return true. This is known compile time, and this traits will allow your sde solver to add a volatility dimensional?

Statistics: Posted by outrun — May 22nd, 2017, 6:51 am

]]>

You could have grid types, allow the solver to configure itself compile time based on grid traits. You can group sde type with traits into groups, each group requiring a certain configuration...

Types like "Heston" could be empty, purely there to to associate function (I would prefer functions over member functions) with the type via type dispatching.

Statistics: Posted by outrun — May 22nd, 2017, 6:42 am

]]>

\[\frac{\partial V}{\partial t} = \sigma(S,t)\frac{\partial^2 V}{\partial S^2} + \mu(S,t) \frac{\partial V}{\partial S} + f(V,S,t) . \]

Clients (BS, CEV, CIR, CVA, early,UVM etc.) can choose their own coefficients easily,e.g. using lambda. So, the issue is how to model the PDE in the 'easiest' way.

A nice extension is to model coefficients.as variadic parameters in a PDE just once and then one can have 1d, 2d (basket, Heston), 3d(raiinbow) clients without copy and paste. I have done some tests and it seems quite elegant. I reckon outrun's dispatching would be useful. Is that the idea? In this case the server is the PDE. It might be possible to sharpen the server-client contract using C++11 type traits library (S and t must be scalar etc,) but have not done it yet.

The coefficients could be syntax (duck typing) or signature based (using std::function). I kind of prefer the latter.

It avoids the drudgery of having to write a separate class for each dimension.It's like a PDE<int N>. Just like mathematics. There are other options but this one saves code bloat.

It looks good but maybe but I don't yet have a 'snag list'.. What do you think?

Only since C++11/14.

Statistics: Posted by Cuchulainn — May 21st, 2017, 10:13 pm

]]>

]]>

Using strong types will indeed allow to and optimize and catch errors compile time.

Statistics: Posted by outrun — May 21st, 2017, 8:08 pm

]]>