SERVING THE QUANTITATIVE FINANCE COMMUNITY

  • 1
  • 2
  • 3
  • 4
  • 5
  • 18
 
User avatar
Cuchulainn
Posts: 59714
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

The ultimate Monte Carlo framework

November 17th, 2011, 12:59 pm

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.
 
User avatar
Cuchulainn
Posts: 59714
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

The ultimate Monte Carlo framework

November 17th, 2011, 1:07 pm

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.
Last edited by Cuchulainn on November 16th, 2011, 11:00 pm, edited 1 time in total.
 
User avatar
Cuchulainn
Posts: 59714
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

The ultimate Monte Carlo framework

November 17th, 2011, 1:35 pm

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?
Last edited by Cuchulainn on November 16th, 2011, 11:00 pm, edited 1 time in total.
 
User avatar
Cuchulainn
Posts: 59714
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

The ultimate Monte Carlo framework

November 17th, 2011, 2:00 pm

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).
Last edited by Cuchulainn on November 16th, 2011, 11:00 pm, edited 1 time in total.
 
User avatar
demha
Posts: 182
Joined: January 27th, 2011, 8:01 pm

The ultimate Monte Carlo framework

November 17th, 2011, 5:55 pm

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.
 
User avatar
Traden4Alpha
Posts: 23951
Joined: September 20th, 2002, 8:30 pm

The ultimate Monte Carlo framework

November 17th, 2011, 8:17 pm

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).
 
User avatar
Cuchulainn
Posts: 59714
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

The ultimate Monte Carlo framework

November 18th, 2011, 6:10 am

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.
Last edited by Cuchulainn on November 17th, 2011, 11:00 pm, edited 1 time in total.
 
User avatar
Cuchulainn
Posts: 59714
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

The ultimate Monte Carlo framework

November 22nd, 2011, 6:41 am

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.
Last edited by Cuchulainn on November 21st, 2011, 11:00 pm, edited 1 time in total.
 
User avatar
Cuchulainn
Posts: 59714
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

The ultimate Monte Carlo framework

November 22nd, 2011, 2:16 pm

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.
Last edited by Cuchulainn on November 21st, 2011, 11: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