SERVING THE QUANTITATIVE FINANCE COMMUNITY

 
User avatar
Cuchulainn
Posts: 59949
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

The ultimate Monte Carlo framework

September 26th, 2012, 4:33 pm

Milo,some design on MC1. An incremental approach is probably recommended.System Configuration and Creational PatternsIn the first version of MC1 we concentrated on implementing a number of numerical methods (in the main, finite difference schemes) that approximate the solution of one-factor stochastic differential equations. The emphasis was on accuracy and functionality on the one hand and creating a flexible design on the other hand. This decision comes at a price and the main consequence of this decision is that other parts of the design process suffer. In particular, when testing the classes in Figure 1 we used hard-coded constructors in main() to create instances of the classes that we wish to use. Some consequences of this approach are:a) The code becomes difficult to understand and to maintain. Inconsistencies can arise.b) It is not possible to configure MC1 without editing and recompiling code.c) It will be difficult to add new functionality to MC1 in the form of new external systems and classesd) We would like to use MCMediator as an independent, reusable component but this goal if difficult to achieve because of the many hard-coded dependencies between it and its dependent systems.Nonetheless, all is not lost because we do have a working prototype and it is now time to design and implement the next revision of the software. The basic goal is to be able to customise and configure MC1 in a step-by-step way. To this end, we examine the applicability of the Builder pattern as described in GOF 1995 to the current problem. Some new requirements are:. MCMediator should have knowledge only of the four systems that it is directly dependent on. In other words, it plays the role of the client in the Builder pattern. . We need to define Director and Builder components and include them as part of Figure 1. The former component contains the plan to construct specific instances of the components while a given builder is responsible for the construction and assembly of these components.. The interface of the Builder in GOF 1995 needs to be extended. In particular, GOF Builder seems to be focused on a single product that is in fact an aggregation of its parts. In the case of MC1, the final product is a related but loosely-coupled collection of components that communicate with MCMediator. We can refine the building process in a later version by outsourcing the creation of these components to other more specialised factory components. For example, the FDM subsystem in association with its SDE and RNG subsystems could be created by using the Abstract Factory pattern. We can also use the Factory Method pattern to create simpler systems.. The design must be flexible enough to allow us to model SDEs involving jumps as well as n-factor SDEs. To this end, we do not see any structural changes to Figure 1 but we will need to examine some of the classes that participate in the model.. We propose modeling the product in the Builder pattern as a Boost or std tuple because modeling it as a class or a struct is too restrictive and inflexible.How will we proceed? First, we model the product as a tuple. Then we modify and clean up the code in MCMediator so as to accept the above tuple in its constructor. Finally, we create the Director Builder classes. It is a good idea to concentrate on the provides-requires interfaces between components. The trick is to determine 'what' we want and then decide 'how' to realise that 'what'. //GOF Builder does not model Client explicitly, which causes confusion in its explanation. Thinking aloud; we can use Boost(?)typedef tuple<P1, P2,...> MyTuple;typedef boost::function<MyTuple () > Factory;Factory f = boost::factory<MyTuple>();MyTuple myTuple = f();-> Now access the components of MyTuple. And of course use boost::tie.What do you think?
Last edited by Cuchulainn on September 26th, 2012, 10:00 pm, edited 1 time in total.
 
User avatar
MiloRambaldi
Posts: 273
Joined: July 26th, 2010, 12:27 am

The ultimate Monte Carlo framework

September 30th, 2012, 1:19 pm

QuoteOriginally posted by: CuchulainnMilo,some design on MC1. An incremental approach is probably recommended.System Configuration and Creational PatternsIn the first version of MC1 we concentrated on implementing a number of numerical methods (in the main, finite difference schemes) that approximate the solution of one-factor stochastic differential equations. The emphasis was on accuracy and functionality on the one hand and creating a flexible design on the other hand. This decision comes at a price and the main consequence of this decision is that other parts of the design process suffer. In particular, when testing the classes in Figure 1 we used hard-coded constructors in main() to create instances of the classes that we wish to use. Some consequences of this approach are:a) The code becomes difficult to understand and to maintain. Inconsistencies can arise.b) It is not possible to configure MC1 without editing and recompiling code.c) It will be difficult to add new functionality to MC1 in the form of new external systems and classesd) We would like to use MCMediator as an independent, reusable component but this goal if difficult to achieve because of the many hard-coded dependencies between it and its dependent systems.Nonetheless, all is not lost because we do have a working prototype and it is now time to design and implement the next revision of the software. The basic goal is to be able to customise and configure MC1 in a step-by-step way. To this end, we examine the applicability of the Builder pattern as described in GOF 1995 to the current problem. Some new requirements are:. MCMediator should have knowledge only of the four systems that it is directly dependent on. In other words, it plays the role of the client in the Builder pattern. . We need to define Director and Builder components and include them as part of Figure 1. The former component contains the plan to construct specific instances of the components while a given builder is responsible for the construction and assembly of these components.. The interface of the Builder in GOF 1995 needs to be extended. In particular, GOF Builder seems to be focused on a single product that is in fact an aggregation of its parts. In the case of MC1, the final product is a related but loosely-coupled collection of components that communicate with MCMediator. We can refine the building process in a later version by outsourcing the creation of these components to other more specialised factory components. For example, the FDM subsystem in association with its SDE and RNG subsystems could be created by using the Abstract Factory pattern. We can also use the Factory Method pattern to create simpler systems.. The design must be flexible enough to allow us to model SDEs involving jumps as well as n-factor SDEs. To this end, we do not see any structural changes to Figure 1 but we will need to examine some of the classes that participate in the model.. We propose modeling the product in the Builder pattern as a Boost or std tuple because modeling it as a class or a struct is too restrictive and inflexible.How will we proceed? First, we model the product as a tuple. Then we modify and clean up the code in MCMediator so as to accept the above tuple in its constructor. Finally, we create the Director Builder classes. It is a good idea to concentrate on the provides-requires interfaces between components. The trick is to determine 'what' we want and then decide 'how' to realise that 'what'. //GOF Builder does not model Client explicitly, which causes confusion in its explanation. Thinking aloud; we can use Boost(?)typedef tuple<P1, P2,...> MyTuple;typedef boost::function<MyTuple () > Factory;Factory f = boost::factory<MyTuple>();MyTuple myTuple = f();-> Now access the components of MyTuple. And of course use boost::tie.What do you think?That's quite a bit to think about (I'm assuming that Figure 1 refers to your UML component diagram).The first thing for me would be to understand exactly what MCMediator's role as the Client is. Then I would start by making a simple prototype of the builder pattern that perhaps just builds the random engine and the FDM scheme based on command line arguments. I think things will become clearer once that is done...
 
User avatar
Cuchulainn
Posts: 59949
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

The ultimate Monte Carlo framework

September 30th, 2012, 2:45 pm

QuoteThe first thing for me would be to understand exactly what MCMediator's role as the Client is.Indeed!The other choice is that it can be a Director but it will make MCMediator top-heavy. edit: it is possble to do the process in increments; for example, I would let MCMediator just know about tuple of the hard-coded external systems. Then in stage 2 you can create flexible Builder and Director. Things can't go wrong because the Client is already operational. There might even be a stage 3 using TMP, XML... etc.
Last edited by Cuchulainn on September 30th, 2012, 10:00 pm, edited 1 time in total.
 
User avatar
MiloRambaldi
Posts: 273
Joined: July 26th, 2010, 12:27 am

The ultimate Monte Carlo framework

October 4th, 2012, 3:33 pm

QuoteOriginally posted by: CuchulainnQuoteThe first thing for me would be to understand exactly what MCMediator's role as the Client is.Indeed!The other choice is that it can be a Director but it will make MCMediator top-heavy. edit: it is possble to do the process in increments; for example, I would let MCMediator just know about tuple of the hard-coded external systems. Then in stage 2 you can create flexible Builder and Director. Things can't go wrong because the Client is already operational. There might even be a stage 3 using TMP, XML... etc.Then perhaps stage 1 is now done for this iteration. For now, I pass each of the external systems as a parameter of MCMediator's ctor. I could use a tuple, but I'm not sure why a tuple is preferable to a struct here?The main change is that MCReporter is now passed to the ctor. Another thing I did differently (it is only a few lines of code to switch back) is use a generic functor for the Payoff instead of boost::function. I can think of examples where boost::function requires less work that using a generic functor, but if the necessary generic libraries were available then it would not be the case. There seems to be a lot of discussion about the performance cost of using delegates like boost::function (though the boost documentation makes it sound like one is just as likely to get improved performance but I suspect this is a biased opinion).I also made MCTypeDMediator more generic by replacing double and long with template parameters. I realized after that double and long were probably just hard-coded as a first step in the incremental approach, but the update should only help I think.As for TMP is stage 3, I am already using it in the test_MC program to allow the user to select between types that have no common base class. I had some "adventures" in TMP with this but I'll discuss it in a different post. Below is the new declaration of MCTypeDMediator. It is also in version 0.42 of qfcl.
 
User avatar
Cuchulainn
Posts: 59949
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

The ultimate Monte Carlo framework

October 4th, 2012, 4:32 pm

QuoteThen perhaps stage 1 is now done for this iteration. For now, I pass each of the external systems as a parameter of MCMediator's ctor. I could use a tuple, but I'm not sure why a tuple is preferable to a struct here?The ctor sounds good. Struct is fine I think as well. Tuple is more lightweight.QuoteAnother thing I did differently (it is only a few lines of code to switch back) is use a generic functor for the Payoff instead of boost::function. I can think of examples where boost::function requires less work that using a generic functor, but if the necessary generic libraries were available then it would not be the case. There seems to be a lot of discussion about the performance cost of using delegates like boost::function (though the boost documentation makes it sound like one is just as likely to get improved performance but I suspect this is a biased opinion).My experience with boost function 1) it is very flexible 2) it is ~ 1.3 times slower than compile-time function ptrs.QuoteI also made MCTypeDMediator more generic by replacing double and long with template parameters. I realized after that double and long were probably just hard-coded as a first step in the incremental approach, but the update should only help I think.yes, they were V1 and not the biggest issue. We now just get more template parameters? For me, it is impossible to get all parameters generic in first sweep(besides, double and long are very popular, just like in Fortran).QuoteAs for TMP is stage 3, I am already using it in the test_MC program to allow the user to select between types that have no common base class. I had some "adventures" in TMP with this but I'll discuss it in a different post. Sounds like fun.QuoteBelow is the new declaration of MCTypeDMediator. It is also in version 0.42 of qfcl. Thanks. Is it downloadable for all people?
Last edited by Cuchulainn on October 3rd, 2012, 10:00 pm, edited 1 time in total.
 
User avatar
MiloRambaldi
Posts: 273
Joined: July 26th, 2010, 12:27 am

The ultimate Monte Carlo framework

October 7th, 2012, 2:31 am

QuoteOriginally posted by: CuchulainnQuoteI also made MCTypeDMediator more generic by replacing double and long with template parameters. I realized after that double and long were probably just hard-coded as a first step in the incremental approach, but the update should only help I think.yes, they were V1 and not the biggest issue. We now just get more template parameters?Yes, of course they are not serving any purpose at the moment. But I find hard-coding unpleasant to even look at ...QuoteQuoteBelow is the new declaration of MCTypeDMediator. It is also in version 0.42 of qfcl. Thanks. Is it downloadable for all people?As part of qfcl/random, I think everyone has read access by svn. But that means they have to download everything in qfcl/random. There is also a CMake build system included, but this has only been tested on MSVS. I could easily make a tag with source code for MC1 only. It would be a bit more difficult, but a tag with MC1 only including a CMake build could be made.
 
User avatar
MiloRambaldi
Posts: 273
Joined: July 26th, 2010, 12:27 am

The ultimate Monte Carlo framework

October 10th, 2012, 3:04 pm

I will try to explain why I believe TMP is in some sense necessary for MC1.The client of MC1 must be able to choose between any number of(1) random engines(2) FDM schemes(3) SDEs(4) output displays(5) payoffsand probably other components as well. For example, the current version of test_MC allows the engine and the FDM scheme to be chosen by command line parameters (while the rest is hard-coded for now).Each selection from one of these 5 categories (presumably?) has its own type. Thus for example, if each category had say 5 types to choose from, then there would be 5^5=3125 quintuples of types to choose between. If each of these 5 categories had a common abstract base class from which its classes inherited, then there would be no difficulty in choosing among all of the possibilities using run-time polymorphism: the factory method would be a standard way. However, in general generic types will not inherit from a common base class. In this case, all 3125 tuples need to be specified. If TMP or some other preprocessing method is not used, then this involves typing 3125 combinations by hand. The latter solution is completely infeasible, e.g. for maintenance reasons. One could try some trick like using type-erasure, but this would come at the price of lost genericity. My attempt at a solution was to write meta-code that generates the cartesian product of any meta-Sequence of types. In the MC1 example, the cartesian product of all 5 lists of types is the set of all quintuples of choices from each category. It is then possible to provide the client a run-time choice between all of the quintuples, by using mpl::for_each on the cartesian product. This is in version 0.43 of qfcl/random. The output of example/cartesian_product_example is below. However, this is does not solve the problem at hand, because Sequence of length > 255 are apparently not possible because of the VC++ limit of macros nested 255 deep, which is apparently what a meta-Sequence entails. My understanding of TMP is rather poor. For example, I don't know why the example below requires several minutes to compile, and more than 3GB of heap space!, when I could have done it by hand with a pencil and paper. After I did this, I found out that this has been discussed on the boost mailing lists. Apparently, using something called views avoids the limit on the length of the Sequences. However, other people who have written meta-code for cartesian products using views found that the compiler still blows up once the Sequence get much longer than 2000 or so elements.The best solution I could find seems to be cartesian_product - a Boost.MPL algorithm (I haven't tried it yet). It does not actually create a type corresponding to the cartesian product, but instead emulates the nested mpl::for_each loops that would result from iterating through the cartesian product. This does not allow for nested products as in the second and third examples below, but for typical applications such as MC1, there is no need for nesting.I have also attached the code for main(), but there are no surprises there.C:\...\Visual Studio 2010\Projects\QFCL\bin\examples\Release>cartesian_product_example.exeV1 = (0, 1, 2, 3) size(V1) = 4V2 = (a, b) size(V2) = 2V3 = (int, char, double) size(V3) = 3V1 X V2 X V3 =(0, a, int)(0, a, char)(0, a, double)(0, b, int)(0, b, char)(0, b, double)(1, a, int)(1, a, char)(1, a, double)(1, b, int)(1, b, char)(1, b, double)(2, a, int)(2, a, char)(2, a, double)(2, b, int)(2, b, char)(2, b, double)(3, a, int)(3, a, char)(3, a, double)(3, b, int)(3, b, char)(3, b, double) size(V1 X V2 X V3) = 24(V1 X V2) X V3 =((0, a), int)((0, a), char)((0, a), double)((0, b), int)((0, b), char)((0, b), double)((1, a), int)((1, a), char)((1, a), double)((1, b), int)((1, b), char)((1, b), double)((2, a), int)((2, a), char)((2, a), double)((2, b), int)((2, b), char)((2, b), double)((3, a), int)((3, a), char)((3, a), double)((3, b), int)((3, b), char)((3, b), double) size((V1 X V2) X V3) = 24V4 = (c, d) size(V4) = 2A1 = (e, f) size(A1) = 2A2 = (g, h) size(A2) = 2A2 X (A1 X (((V1 X V2) X V3) X V4)) =(g, (e, (((0, a), int), c)))(g, (e, (((0, a), int), d)))(g, (e, (((0, a), char), c)))(g, (e, (((0, a), char), d)))(g, (e, (((0, a), double), c)))(g, (e, (((0, a), double), d)))(g, (e, (((0, b), int), c)))(g, (e, (((0, b), int), d)))(g, (e, (((0, b), char), c)))(g, (e, (((0, b), char), d)))(g, (e, (((0, b), double), c)))(g, (e, (((0, b), double), d)))(g, (e, (((1, a), int), c)))(g, (e, (((1, a), int), d)))(g, (e, (((1, a), char), c)))(g, (e, (((1, a), char), d)))(g, (e, (((1, a), double), c)))(g, (e, (((1, a), double), d)))(g, (e, (((1, b), int), c)))(g, (e, (((1, b), int), d)))(g, (e, (((1, b), char), c)))(g, (e, (((1, b), char), d)))(g, (e, (((1, b), double), c)))(g, (e, (((1, b), double), d)))(g, (e, (((2, a), int), c)))(g, (e, (((2, a), int), d)))(g, (e, (((2, a), char), c)))(g, (e, (((2, a), char), d)))(g, (e, (((2, a), double), c)))(g, (e, (((2, a), double), d)))(g, (e, (((2, b), int), c)))(g, (e, (((2, b), int), d)))(g, (e, (((2, b), char), c)))(g, (e, (((2, b), char), d)))(g, (e, (((2, b), double), c)))(g, (e, (((2, b), double), d)))(g, (e, (((3, a), int), c)))(g, (e, (((3, a), int), d)))(g, (e, (((3, a), char), c)))(g, (e, (((3, a), char), d)))(g, (e, (((3, a), double), c)))(g, (e, (((3, a), double), d)))(g, (e, (((3, b), int), c)))(g, (e, (((3, b), int), d)))(g, (e, (((3, b), char), c)))(g, (e, (((3, b), char), d)))(g, (e, (((3, b), double), c)))(g, (e, (((3, b), double), d)))(g, (f, (((0, a), int), c)))(g, (f, (((0, a), int), d)))(g, (f, (((0, a), char), c)))(g, (f, (((0, a), char), d)))(g, (f, (((0, a), double), c)))(g, (f, (((0, a), double), d)))(g, (f, (((0, b), int), c)))(g, (f, (((0, b), int), d)))(g, (f, (((0, b), char), c)))(g, (f, (((0, b), char), d)))(g, (f, (((0, b), double), c)))(g, (f, (((0, b), double), d)))(g, (f, (((1, a), int), c)))(g, (f, (((1, a), int), d)))(g, (f, (((1, a), char), c)))(g, (f, (((1, a), char), d)))(g, (f, (((1, a), double), c)))(g, (f, (((1, a), double), d)))(g, (f, (((1, b), int), c)))(g, (f, (((1, b), int), d)))(g, (f, (((1, b), char), c)))(g, (f, (((1, b), char), d)))(g, (f, (((1, b), double), c)))(g, (f, (((1, b), double), d)))(g, (f, (((2, a), int), c)))(g, (f, (((2, a), int), d)))(g, (f, (((2, a), char), c)))(g, (f, (((2, a), char), d)))(g, (f, (((2, a), double), c)))(g, (f, (((2, a), double), d)))(g, (f, (((2, b), int), c)))(g, (f, (((2, b), int), d)))(g, (f, (((2, b), char), c)))(g, (f, (((2, b), char), d)))(g, (f, (((2, b), double), c)))(g, (f, (((2, b), double), d)))(g, (f, (((3, a), int), c)))(g, (f, (((3, a), int), d)))(g, (f, (((3, a), char), c)))(g, (f, (((3, a), char), d)))(g, (f, (((3, a), double), c)))(g, (f, (((3, a), double), d)))(g, (f, (((3, b), int), c)))(g, (f, (((3, b), int), d)))(g, (f, (((3, b), char), c)))(g, (f, (((3, b), char), d)))(g, (f, (((3, b), double), c)))(g, (f, (((3, b), double), d)))(h, (e, (((0, a), int), c)))(h, (e, (((0, a), int), d)))(h, (e, (((0, a), char), c)))(h, (e, (((0, a), char), d)))(h, (e, (((0, a), double), c)))(h, (e, (((0, a), double), d)))(h, (e, (((0, b), int), c)))(h, (e, (((0, b), int), d)))(h, (e, (((0, b), char), c)))(h, (e, (((0, b), char), d)))(h, (e, (((0, b), double), c)))(h, (e, (((0, b), double), d)))(h, (e, (((1, a), int), c)))(h, (e, (((1, a), int), d)))(h, (e, (((1, a), char), c)))(h, (e, (((1, a), char), d)))(h, (e, (((1, a), double), c)))(h, (e, (((1, a), double), d)))(h, (e, (((1, b), int), c)))(h, (e, (((1, b), int), d)))(h, (e, (((1, b), char), c)))(h, (e, (((1, b), char), d)))(h, (e, (((1, b), double), c)))(h, (e, (((1, b), double), d)))(h, (e, (((2, a), int), c)))(h, (e, (((2, a), int), d)))(h, (e, (((2, a), char), c)))(h, (e, (((2, a), char), d)))(h, (e, (((2, a), double), c)))(h, (e, (((2, a), double), d)))(h, (e, (((2, b), int), c)))(h, (e, (((2, b), int), d)))(h, (e, (((2, b), char), c)))(h, (e, (((2, b), char), d)))(h, (e, (((2, b), double), c)))(h, (e, (((2, b), double), d)))(h, (e, (((3, a), int), c)))(h, (e, (((3, a), int), d)))(h, (e, (((3, a), char), c)))(h, (e, (((3, a), char), d)))(h, (e, (((3, a), double), c)))(h, (e, (((3, a), double), d)))(h, (e, (((3, b), int), c)))(h, (e, (((3, b), int), d)))(h, (e, (((3, b), char), c)))(h, (e, (((3, b), char), d)))(h, (e, (((3, b), double), c)))(h, (e, (((3, b), double), d)))(h, (f, (((0, a), int), c)))(h, (f, (((0, a), int), d)))(h, (f, (((0, a), char), c)))(h, (f, (((0, a), char), d)))(h, (f, (((0, a), double), c)))(h, (f, (((0, a), double), d)))(h, (f, (((0, b), int), c)))(h, (f, (((0, b), int), d)))(h, (f, (((0, b), char), c)))(h, (f, (((0, b), char), d)))(h, (f, (((0, b), double), c)))(h, (f, (((0, b), double), d)))(h, (f, (((1, a), int), c)))(h, (f, (((1, a), int), d)))(h, (f, (((1, a), char), c)))(h, (f, (((1, a), char), d)))(h, (f, (((1, a), double), c)))(h, (f, (((1, a), double), d)))(h, (f, (((1, b), int), c)))(h, (f, (((1, b), int), d)))(h, (f, (((1, b), char), c)))(h, (f, (((1, b), char), d)))(h, (f, (((1, b), double), c)))(h, (f, (((1, b), double), d)))(h, (f, (((2, a), int), c)))(h, (f, (((2, a), int), d)))(h, (f, (((2, a), char), c)))(h, (f, (((2, a), char), d)))(h, (f, (((2, a), double), c)))(h, (f, (((2, a), double), d)))(h, (f, (((2, b), int), c)))(h, (f, (((2, b), int), d)))(h, (f, (((2, b), char), c)))(h, (f, (((2, b), char), d)))(h, (f, (((2, b), double), c)))(h, (f, (((2, b), double), d)))(h, (f, (((3, a), int), c)))(h, (f, (((3, a), int), d)))(h, (f, (((3, a), char), c)))(h, (f, (((3, a), char), d)))(h, (f, (((3, a), double), c)))(h, (f, (((3, a), double), d)))(h, (f, (((3, b), int), c)))(h, (f, (((3, b), int), d)))(h, (f, (((3, b), char), c)))(h, (f, (((3, b), char), d)))(h, (f, (((3, b), double), c)))(h, (f, (((3, b), double), d))) size(A2 X (A1 X (((V1 X V2) X V3) X V4))) = 192
 
User avatar
Cuchulainn
Posts: 59949
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

The ultimate Monte Carlo framework

October 10th, 2012, 8:46 pm

Possible alternative (CRTP patterns). Will come back with a full rant tomorrow on the various possible solutions.
Last edited by Cuchulainn on October 9th, 2012, 10:00 pm, edited 1 time in total.
 
User avatar
Cuchulainn
Posts: 59949
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

The ultimate Monte Carlo framework

October 11th, 2012, 3:31 pm

Milo,We tried to use MPL on MC 0.5 a while ago bit it fizzled out for some reason. Compile times are longer in general because classes are being generated. But 3 GB is a lot.Some rants, preferences, prejudices and questions:1. What is the compelling reason for using TMP instead of something else (objective reason).2. Has anyone done what you are doing using TMP? Why no white papers?3. What wrong's with good ole' OO factories to create objects?4. Pruning: reduce the number of permutations in choices and use a small 'db' of prototype objects.5. Is TMP in this context over-engineering/wrong paradigm? I think so.6. Hybrid: use TMP at the CRTP level?Conclusion: TMP is not the way in this context. An examples to prove or disprove this statement.
Last edited by Cuchulainn on October 10th, 2012, 10:00 pm, edited 1 time in total.
 
User avatar
MiloRambaldi
Posts: 273
Joined: July 26th, 2010, 12:27 am

The ultimate Monte Carlo framework

October 12th, 2012, 4:26 pm

QuoteOriginally posted by: CuchulainnPossible alternative (CRTP patterns). Will come back with a full rant tomorrow on the various possible solutions.I don't understand how this is a possible alternative, because I don't see anything being achieved by BLOCK II.
 
User avatar
MiloRambaldi
Posts: 273
Joined: July 26th, 2010, 12:27 am

The ultimate Monte Carlo framework

October 12th, 2012, 4:48 pm

QuoteOriginally posted by: CuchulainnMilo,We tried to use MPL on MC 0.5 a while ago bit it fizzled out for some reason. Compile times are longer in general because classes are being generated. But 3 GB is a lot.Some rants, preferences, prejudices and questions:1. What is the compelling reason for using TMP instead of something else (objective reason).I could not think of any other solution that does not put additional artificial constraints on the classes! Of course that doesn't mean I didn't overlook a simple solution.Quote2. Has anyone done what you are doing using TMP? Why no white papers?There is a very similar usage of TMP in boost/unit_test, when a given test is to be performed on a list of types, but this the trivial case where the types are not nested.Others are certainly doing similar things, though I have not seen this exact usage for type selection. For example, the library I mentioned was created to deal with nested mpl::for_each loops, which are presumably very common. I have not looked for white papers on the subject.Quote3. What wrong's with good ole' OO factories to create objects?Does this not require a common base class?Quote4. Pruning: reduce the number of permutations in choices and use a small 'db' of prototype objects.5. Is TMP in this context over-engineering/wrong paradigm? I think so.6. Hybrid: use TMP at the CRTP level?Hybrid sounds interesting, but I would need details or and example to understand what you mean.QuoteConclusion: TMP is not the way in this context. An examples to prove or disprove this statement.I'm still not convinced there is another way
 
User avatar
Cuchulainn
Posts: 59949
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

The ultimate Monte Carlo framework

October 12th, 2012, 5:14 pm

QuoteOriginally posted by: MiloRambaldiQuoteOriginally posted by: CuchulainnPossible alternative (CRTP patterns). Will come back with a full rant tomorrow on the various possible solutions.I don't understand how this is a possible alternative, because I don't see anything being achieved by BLOCK II.Why not? BTW CRTP is used in ATL and some Boost libraries (Statcharts, Units)..What about BLOCK I? QuoteI'm still not convinced there is another way Hard-coded at top level. Seems you are at the bleeding edge of TMP...
Last edited by Cuchulainn on October 11th, 2012, 10:00 pm, edited 1 time in total.
 
User avatar
Cuchulainn
Posts: 59949
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

The ultimate Monte Carlo framework

October 13th, 2012, 6:00 am

QuoteOriginally posted by: outrunMilo: Just look at e.g. random engine concept. It should provide amongst other things an operator() -i.e. it's conforming to an interface-. Then you write a function template or class template that works with all engine types (the template parameter) because it uses the operator() that all engine types provide. Simple, orthogonal, well defined.The cartesian idea sounds very wrong, *and* there is no need for a base class to implement a standard interface or concept either. Those ideas are unnecessary bloat / design freaking.Very ambitious IMO.This is a very general answer to a specific question. It's nice to have software wilh the above qualities and no one (especially developers ) will disagree. But _how_ to do it, really with whatever approach?I have not seen any papers/books/people on this so I doubt if it has been done/can be done.The problem to be solved is well-defined, so how can we do it? My thesis is that generics for Boost-type libraries do not scale to larger software systems. I would be be deligted to be proved wrong. Take a test case 101 and show the main steps, e.g. Mediator, FDM, SDE and RNG for starters.I agree on Cartesian approach, it's a sledge-hammer.
Last edited by Cuchulainn on October 12th, 2012, 10:00 pm, edited 1 time in total.
ABOUT WILMOTT

PW by JB

Wilmott.com has been "Serving the Quantitative Finance Community" since 2001. Continued...


Twitter LinkedIn Instagram

JOBS BOARD

JOBS BOARD

Looking for a quant job, risk, algo trading,...? Browse jobs here...


GZIP: On