Page 15 of 18

### The ultimate Monte Carlo framework

Posted: October 19th, 2012, 6:00 pm
QuoteOriginally posted by: MiloRambaldiQuoteOriginally posted by: CuchulainnI have not seen any papers/books/people on this so I doubt if it has been done/can be done.QuoteAnd I suspect no one has done at the level Milo is at.I would be very surprised that this has not been done, because it seems like such a standard design issue.It would also be very surprising if I have exceeded everyone else here, since I am still a beginner at TMP.However, if my solution (I do believe I have one) really is original then perhaps a paper should be written ...The design is well-known (e.g. C#, Java, COM) _but_ not in C++ and TMP AFAIK. The question is why...

### The ultimate Monte Carlo framework

Posted: October 19th, 2012, 6:19 pm
What about ~dependency injection in JavaI have been told that this is very powerful. Ugh, factories aren't fun DI in C++

### The ultimate Monte Carlo framework

Posted: October 22nd, 2012, 12:57 am
Attached is some explicit code illustrating what I have in mind as our "Dynamic Configuration Problem". The immediate problem as I see it, is the necessity of handling a very large collection of types. In my simple toy example, there are just 3 x 3 x 2 = 18 types, corresponding to the case where the builder pattern chooses a triple of types from three families of types, A, B and C where A and B have 3 types each and C has 2 types. But in practice there would likely be several thousand types. The goal in this code is to perform a simple task for each of the 18 triples in the cartesian product of types A x B x C. Three methods to achieve this are compared in the code. I have just attached the main .cpp, but the source tree can be obtained from svn and compiled. The output is also attached below.(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.(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.)(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... QuoteOriginally posted by: CuchulainnThe design is well-known (e.g. C#, Java, COM) _but_ not in C++ and TMP AFAIK. The question is why...I would be very interested to see an example in C#. I'm currently reading about reflection in C#. If this gives an alternative solution in C#, then it seems likely it would also be applicable to C++ using the library Polter mentioned.C:\...\Visual Studio 2010\Projects\QFCL\bin\examples\Release>cartesian_product_simple_example.exe

### The ultimate Monte Carlo framework

Posted: October 22nd, 2012, 6:30 am
QuoteSo it's not a specific dynamic (run time) issue.Yes it is IMO. I don't think TMP is the way to go. The Cartesian product approach can generate solutions that are semantically incorrect e.g. a Crank Nicolson with a nonlinear SDE does not work. So, the solution space should be pruned.QuoteWhy 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. That's because you don't use patterns! This is the way C# and Java developers implement systems. Dynamic Injection is the way to go IMO. Until now Milo's solution is the only one to date. It does work but it may not be the final word. And doing TMP in a vacuum approach is not good; you need a concrete test case.My claim (again) is that C++ has reached its limits here. As mentioned earlier, this claim can be refuted by a _working_ counterexample. Can you do that?

### The ultimate Monte Carlo framework

Posted: October 22nd, 2012, 6:51 am
Quote1) "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.I don't think MPL will help improve. You mention long compile time (bad for production environments) and lots of GB memory.And for MO/FO developers who wish to do what-if scenarios the solution will be too inflexible IMO.Quote(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.)"Get it working, then get it right, then get it optimised".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... It's inelegant, but it works. I would say that's the feeling of many FO quants. We can always make it bootiful, later.QuoteI would be very interested to see an example in C#. I'm currently reading about reflection in C#. We use 1) Builder and interfaces 2) Reflectipn to actuallly generate (emit) code. For example, C# generics cannot handle +, * so I use both Reflection and dynamic keywodrd to generate what I need. It's in the forthcoming Germani/Duffy book.My hunch is DI in C# is the way to go.

### The ultimate Monte Carlo framework

Posted: October 22nd, 2012, 7:04 am
QuoteOriginally posted by: outrunIt an orthogonal discussion. Do you want to encode the "dont' use CN with non lin SDE" in e.g. a trait? And what if a users wants to use that anyway?Best seems to be to use a trait class that can be used in TMP.The way I did it in the is a hierarchy of SDEs and a hierarchy of Visitiors. So call CN visit() on CEV SDE ==> throw exception and a dialog text "CN N/A on SDE".Quote*however* it's a nice problem for a book on C++ design issues, but not relevant for a MC framework. Let the uses pick *any* of the 3 methods, keep it outside.Of course. But we use MC to keep focused. Later, it can used in PDE. etc. again and again. That's the whole point.It is a good problem, but it is an open, hard problem. Must production code becomes messy at config level.

### The ultimate Monte Carlo framework

Posted: October 22nd, 2012, 7:15 am
QuoteIt is easy to implement, but very inelegant, goes against the design goals and will cause performance degradationStupid question: has anyone _explicitly_ stated what goals/requirements are?Quote..I'm going to leave it at this, it's a difference in the goal... In s/w, each stakeholder has his own (internalised) mental model, unknown to the others.BTW here is an example of code generation in C#.//I agree, BLOCK II is not relevant to current case. Thinking aloud, Milo: Boost::any type useful?

### The ultimate Monte Carlo framework

Posted: October 22nd, 2012, 8:19 am
Here is C# to show how to create code. For this project you could use C++/CLI (.NET!) to generate C++/CLI code that works with native C++.My feeling is to have a dictionary of types, choose the one you want, generate code, and build.

### The ultimate Monte Carlo framework

Posted: October 22nd, 2012, 9:31 am
One important requirement is cutting down on compile time, especially if in prime time. It if take 20 minutes, that's very long.

### The ultimate Monte Carlo framework

Posted: October 22nd, 2012, 9:41 am
QuoteOriginally 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.