Serving the Quantitative Finance Community

 
User avatar
Polter
Posts: 1
Joined: April 29th, 2008, 4:55 pm

The ultimate Monte Carlo framework

October 23rd, 2012, 12:23 pm

Cuch, your code doesn't compile for me: http://ideone.com/lMlZvG Fixed (I think*) version: http://ideone.com/QgNcHn* -- I'm not sure, as I don't have time to decipher what does "T" stand for and therefore what is its intent (I could guess it's perhaps a "Scalar"? but guessing can be wrong...)
Last edited by Polter on October 22nd, 2012, 10:00 pm, edited 1 time in total.
 
User avatar
Cuchulainn
Posts: 20254
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

The ultimate Monte Carlo framework

October 23rd, 2012, 12:48 pm

QuoteOriginally posted by: PolterCuch, your code doesn't compile for me: http://ideone.com/lMlZvGThe FDM_NOTII is the spurious one indeed! It compiles on VS2010 and that is bad.idemdito stack<char, list<int>>BTW the TTP one does compile I suppose.
 
User avatar
Polter
Posts: 1
Joined: April 29th, 2008, 4:55 pm

The ultimate Monte Carlo framework

October 23rd, 2012, 12:52 pm

Yeah, I fixed that (I think) -- I always find it helpful to provide a link to Ideone.com when I'm sharing a piece of code, it forces me to provide something that actually compiles (well, at least on GCC) and runs ;]
 
User avatar
Cuchulainn
Posts: 20254
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

The ultimate Monte Carlo framework

October 23rd, 2012, 12:56 pm

I called () and it did no compile Indeed It was a counterexample and shows TTP is better. My bad.
Last edited by Cuchulainn on October 22nd, 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 23rd, 2012, 12:57 pm

BTW, why do you prefer "FDM_II" to "FDM"?
 
User avatar
Cuchulainn
Posts: 20254
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

The ultimate Monte Carlo framework

October 23rd, 2012, 1:04 pm

QuoteOriginally posted by: PolterBTW, why do you prefer "FDM_II" to "FDM"?FDM_II was done _just_ to stretch FDM with TTP. Having said that, FDM_II could be seen as a higher level entity above SDE and FDM. Maybe the name FDM_II should be called Mediator or something. It could be a container of FDM instances.
Last edited by Cuchulainn on October 22nd, 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 23rd, 2012, 1:30 pm

I see.Now, the next step would be to add some constraints (either traits or tags suggested by outrun or perhaps using BCCL).Here's what I mean: http://ideone.com/wgzZh6Compiles without issues: FDM<double, std::allocator> mySolver3; std::cout << mySolver() << std::endl;Doesn't compile since "(std::allocator<std::vector<double> >)" doesn't satisfy the Callable concept (that's a plus) but we could use a friendlier compiler diagnostic: FDM_II<std::vector<double>, std::allocator, FDM> fdmIIB; std::cout << "fdmIIB: " << fdmIIB() << std::endl;And the instantiation itself again compiles without complaints: http://ideone.com/A4uZSR
Last edited by Polter on October 22nd, 2012, 10:00 pm, edited 1 time in total.
 
User avatar
Cuchulainn
Posts: 20254
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

The ultimate Monte Carlo framework

October 23rd, 2012, 2:15 pm

QuoteOriginally posted by: PolterI see.Now, the next step would be to add some constraints (either traits or tags suggested by outrun or perhaps using BCCL).Here's what I mean: http://ideone.com/wgzZh6Compiles without issues: FDM<double, std::allocator> mySolver3; std::cout << mySolver() << std::endl;Doesn't compile since "(std::allocator<std::vector<double> >)" doesn't satisfy the Callable concept (that's a plus) but we could use a friendlier compiler diagnostic: FDM_II<std::vector<double>, std::allocator, FDM> fdmIIB; std::cout << "fdmIIB: " << fdmIIB() << std::endl;And the instantiation itself again compiles without complaints: http://ideone.com/A4uZSRFDM_III is a collection of FDM but I get similar compiler errors.
Last edited by Cuchulainn on October 22nd, 2012, 10:00 pm, edited 1 time in total.
 
User avatar
MiloRambaldi
Posts: 1
Joined: July 26th, 2010, 12:27 am

The ultimate Monte Carlo framework

October 23rd, 2012, 2:32 pm

QuoteOriginally posted by: outrunClear example Milo. So it's not a specific dynamic (run time) issue.I would provide and use Method_f_1 and keep the generation of Cartesian outer products outside the project. It increases complexity of the code to solve a too specific problem that should be orthogonal to the framework. I can only come up with a usecase in test frameworks, and people who use it in that context know how to do this to their liking.Why would this belong in a MC framework? It's a too academic problem IMO, and you show it can be solved in various ways each with own benefit.Just to clarify: The cartesian_product is outside the MC framework. It is in qfcl/utility which contains general code that can be used in any project (e.g. in qfcl/random or qfcl/mc1).However, I believe this must be dealt with in MC1 in order to implement the builder pattern.
 
User avatar
MiloRambaldi
Posts: 1
Joined: July 26th, 2010, 12:27 am

The ultimate Monte Carlo framework

October 23rd, 2012, 2:46 pm

QuoteOriginally posted by: outrunanother one maybe to not generate cartesian products automatically but let the user specificy the combinations it want's to calcualte.However if you make a manual list the size of the cartesian product then I would expect the compile time to be identical.Just to make sure we are on the same page, even if the user wants to generate only a single combination at run-time, then we need to compute the entire cartesian product (or something analogous) at compile time. This is the case in the current version of qfcl/test/TestMC.
 
User avatar
Polter
Posts: 1
Joined: April 29th, 2008, 4:55 pm

The ultimate Monte Carlo framework

October 23rd, 2012, 3:36 pm

QuoteOriginally posted by: Cuchulainn It compiles on VS2010 and that is bad.Huh... turns out we should've tried Clang, too: http://llvm.org/demo/If I copy-paste the code from http://ideone.com/A4uZSR (keeping the same line numbers -- s.t. "source.cc:27:42" in the following denotes line 27, column 42 of the source code), I obtain the compilation diagnostics as the ones attached.Clang stops complaining if we get rid of the shadowed names like this: http://ideone.com/l97a4SNote, that these second (and third, etc.) "T"s wouldn't do anything anyway, so it's not a loss (if anything, we may want to put different names for documentation purposes):QuoteThe second template parameter is new. It is a template template parameter. It has the following elements: The keyword template, starting the template template parameter; The keyword template is followed (between pointed brackets) by a list of template parameters that must be specified for the template template parameter. These parameters may be given names, but names are usually omitted as those names cannot be used in subsequent template definitions. On the other hand, providing formal names may help the reader of the template to understand the kind of templates that must be specified with the template template parameter.See: http://www.icce.rug.nl/documents/cplusp ... PTEMPPARBy using-different-names-for-self-doc-code I mean something like "ElementType" in the following:template <typename T, template <typename ElementType> class Cont>class Stack;Notice, how "T" (which is a bad/non-descriptive name, BTW) and "ElementType" are different names.See: http://www.informit.com/articles/article.aspx?p=376878
Last edited by Polter on October 22nd, 2012, 10:00 pm, edited 1 time in total.
 
User avatar
MiloRambaldi
Posts: 1
Joined: July 26th, 2010, 12:27 am

The ultimate Monte Carlo framework

October 23rd, 2012, 4:58 pm

QuoteOriginally posted by: outrunIs that to build a library you can link against? This design doesn't scale, in general a MC project will only use a very limited set of combinations out of the cartesian set. Also there is the idea to add type checking that will cause compiler errorsProbably, I'm not sure if headers only is possible.As far as pruning the full cartesian product, I'm quite sure that can be readily handled. Aside from the compiler performance issues which I am hopeful can be overcome, I think the design is fully scalable.