Page 1 of 3

Duck Typing

Posted: May 21st, 2017, 6:20 pm
by Cuchulainn
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. 

Re: Duck Typing

Posted: May 21st, 2017, 6:54 pm
by outrun
It's Java ItIsLikeSo, while boost is more_like_so

Re: Duck Typing

Posted: May 21st, 2017, 7:00 pm
by outrun
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!

Re: Duck Typing

Posted: May 21st, 2017, 7:02 pm
by ISayMoo
Wikipedia entry

It makes testing more complex Python code an awfully funny affair, mostly awfully.

Re: Duck Typing

Posted: May 21st, 2017, 7:31 pm
by outrun
oops! :D

Re: Duck Typing

Posted: May 21st, 2017, 7:35 pm
by Cuchulainn
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'?

Re: Duck Typing

Posted: May 21st, 2017, 7:37 pm
by Cuchulainn
Wikipedia entry

It makes testing more complex Python code an awfully funny affair, mostly awfully.
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 concepts in C++) or an even more scary run-time error in Python at worse (I don't know Python).

Re: Duck Typing

Posted: May 21st, 2017, 8:08 pm
by outrun
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. 

Re: Duck Typing

Posted: May 21st, 2017, 8:11 pm
by outrun
Are you working on policies, using type dispatching?

Re: Duck Typing

Posted: May 21st, 2017, 10:13 pm
by Cuchulainn
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.

Re: Duck Typing

Posted: May 22nd, 2017, 6:42 am
by outrun
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.

Re: Duck Typing

Posted: May 22nd, 2017, 6:51 am
by outrun
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?

Re: Duck Typing

Posted: May 22nd, 2017, 12:16 pm
by Cuchulainn
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?

Re: Duck Typing

Posted: May 22nd, 2017, 12:34 pm
by Cuchulainn
oops! :D
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.

Re: Duck Typing

Posted: May 22nd, 2017, 12:34 pm
by 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..