Serving the Quantitative Finance Community

  • 1
  • 3
  • 4
  • 5
  • 6
  • 7
  • 18
 
User avatar
Polter
Posts: 1
Joined: April 29th, 2008, 4:55 pm

The ultimate Monte Carlo framework

December 17th, 2011, 11:55 am

Cuch, thanks for attaching the code! Can I ask you a couple of clarification-questions?How do you do polymorphism on contract-type (e.g. Option) and contract-subtype(s) (e.g. European-Option, European-Option/Call)?Basically switching the namespace(s)? If so, which one(s) and how? Is there some kind of planned hierarchy?That is, is what is currently named "TypeD" intended to stand for EuropeanOption::Call namespace or EuropeanOption_Call namespace?(or even Option::European::Call, etc.)?Do you think you could attach an example?// BTW: remember to change "long" to memsize-type like "std::size_t" or "std::ptrdiff_t" whenever appropriate!For illustration, I attach the parts of the code I'm talking about and the (stripped to bare bones) use case:
Last edited by Polter on December 16th, 2011, 11: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

December 18th, 2011, 9:28 am

Polter,Thanks for the feedback. The questions have to do with the configuration and initialisation of the objects in the class hierarchy. e.g. Payoffs, SDE, FDM and so on. It is a general concern and some of the solution I used in V0.72 were:1. Namespaces (e.g. TypeD)2. Hard-coded switches (e.g. Call and Put payoff, RNG)3. Boost function to increase flexibility (see Payoff member).(4. Traditional OO class hierarchies)5. Generic parameters, e.g. Config<T1, T2, ..., int Choice> Choice == 1 ==> Euler etc.So, in the current version a number of things are hard-coded. It is not a problem to more it more generic, but what is the 'best' approach in this case?Some kind of Factory is useful; one nice option is Boost Functional Factory that keeps down class population bloat. Maybe we can agree on some standard as these issues crop up time and time again.P.S. will use size_t in future
Last edited by Cuchulainn on December 17th, 2011, 11: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

December 18th, 2011, 9:28 am

(double, for some strange reason it posts twice???)
Last edited by Cuchulainn on December 17th, 2011, 11: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

December 18th, 2011, 9:45 am

QuoteOriginally posted by: outrunGreat delivery!So how do we proceed? I think you'll need to give it a name and (sub)brand, and move it into the sandbox for review?Thanks.I think we have something that works and it is a foundation. Some scenarios could be:1. I incorporate features based on feedback2. People can add/modify code3. Standardisation of names + interfaces.One sub-project would be to have MC for n-factor SDEs. I have a generic version using my own matrices and function pointers but I think uBLAS (and boost::array) and Boost function would more standardised. And introducing jump models.I think the code can be put into the sandbox?
 
User avatar
Cuchulainn
Posts: 20254
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

The ultimate Monte Carlo framework

December 18th, 2011, 9:45 am

(double)
Last edited by Cuchulainn on December 17th, 2011, 11:00 pm, edited 1 time in total.
 
User avatar
taden
Posts: 0
Joined: January 18th, 2010, 12:52 pm

The ultimate Monte Carlo framework

December 21st, 2011, 7:57 pm

Cuch, thank you for the code!I have a couple of questions about qfcl and the MC code.1) Is qfcl going to be tested against multiple compilers? It would be interesting to include gcc and msvc in the tests. (I have attempted to compile the MC code with gcc and I am struggling a bit particularly with -std=c++11. All well with msvc10.)2) Would using boost.signals2 be a requirement to make the MC code thread-safe?Thanks
 
User avatar
Cuchulainn
Posts: 20254
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

The ultimate Monte Carlo framework

December 21st, 2011, 8:34 pm

Hi Taden,Thanks for the feedback:1) Is qfcl going to be tested against multiple compilers? It would be interesting to include gcc and msvc in the tests. (I have attempted to compile the MC code with gcc and I am struggling a bit particularly with -std=c++11. All well with msvc10.)DD good idea and it is necessary. We need people to help indeed. Code must be portable. BTW C++ 11 was a fancy touch in MCPostProcess but it can be replaced by STL algos.If we do a lot of Boost then we piggyback, so portability is free?2) Would using boost.signals2 be a requirement to make the MC code thread-safe?DD We should do signal2 by default. In MC 101 I did not want to get too fancy just yet. BTW I have n-factor MC waiting in the wings but I suggest hammering and squeezing (like the above posed questions) MC 101 until nothing is left to test and then move up to the next level. What do you think?
Last edited by Cuchulainn on December 20th, 2011, 11:00 pm, edited 1 time in total.
 
User avatar
Polter
Posts: 1
Joined: April 29th, 2008, 4:55 pm

The ultimate Monte Carlo framework

December 21st, 2011, 10:23 pm

Cuch, I actually like the std::accumulate version better in any case -- it expresses the intent more clearly.Performance benefits could convince me for the std::for_each with C++11 lambda solution, but I don't see how it could be faster?If anything, syntax-wise, Boost.Range (2.0) looks more user-friendly:http://www.boost.org/doc/libs/release/l ... mlalthough it's also not faster, and in one complex case it turned out to be slower than the alternative:http://stackoverflow.com/questions/3204 ... ts-in-aI'd also prefer identity_element of plus functor instead of hard-coded 0.0, like the one in STL:http://www.sgi.com/tech/stl/MonoidOpera ... tion.hsome examples:http://stlab.adobe.com/identity__elemen ... ts.htmlI'm actually a bit surprised that identity_element isn't in C++11 standard, remember there was a couple of STL elements that got there (like iota), apparently it wasn't one of them.Also a bit strange that it's only in the Boost.ICL (and, I think, Boost.Graph), not on a more general level.If anything, I suppose we can always ship ours, perhaps w/ some simpler wrapper around Boost.Range's accumulate with init=identity_element by default (just call it qfcl::sum) -- if there's a need.Then, we can just write:double sum = qfcl::sum(arr);
Last edited by Polter on December 20th, 2011, 11: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

December 22nd, 2011, 10:05 am

Quote* a clear separation between algorithms and containers, also ensure that work with STL containers* provide a generic interface to users, preferable don't force (but allow for) non standard element on it's use when it's not neededYes, I agree. It is however a bit abstract at the moment. But how to achieve this goal is the issue. The goals need to be realised by a process (e.g. cook book) We need to see users of libraries and library creators. They have different viewpoints.I like the incremental approach of continuous improvement and feature enhancement that software development teams use a lot. QuoteIt's probably better to start *working* on code instead of just commenting on Cuch's code. We should segment the code into stand-alone units (algorithms) that have generic value, I think people are waiting on someone to give the lead by producing running code and documentation. That is what I have tried to do.Well, we can both. I welcome people extending the code as well. The advantage of code review is that it can be run (better than pseudocode). In this was it is easier to give feedback. I don't know any other way.The point abouit MC 101 is not only the code but it is also a defined process and design for many kinds of applications. Again, it will result in a flexible framework. I would let people respond as they feel to be best.If we wish to promote the 'generic way' then some issues need to be adddress in a scientific way:1. Not everyone is acquainted with the GP paradigm.2. It is part of a bigger picture in which other paradigms are used3. Useful for libaries, but quants do not think like this AFAIK. 4. It is a bottom-up approach and kind of ad-hoc discovery of generic interfaces5. Software architecture is missing.These are the pros and cons I see. To make things clear, the project needs a generic library asap showing how to deliver the desired functionality. Something like a mission statement document. Maybe the implementation of Alan's PostProcessing Error Analysis. I think issues 1-4 need to be addressed once and for all now as otherwise we will be discussing design intent 6 months down the line.QuoteI haven't seen the code yet! and we can also have multi design versions with different pros con's)Maybe it's an idea to peruse the code and post suggestions for improvement. Even a new design is fine. QuoteI have however very limited time at the moment [...] Fair enough. What kinds of generic libraries would people like to see? Quotewe can add choices like Polter mentioned but leave the choice to the user instead of part of the design.Polter gave very good feedback. I will incorporate it in next round.
Last edited by Cuchulainn on December 21st, 2011, 11: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

December 22nd, 2011, 1:23 pm

Hi Thijs,I think what will happen is that a kind of 'qfcl software culture' will evolve that is acceptable to everyone. For me, user feedback will be one of the drivers since writing usable software is essential. There are many roads to Rome Regarding MC 101 it is non-monolithic because each module is self-contained and replaceable. A good project would be to take its design and then port it to a Boost-like implementation. Anyone interested in having a go at this choice?
Last edited by Cuchulainn on December 21st, 2011, 11: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

December 24th, 2011, 12:09 pm

QuoteOriginally posted by: PolterI'd also prefer identity_element of plus functor instead of hard-coded 0.0, like the one in STL:http://www.sgi.com/tech/stl/MonoidOpera ... tion.hsome examples:http://stlab.adobe.com/identity__elemen ... ts.htmlI'm actually a bit surprised that identity_element isn't in C++11 standard, remember there was a couple of STL elements that got there (like iota), apparently it wasn't one of them.Also a bit strange that it's only in the Boost.ICL (and, I think, Boost.Graph), not on a more general level.If anything, I suppose we can always ship ours, perhaps w/ some simpler wrapper around Boost.Range's accumulate with init=identity_element by default (just call it qfcl::sum) -- if there's a need.Then, we can just write:double sum = qfcl::sum(arr);Indeed.In a sense, many of the libraries do not fully implement the mathematical structures for groupoids, semigroups, rings, field etc. Now users have to initialise to 0.0 (does it work serendipitously for complex<T>?).I have not seen [0,0] and [1,1] as zero and identity elements in Boost Interval. uBLAS does support zero and identity vectors and matrices.Incorporating this would make client code more robust and reliable. edit: Ideally Boost Rational should implement a field so it should have canonical zero and identity elements.
Last edited by Cuchulainn on December 23rd, 2011, 11:00 pm, edited 1 time in total.
 
User avatar
FinancialAlex
Posts: 1
Joined: April 11th, 2005, 10:34 pm

The ultimate Monte Carlo framework

January 4th, 2012, 1:18 am

Thijs,Please find attached a relatively simple MC framework largely inspired by Mark Joshi's Design Patterns book (in recognition, his name is mentioned in various files). It is definitely a work in progress: for example, Greeks are not yet integrated in the framework. Having a well-thought addition of Monte Carlo Greeks within the framework will be very useful. The main solution is in the folder with "Console" in name and was compiled under Visual Studio 2010
Attachments
Monte Carlo framework.zip
(84.42 KiB) Downloaded 98 times
Last edited by FinancialAlex on January 3rd, 2012, 11:00 pm, edited 1 time in total.