SERVING THE QUANTITATIVE FINANCE COMMUNITY

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

Modern & Effective C++ design ideas

May 20th, 2014, 6:12 pm

Quotewe might have two type of FDM solvers, one for american and one for european style contracts. This could also be accomplished with traits (and perhaps it will), but this seems natural right nowIt depends, maybe yes, maybe no.Thinking of PDE and FDM in this way is not easy to analyse without an executable POC (e.g. like the PRNG I was able to use!)
 
User avatar
Cuchulainn
Posts: 59014
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

Modern & Effective C++ design ideas

May 20th, 2014, 6:43 pm

Quote*Somewhere* we need to capture the difference between and American option and a European one, at the end of the pipeline a different price will be printed, right? Difference can be large or small:Small; PDE with constraint at each time level;Large/Huge: PDE/FDM for European, PVI/FEM for American. For this reason i"n a variable like "bool is_american;" " is too naive.A component/OO approach is possibly the only way, and it been done before by quite a few quants.
Last edited by Cuchulainn on May 19th, 2014, 10:00 pm, edited 1 time in total.
 
User avatar
Cuchulainn
Posts: 59014
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

Modern & Effective C++ design ideas

May 21st, 2014, 4:18 am

QuoteOriginally posted by: outrunQuoteOriginally posted by: CuchulainnQuote*Somewhere* we need to capture the difference between and American option and a European one, at the end of the pipeline a different price will be printed, right? Difference can be large or small:Small; PDE with constraint at each time level;Large/Huge: PDE/FDM for European, PVI/FEM for American. For this reason i"n a variable like "bool is_american;" " is too naive.A component/OO approach is possibly the only way, and it been done before by quite a few quants.There are solvers like the 4 you mention and those are different parts of the design. There are many more and that's why it's essential to place information where is should. American or European is a instrument property, and different types of contracts need different types of solvers. The applicability of certain solvers for certain types of contract depends on those traits. You can typically use more solvers for European contracts than with American contracts. OO is from the pre STL era (STL is not OO), and it will give you a QL. Rational discussions about design -where choices are *motivated*- will not result in an OO design.STL is a good C++ library. But that's as far as it goes, design-wise.I look forward to seeing a working POC. Do you have working code? This is the _only_ way forward to let people see how it works. Personally, I really don's see how the STL concept can be applied to a mathematically complex topic such as PDE/FDM.
Last edited by Cuchulainn on May 20th, 2014, 10:00 pm, edited 1 time in total.
 
User avatar
Cuchulainn
Posts: 59014
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

Modern & Effective C++ design ideas

May 21st, 2014, 4:41 am

QuoteOriginally posted by: outrunAs far as *what* goes? 2001 and STL marked the beginning of moderns C++ and the end of OO. It's really much better, you need to but read those old & classic books so that we can have rational instead of emotional discussions.I agree, so come up with a working prototype What can be easier? Just do it.
Last edited by Cuchulainn on May 20th, 2014, 10:00 pm, edited 1 time in total.
 
User avatar
Cuchulainn
Posts: 59014
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

Modern & Effective C++ design ideas

May 21st, 2014, 9:32 am

QuoteOriginally posted by: outrunQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: outrunAs far as *what* goes? 2001 and STL marked the beginning of moderns C++ and the end of OO. It's really much better, you need to but read those old & classic books so that we can have rational instead of emotional discussions.I agree, so come up with a working prototype What can be easier? Just do it.Indeed thats the goal. It takes some time to get things right, hence the posting of snippets here whenever I feel I have given it enough thought. However, some poeple can have good rational design discussions *before* they have code. Eg you respond with dogma's instead of discussing the actual design argument I posted.Personally, I find it hard to comment on paper models. It takes too long to think about what the design intent is. But a design PLUS a working C++ prototype is ideal.Paper models don't crash.I liked your PRNG code that I was able to integrate in a dll. Can you do something similar here as well? Even a 101 case with each trait visible? Hopefully, these remarks don't come across as being dogmatic.
Last edited by Cuchulainn on May 20th, 2014, 10:00 pm, edited 1 time in total.
 
User avatar
Cuchulainn
Posts: 59014
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

Modern & Effective C++ design ideas

May 22nd, 2014, 7:34 am

One recurring issue in software development is that progammers tend to start designing a _solution_ before agreement on what the _problem_ is (70% of software projects fail for this reason).For 1-factor early-exercise PDE and various this is a good specification. Then we are signing from the same sheet. And the problem becomes scoped and unambiguous. And the fixed price is 20K.Next Specification ----> Design (and how!)
Last edited by Cuchulainn on May 21st, 2014, 10:00 pm, edited 1 time in total.
 
User avatar
Cuchulainn
Posts: 59014
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

Modern & Effective C++ design ideas

May 22nd, 2014, 8:33 am

QuoteOriginally posted by: outrunIndeed, first a scope and requirements. My toy project is to try and make it very wide (all QF models, [analytical, MC, PDE], multi-factor, exotic options,single instruments, full portfolios, pricing, VaR) and see if that leads to a scalable design.This would be huge project.Would you see 1-factor as a special case of n-factor? e.g. modelling (S1,...Sn) as std::array<T,n>. The magic number 7 _is_ the problem. that the number of objects an average human can hold in working memory is 7 ± 2. This is frequently referred to as Miller's Law.
Last edited by Cuchulainn on May 21st, 2014, 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