Awesome outrun,However, shouldn't we first polish some aspects rgd code contributions, dev-style, etc before even beggining? I don't mean to be a party spoiler ( especially since I helped starting the party myself ) and I am not suggesting being as paranoid about code contributions as our Boost friends or even IEEE ( not saying this lightly, last time we tried, I took our team 4 years to have them commenting, reviewing and finally publishing some of our work) but at least a minimal set of guidelines rgd accomp test-suite, make files and project files for key IDEs, documentation, at the code-level, a complement of what we already compiled at the high-level for project MT purposes. Btw this is just a suggestion to our PMs.Serp

I find it great to collect many of such tiny issues before starting the endeavour. A project that is not deadline driven has this good advantage that ruminations can - atleast to a larger extent - prevent dead ends and legacy code. Honestly I dont find it so bad being even more paranoid than boost and IEEE guys, otherwise we end up again with yet more numerically unstable code and a random engine ill suited for parallel and quasi MC (any reference to real facts and situations is purely intentional). That is: I agree with both outrun and SJ in that we should discuss all possible aspects first, as to put all cards on the table (is this even english?). Otherwise the whole thing would "just" be QuantLib 2.0 (without prejudice on the quality of QL). On a side note, I've stumbled in the last weeks over countless dead open source quantfin projects even from respectable teams, and the risk is significant, therefore it might be also useful preventing enthusiasms from forming yet another bubble.(if this all starts well, then I might consider providing some qmc code too).

QuoteOn a side note, I've stumbled in the last weeks over countless dead open source quantfin projects even from respectable teams, and the risk is significant, therefore it might be also useful preventing enthusiasms from forming yet another bubble.(if this all starts well, then I might consider providing some qmc code too).Good point.No offence meant, but many projects/libs need to apply a number of techniques from enginneering/industrial projects. We need some of them here. They are not difficult, but clinging to the old ways will *NOT* work.How many projects have?docsArchitects and designersA product development planSource code reviewThat's why they fail. Some adaptation is needed imo.

QuoteI'm cleaning up old code, e.g. probability distribution code, and Black & Scholes code (as an example for this discussion)Speaking of Math Toolkit, I have already 4 chapters + code + examples all written up.So the learning curve is fine. BTW Boosts for Maths Toolkit are extensive, as you know

Going back to the original question: double p = cdf( normal(0.0, 3.0), 0.30); is also the way that C++11 does it, so you'll probably want to have it. The flat interface is simpler, though. I'd keep both.

Will there be support for the following programming styles that will inevitably arise:1. Using tuples and structs of data (standardised by someone here?) . I think that QL has quite a few. Advantage of structs is they can be used with factories.2. Prototypes for the entities in 1 (like the GUI buttons you can customise in tool boxes)3. Named parameters in Boost ensure that users don't give arguments in the wrong orderI would like to add your palette of standardised structs in my FDM framework. This is good for the qualty on all counts. No copy and paste. The major follow-on question is: "What are the various programming styles (C++, C, C#, OOP, GP) your s/w should interop with". Some interviewing is needed. Anyway, I know someone in PDE/FDM who want to talks to you because he wants to kniow if he should STOP typing the exact formulae to check against FDM values. And someone in C# and Matlab.//Regarding the code, what is the rationale. An extra option is to use CRTP that does preserve polymorphism but it uses static_cast so it is fast.

QuoteHow many projects have?docsArchitects and designersA product development planSource code reviewThat's why they fail. Some adaptation is needed imo.Good that you remind this Cuch! Despite QuantLib's code quality the lack of documentation was a major drawback for a significant portion of potential users, and developers too.I fear the biggest problems will be with architecture though... One might also devise an open-source variant of Brooks' surgical team.