Serving the Quantitative Finance Community

 
User avatar
Cuchulainn
Posts: 20252
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

The ultimate Monte Carlo framework

October 22nd, 2012, 9:49 am

QuoteOriginally posted by: outrunHow do you implement the knowledge where you want to prevent non line SDE with CN to be combined? Isn't that the same in C++ and C#, an explicit bit of code that encodes the knowledge?Yes, somewhere this must be given. I just gave a hard-coded answer, but I am sure there is a better way. Maybe something in the lines of a compiler (like Spirit)? Or some kind of access control matrix. Not sure.
Last edited by Cuchulainn on October 21st, 2012, 10:00 pm, edited 1 time in total.
 
User avatar
Cuchulainn
Posts: 20252
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

The ultimate Monte Carlo framework

October 22nd, 2012, 10:07 am

QuoteEnfin.. Everyone is of course free to hypothise any goal he wants, I do that too sometimes -purely out of personal pleasure & skill development-. If I was manager of a software company I would of course stop this goal-less experimenting. On the contary, this is a vital problem. And this is qfcl project, not a s/w company. We are not doing this in the employer's time I assume (1 exception being myself, I suppose, being self-employed and have this freedom). If you were a manager then all off a sudden you will be inundated with many programing styles. The best s/w managers I have seen are those who let developers get on it the job, assuming that the latter are not hobbying.
Last edited by Cuchulainn on October 21st, 2012, 10:00 pm, edited 1 time in total.
 
User avatar
Cuchulainn
Posts: 20252
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

The ultimate Monte Carlo framework

October 22nd, 2012, 10:09 am

QuoteOriginally posted by: outrunQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: outrunHow do you implement the knowledge where you want to prevent non line SDE with CN to be combined? Isn't that the same in C++ and C#, an explicit bit of code that encodes the knowledge?Yes, somewhere this must be given. I just gave a hard-coded answer, but I am sure there is a better way. Maybe something in the lines of a compiler (like Spirit)? Or some kind of access control matrix. Not sure.That's someting that can very nicely be done in C++ with traits and tags. e.g. something that return true type of false type if an SDE is linear or not? Also make it a default behavior to pick the best combi but also allow a user to do it anyway.It is possible to show _how_ and put us out of our misery? A simple 101 case is fine. At this stage we have no traits solution and why is it better than Milo's 1), 2) and 3)?
Last edited by Cuchulainn on October 21st, 2012, 10:00 pm, edited 1 time in total.
 
User avatar
Polter
Posts: 1
Joined: April 29th, 2008, 4:55 pm

The ultimate Monte Carlo framework

October 22nd, 2012, 11:18 am

QuoteOriginally posted by: MiloRambaldi(1) "Advanced" TMP, where the cartesian product of types is literally computed by meta-code. The example code for Method 1 is clearly the most elegant and concise. Currently this solution has the problem that computing cartesian products in TMP is very slow to compile even for moderately sized product, and even worse causes the compiler to blow up as the size grows. However, I believe that these compiler issues can be overcome by using the MPL package I mentioned below --- but this remains to be tested.So far, I like this idea the most. (Although, if possible, pruning would be useful -- I'd view it as a type-safety feature not to be able to use, say, CrankNicolson as, say, RandomNumberGenerator with a MonteCarloPricer ;]).BTW, before you spend time going too deeply into MPL, do you think you could take a look at Boost.Proto and see if it does what you need? Reason I'm bringing this up in this context: http://www.boost.org/doc/libs/release/d ... orQuote(2) Run-time polymorphism. This is essentially BLOCK I in Cuchulainn's post below. It is easy to implement, but very inelegant, goes against the design goals and will cause performance degradation. (I'm assuming we agree that BLOCK II is not helpful for the problem at hand.)Please, no, if it's possible to avoid :-)Generally, run-time solutions have (by definition) weaker type-safety than compile-time solutions.Let's be honest here, both can result in non-trivial-to-debug programs.But I'd rather stare at N-deep stack of template invocations reported by the compiler from a buggy program that refused to compile, than have to go through a N-deep stack of virtual function calls in a buggy program that compiled and silently omitted reporting the problem until the very moment it occurred. Conjecture: compile-time polymorphism is easier to use, debug, maintain, and understand than run-time polymorphism.Quote(3) Hard-coding at the top level. I originally dismissed this solution, and it is unfeasible to write this code by hand in larger examples. However, perhaps the solution could be made feasible where the original source (which may or may not be entirely in C++) is compiled once to obtain intermediate source code which is then run through the C++ compiler. It seems inelegant to me, but perhaps this is a normal procedure for large projects... Yeah, this probably won't scale?
Last edited by Polter on October 21st, 2012, 10:00 pm, edited 1 time in total.
 
User avatar
Cuchulainn
Posts: 20252
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

The ultimate Monte Carlo framework

October 23rd, 2012, 5:39 am

Maybe not all people use traits. The problem with traits IMO it's possible to use inconsistent data types.What if I say in my main() function the code below? It wil probably compile (and run!) but is semantically incorrect? This is probably the same problem in STL below.I think template template parameters would resolve this issue with traits. Maybe I worry too much.
Last edited by Cuchulainn on October 22nd, 2012, 10:00 pm, edited 1 time in total.
 
User avatar
Cuchulainn
Posts: 20252
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

The ultimate Monte Carlo framework

October 23rd, 2012, 11:29 am

QuoteOriginally posted by: outrunIf you want that then either 1) provide a different interface for the jump SDE (don't call the members pure_ diffusion), that way you use the interface signature to tag properties.2) or have the default trait map to nothing) 3) Or "disable_if" the Euler scheme for SDEs that have a jump member function. I think I prefer this one.These all destroy polymorphism I suspect. Solution 3) is particularly nasty looking.
 
User avatar
Cuchulainn
Posts: 20252
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

The ultimate Monte Carlo framework

October 23rd, 2012, 11:31 am

4)and5)
 
User avatar
Cuchulainn
Posts: 20252
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

The ultimate Monte Carlo framework

October 23rd, 2012, 11:54 am

N.B. I used the word 'suspect' because no working code was provided for 1), 2) and 3) options. So, on first impressions they look like workarounds. We agree to disagree at this stage. For me, TTP is the most robust solution. And I provide running code which is not the case for 1), 2) and 3). Please provide code + main() so that we can test it. Otherwise, I have to take it on faith, which I don't.
Last edited by Cuchulainn on October 22nd, 2012, 10:00 pm, edited 1 time in total.