What is it? I get the impression it is used a lot but not mentioned along the way. It is implicit knowledge.

My take is that syntax oriented C++/Boost policies are in fact special cases of duck typing.

- Cuchulainn
**Posts:**60268**Joined:****Location:**Amsterdam-
**Contact:**

What is it? I get the impression it is used a lot but not mentioned along the way. It is implicit knowledge.

My take is that syntax oriented C++/Boost policies are in fact special cases of duck typing.

My take is that syntax oriented C++/Boost policies are in fact special cases of duck typing.

It's a cultural convention to make function and variable names more readable, especially

those who consist of multiple descriptive words.

It's not a language requirement / feature, but a convention. A great thing to argue about!

those who consist of multiple descriptive words.

It's not a language requirement / feature, but a convention. A great thing to argue about!

- Cuchulainn
**Posts:**60268**Joined:****Location:**Amsterdam-
**Contact:**

Shall I take a precise, compact test case and see how to model it in the 4-5 well-known ways and then call in the jury to investigate the pros and cons of each 'suspect'?

- Cuchulainn
**Posts:**60268**Joined:****Location:**Amsterdam-
**Contact:**

Has it to do with this? Especially the 'comments' remarks? How do we know what client code needs to know?(?)

A disadvantage of policies in their current incarnation is that the policy interface doesn't have a direct, explicit representation in code, but rather is defined implicitly, via duck typing, and must be documented separately and manually, in comments. The main idea is to use commonality-variability analysis to divide the type into the fixed implementation and interface, the policy-based class, and the different policies. The trick is to know what goes into the main class, and what policies should one create. The article mentioned above gives the following answer: wherever we would need to make a possible limiting design decision, we should postpone that decision, we should delegate it to an appropriately named policy.

//

In fairness, if you don't implement your abstract functions you get a compiler error whereas with DT you might give the server a chicken (chicken don't quack in general) and then I suspect we get an unreadable compiler at best (no

Last edited by Cuchulainn on May 21st, 2017, 8:47 pm, edited 1 time in total.

In C++ sending an object of some type to a server would require some transport mechanism that packs and unpack. The unpack routine that created an object of some specified type would need to be compiled at the server, would know the list of types it can handle, and hence it's not any different than generic DT issues a local machine?

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

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

- Cuchulainn
**Posts:**60268**Joined:****Location:**Amsterdam-
**Contact:**

One use case is modelling bunches of functions as a unit as it were. Take a scoped down *nonlinear* generalised BS PDE for the sake of argument.

\[\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.

\[\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.

I know very little about the requirements, but my first choice would be to use types, traits and policies, and pick non-member functions over member functions when possible. These choices are often subjective, choices will have pros and cons that need to match design objectives.

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.

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.

Last edited by outrun on May 22nd, 2017, 7:35 am, edited 1 time in total.

Typedef<T>

bool is_stoch_vol(T&) {return false;}

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?

bool is_stoch_vol(T&) {return false;}

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?

- Cuchulainn
**Posts:**60268**Joined:****Location:**Amsterdam-
**Contact:**

One scenario is that PDEs are approximated by FD schemes. A given FD scheme must work with my PDEs having the same structure (you don't want to rewrite Crank Nicolson that comes along). Second, a given PDE can be approximated by a number of FD schemes. This is not difficult in C++11.

*pick non-member functions over member functions when possible. *

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?

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?

- Cuchulainn
**Posts:**60268**Joined:****Location:**Amsterdam-
**Contact:**

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.oops!

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..

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..

GZIP: On