Serving the Quantitative Finance Community

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

The ultimate Monte Carlo framework

October 23rd, 2012, 6:24 pm

QuoteOriginally posted by: PolterQuoteOriginally 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/articl ... 78Bleeding edge.
 
User avatar
Cuchulainn
Posts: 20250
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

The ultimate Monte Carlo framework

October 23rd, 2012, 6:31 pm

Returning to an earlier postQuoteOriginally posted by: PolterQuoteOriginally 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 ... rocessorIt might be a solution if someone devotes some time to it. At first glance some kind of entity modelling like in iSO 10303-11 which is used in oil and gas.
Last edited by Cuchulainn on October 22nd, 2012, 10:00 pm, edited 1 time in total.
 
User avatar
Cuchulainn
Posts: 20250
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

The ultimate Monte Carlo framework

October 23rd, 2012, 6:32 pm

QuoteSimilarly I would guard against run-time polymorphism or weak-typing. Why?
 
User avatar
MiloRambaldi
Posts: 1
Joined: July 26th, 2010, 12:27 am

The ultimate Monte Carlo framework

October 23rd, 2012, 7:15 pm

QuoteOriginally posted by: CuchulainnQuoteOriginally posted by: outrunIndeed, the goal is unspecified, and 1) I don't want to try to bend it somewhere we all think to differently about goals2) the current issue seems an artificial / academic (but maybe interesting however outside a potential scope I would have) multimap<problem,solutions>and that leaves me in a position that I don't have anything useful to say.Well, maybe Milo can define the goals and we can take it from there, i.e. in the implementation phase to determine what the best fit is.We have to know what the problem is before a solution can be proferred.In its most general form, my goal is run-time type selection without any run-time polymorphism.A more concrete goal is to implement the builder pattern for MC1. The run-time type selection is just the first hurdle ...
 
User avatar
Cuchulainn
Posts: 20250
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

The ultimate Monte Carlo framework

October 24th, 2012, 4:11 am

QuoteIn its most general form, my goal is run-time type selection without any run-time polymorphism.Clear.It is interesting _how_ this will pan out in a typical interaction scenario;U1: Choose SDE, FDM objects from a pallete of optionsU2: Adding/removing optionsU3: Running multiple instances of MC1 (possible in parallel)U4: How to configure the system (e.g. using XML, dlls, assembles?)QuoteA more concrete goal is to implement the builder pattern for MC1. The run-time type selection is just the first hurdle ...Once this has been achieved then it can be done for other kinds of systems (in C# as well).What you are doing has done many times before - at least in Java and C# - so benchmrking how they do it does not do any harm. See Dependency Injectiion in C# No point reinventing the wheel.
Last edited by Cuchulainn on October 23rd, 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 26th, 2012, 4:45 am

QuoteOriginally posted by: PolterBTW, 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 ... processorI did have a look at Boost.Proto, but as far as I can tell it is only for creating function objects and not for type computations. Though I suppose the context you pointed out is relevant: They claim that there was up to a 10x speedup when they used preprocessor macro methods, instead of building on MPL and Fusion.On the other hand, I am not familiar with Fusion but it seems that it might be very useful here: not for the actual cartesian product, but for constructing an n-nested mpl::for_each loop which is really what is needed for runtime type selection.
 
User avatar
Cuchulainn
Posts: 20250
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

The ultimate Monte Carlo framework

October 26th, 2012, 2:30 pm

QuoteOriginally posted by: MiloRambaldiQuoteOriginally posted by: PolterBTW, 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 ... processorI did have a look at Boost.Proto, but as far as I can tell it is only for creating function objects and not for type computations. Though I suppose the context you pointed out is relevant: They claim that there was up to a 10x speedup when they used preprocessor macro methods, instead of building on MPL and Fusion.On the other hand, I am not familiar with Fusion but it seems that it might be very useful here: not for the actual cartesian product, but for constructing an n-nested mpl::for_each loop which is really what is needed for runtime type selection.More generally, there is a need IMO to model entities as in my link to ISO 10303-11 (Express) or even something like UML metamodelling. Until something on these lines can be done in C++ I think it will be very difficult with just the current functionality.
Last edited by Cuchulainn on October 25th, 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 26th, 2012, 3:13 pm

MiloRambaldi, great! Thanks for checking & good to know!
 
User avatar
MiloRambaldi
Posts: 1
Joined: July 26th, 2010, 12:27 am

The ultimate Monte Carlo framework

February 15th, 2013, 10:24 pm

I've had time lately to continue working on this. Version 0.5 of qfcl/random is now available available. Recall that the extra libraries needed to build everything (NTL and some boost extensions) are in my sandbox.This has been tested on Visual Studio only. It remains (at least) to make the build work on Linux too, and to complete the documentation before submitting to boost for review (I know they are interested in the O(1) jump ahead, and I'm hoping they will also be interested in some of the other features, especially the generalization of MT to arbitrary linear generators).Several months ago I observed that the qfcl mersenne twister (called MT19937) was somewhat slower (~25%) than boost-MT19937. It turns out that this is only the case when the engines are passed by reference (non-const of course) to the timing routine. When I tried making the timing routing a macro function, both engines were faster, but the difference for the qfcl engine was big, so that it was in fact significantly faster than the boost engine (~17%). I was expecting the new design to be a bit faster than boost.I thought perhaps that passing by reference was causing an indirection in the call to the engine, but looking at the assembly code it seemed that the compiler was smart enough to inline the timing function. I will have to look into this in more detail because I want to understand what is going on. If someone has any ideas please share.There is other stuff in the repository. I have been working on something else that could possibly be submitted to boost, related to run-time type-selection, but it is not ready yet.