Page 3 of 18

The ultimate Monte Carlo framework

Posted: November 17th, 2011, 12:59 pm
by Cuchulainn
Quotestruct WhyWhySignals{void operator()() cosnt{T:);}};WhyWhySignals<HelloWorld>(); hahaha, this won't compile, but you get the idea!It probably will with template template parameters.

The ultimate Monte Carlo framework

Posted: November 17th, 2011, 1:07 pm
by Cuchulainn
QuoteOriginally posted by: outrunQuoteOriginally posted by: CuchulainnQuoteIs there a need for using signals over a simple template with an agreed interface?Absolutely!With signals you can configure the engine to suit any user needs. I have written an article November Wilmott 2011 on this very topic by creating a BS pricer that gets it data from a slot.In general, I know how to design these loosely coupled systems using signals. Robert and myself have even mapped GOF and POSA patterns to signals, e.g. Observer.so your talking about run-time configuration. For data feeds that makes sense. For a MC engine I'm not sure? Do you attach the payoff function to the BS pricer as well?Software development for our team has become almost like a real discipline in the last few weeks. An epiphany. If I were to do Alan's Brownian Bridge hit I would do it exactly the same. All you need to know is the I/O and find someone who knows the algo. For V2 of FDM framework I will have signals as default.

The ultimate Monte Carlo framework

Posted: November 17th, 2011, 1:35 pm
by Cuchulainn
QuoteOriginally posted by: outrunTo me this looks like *user* code -using specifics elements like boost function, signals etc- instead of generic library code.I'm used to more dogmatic coding approach of generic libraries. Define interfaces, algorithms, it's indeed a complicated set of styles people prefer.Fair enough. I am not building libraries, but configurable frameworks. It's like being an application developer, a different kind of software product. We use libraries. Bit like the NAG approach.Quoteit's indeed a complicated set of styles people preferDid you solicit feedback from users (not library builders) on their preferences?

The ultimate Monte Carlo framework

Posted: November 17th, 2011, 2:00 pm
by Cuchulainn
QuoteOriginally posted by: outrunQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: outrunTo me this looks like *user* code -using specifics elements like boost function, signals etc- instead of generic library code.I'm used to more dogmatic coding approach of generic libraries. Define interfaces, algorithms, it's indeed a complicated set of styles people prefer.Fair enough. I am not building libraries, but configurable frameworks. It's like being an application developer, a different kind of software product. We use libraries.yes. so we need to segment the code into a "applications" part when frameworks and tool reside, and a set of generic libraries that contain algorithms etcSure. Like boost. Libraries are application-independent.The higher order algorithmics (e.g. FDM) reside in the framework. We still need interaction on how to design MC engines. (eventually they will need GUI and DB).

The ultimate Monte Carlo framework

Posted: November 17th, 2011, 5:55 pm
by demha
QuoteOriginally posted by: CuchulainnSoftware development for our team has become almost like a real discipline in the last few weeks. An epiphany. If I were to do Alan's Brownian Bridge hit I would do it exactly the same. All you need to know is the I/O and find someone who knows the algo. This sounds a lot like flow based programming (FBP) and Paul Morrison has written a couple of books on this subject. Apparently, Paul has been doing this since the 1950s and is being "rediscovered" lately.

The ultimate Monte Carlo framework

Posted: November 17th, 2011, 8:17 pm
by Traden4Alpha
It would seem that the guts of the engine would include:* Sample generators (RNGs, weighted sampling, antithetic sampling, low-discrepancy, etc.)* Sample functions (converts a "random number" to an application-specific quantity)* Path constructors (constructs an event path as a sum of function-mapped samples, including path-dependencies)* Event aggregators (aggregates across samples or paths to compute MC statistics, MC-based solution estimates, and MC quality estimates)* MC run managers (spawns/handles multiple MC runs such as with different application parameter values or MC control parameter values)On top of this would be an application layer that maps a user's domain application to a configuration of the MC engine components (e.g., defining sample generator, path constructor, event aggregator, etc.). The application layer could/should intermediate between a "friendly" interface on to MC and the more complex hardware-specific internals (e.g. SIMD/GPU details).

The ultimate Monte Carlo framework

Posted: November 18th, 2011, 6:10 am
by Cuchulainn
QuoteOriginally posted by: demhaQuoteOriginally posted by: CuchulainnSoftware development for our team has become almost like a real discipline in the last few weeks. An epiphany. If I were to do Alan's Brownian Bridge hit I would do it exactly the same. All you need to know is the I/O and find someone who knows the algo. This sounds a lot like flow based programming (FBP) and Paul Morrison has written a couple of books on this subject. Apparently, Paul has been doing this since the 1950s and is being "rediscovered" lately.Indeed. I think this is the same as Data Flow Diagrams in Yourdon's SA approach. I use them in my domain archictecture reference models to help decompose (and understand!) a system before implementing it. I am using them for the MC engines. On a related note, using state machines to model systems can also add to the understandability and reliability of software systems.DFDs got lost in action when OOP became popular; DFDs were considered to be non-OO. Nowadays, parallel programs use them (e.g. see Microsoft PPL). At C++ level, Boost signals help me implement data transfer between components.Another one waiting to be 'found' again is Module Interconnection Language (MIL), especially if we want as little coupling as possible.In general, using as many paradigms as possible helps us tame the s/w beast imo.

The ultimate Monte Carlo framework

Posted: November 22nd, 2011, 6:41 am
by Cuchulainn
QuoteOriginally posted by: Traden4AlphaIt would seem that the guts of the engine would include:* Sample generators (RNGs, weighted sampling, antithetic sampling, low-discrepancy, etc.)* Sample functions (converts a "random number" to an application-specific quantity)* Path constructors (constructs an event path as a sum of function-mapped samples, including path-dependencies)* Event aggregators (aggregates across samples or paths to compute MC statistics, MC-based solution estimates, and MC quality estimates)* MC run managers (spawns/handles multiple MC runs such as with different application parameter values or MC control parameter values)On top of this would be an application layer that maps a user's domain application to a configuration of the MC engine components (e.g., defining sample generator, path constructor, event aggregator, etc.). The application layer could/should intermediate between a "friendly" interface on to MC and the more complex hardware-specific internals (e.g. SIMD/GPU details).Talking a data/task view, I see 3 'levels': 1) market/calibrated data and models 2) Simulated data (e.g. paths) and 3) MIS, high-level data and high-scenarios. These can be separately designed and they lead to parallel task and data decomposition. The above list of subtasks will be in one of the 3 parent tasks.Important in the engine are efficiency (very fast), functionality (what kinds of SDEs to support), maintainabiliy (add plug ins, narrow interfaces between components.).What do you think?BTW we do not yet have a feature/requirements list.

The ultimate Monte Carlo framework

Posted: November 22nd, 2011, 2:16 pm
by Cuchulainn
QuoteOriginally posted by: outrunRequirements is indeed tough:I have a Monte Carlo parameter search algorithm that maximized likelihood. I absolutely can't image any framework to help me with that: it's all too specific. One thing I can think of for "requirements" is efficient and easy access to low level routines (make it user-friendly and usable on both high and low levels). Generics thing I wrote myself are multivariate Gaussian sampling and PDF evaluation, and simulated anealing (in a very crude way)This is an application that uses MC to solve a certain problem. I suppose there will be many applications that do not fall into any category.A common situation here is n-factor option pricing using SDEs and numerical methods. For this I do think (and am reasonably sure) that an adaptable framework can be defined, and I have done a POC already. An examplle is how QL does it and Matlab's SDE package. It's somewher to start.