• C++ Programming for Financial Engineering
    Highly recommended by thousands of MFE students. Covers essential C++ topics with applications to financial engineering. Learn more Join!
    Python for Finance with Intro to Data Science
    Gain practical understanding of Python to read, understand, and write professional Python code for your first day on the job. Learn more Join!
    An Intuition-Based Options Primer for FE
    Ideal for entry level positions interviews and graduate studies, specializing in options trading arbitrage and options valuation models. Learn more Join!

Poll: for how much would you buy a book on "Getting Started with QuantLib"?

For how much would you buy a book on "Getting Started with QuantLib"?

  • For at most $10

    Votes: 18 30.0%

  • For at most $20

    Votes: 5 8.3%

  • For at most $30

    Votes: 5 8.3%

  • For at most $50

    Votes: 4 6.7%

  • I would also pay $100 if the book is really good

    Votes: 1 1.7%

  • I would not buy in any case

    Votes: 15 25.0%

  • What is QuantLib?!

    Votes: 12 20.0%
  • Total voters
    60
how many of yours have bought Luigi's book

My 2 cents,
I gave a talk at QL 2016 so my views are well-known.

Seriously, my question to the QL community; what are the plans? IMO it is based on C++03 and 90's design which is fine, but I see challenges for QL as a software product.

1. C++11 >> C++03
2. Modern hybrid design (top-down bottom-up; OOP. lambda functions!)
3. Too much class hierarchies, there are other solutions
4. I think it will be almost impossible to parallelise the code.
5. Parallel design patterns; GOF patterns are a wee bit passé.
6. The average quant does not know enough software design to use Ql. For sure. And don't say quants will pick it up quickly; believe me, you understand patterns only after the 2nd "throwedaway" prototype.

As owner, I would build a new QL from the ground up, at this stage. Keep the algos and strip away the patterns and replace by the new functional paradigm.
But my views are irrelevant.


Some of my posts on QL.

Using Quantlib - wilmott.com
 
Last edited:
quote-the-management-question-therefore-is-not-whether-to-build-a-pilot-system-and-throw-it-away-you-fred-brooks-213577.jpg
 
As to 1) & 2), Luigi addressed them in his QLUM 2017 talk.
Short summary: QuantLib will evolve but using modern technologies is not a goal per se.
Finally, backward compatibility is essential (an it is there!). At least because in [big] financial institution quants cannot use what they want: they have to use what is conform with IT-policies.

3) Yes, there is always a better a posteriori way to do something. :)

4). In 90% not necessarily in practice. And for the rest of 10% when it is, it suffices in 95% to call several instances of QuantLib in parallel (as separate processes). There are enough solutions for this.

5). ...

6). Yes, I mentioned this in my talk and have shown some especially tricky places.
However, my final remark was: Luigi, keep up a good work to keep out mediocres from QL code!
Of course it was said as a joke but anyway, those who can (i.e. nearly everybody who really wishes to) dwell into QL-code is welcome to use it.
For others there are QuantLibXL and Deriscope.
 
The issues with traditional OOP can be seen in many legacy applications, I agree. The functional programming model is becoming more popular and it is the best paradigm for mathematical applications (see (*)).
For point 5) the GOF patterns are applicable to single-threaded applications. Leveraging multi-core technology is very difficult because program decomposition is based on objects.

I agree updating a C++03 application to C++11 would be no walk in the park. It would take a yuge management commitment to free up resources.

One of the maintenance headaches with traditional OOP (correct me if have misunderstood) is the accumulation of layers of objects on top of other objects (lasagna). The reason is that objects communicate by sending messages to each other ==> object entanglement. FP works with function based on signature.

FP has a good future for computational applications IMO.

*

In computer science, functional programming is a programming paradigm—a style of building the structure and elements of computer programs—that treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data. It is a declarative programming paradigm, which means programming is done with expressions[1] or declarations[2] instead of statements. In functional code, the output value of a function depends only on the arguments that are passed to the function,
 
Last edited:
Code: 
HullWhiteFaçade hw(...);

auto result = hw.doit();
Q. BTW how's your C++ fluency?

A: Achtung! This is very interesting question.
Short answer in context of this poll: good enough to solve my tasks by means of QuantLib as well to extend it in such a way that it works for me (but not necessarily always good enough to be contributed to QuantLib repository).

//

I think a good idea for a book is the following: since you know how to navigate in QL (many don't and they are thus your target group) what you can do is create easy C-like wrapper interface using the GOF Façade pattern (which few seem to use, now why is that?)

I would take the top 10 use cases and put them in easy wrappers, e.g. HW piecewise curve calibrators.

I think such a book is good. Hide the details. You would be a proxy between QL and the outside world.

Facade pattern - Wikipedia
 
Last edited:
pingu said:
For the american people, this is call "Monday morning Quaterback"
Click to expand...
Indeed. OP Comment is almost an excuse for keeping the status quo and just plod along, coding as usual. Hope they don't say that to management!

// In Ireland, we call it hurler on the ditch; In Nederland the best skippers are standing on the
// harbour pier. aka is cheap...

In fairness, QL is a software product and you need experienced developers to maintain and extend it. Difficult since it is open-source so not for profit and software is expensive. You could charge for services and free up $ for maintenance.
The 90s were the golden age of OOP and design patterns. It was a kind of boom time. But technology has moved on.

Of course, it depends what the product vision is.
 
Last edited:
3) Yes, there is always a better a posteriori way to do something

This remark shows a complete ignorance (or worse, lack of concern) of what larger software teams have to deal with and also the actual software process itself.
 
Daniel Duffy said:
3) Yes, there is always a better a posteriori way to do something

This remark shows a complete ignorance (or worse, lack of concern) of what larger software teams have to deal with and also the actual software process itself.
Click to expand...
It shows just a healthy pragmatism.
Theorists can speculate on (sic! speculate, not [even try to] improve) the shortcomings and pitfalls of a product, practitioners will either revamp them, or (in most of cases) point out to a pitfall and sketch how to avoid it.
In theory one can improve software architecture as far as one can/want.
In practice there is always trade-off between elegance, robustness, time, costs and efficiency.
 
A bit conservative this 'pragmatism', developers usually jump on new ideas. See it as an opportunity.

Anyhoo,

FYI, I have worked on many (20-30) projects since 1989 (including RiskWatch in 1992). I wrote the first CAD C++ library and holography. So I was in the trenches (including GOF) in all roles, Now I am no longer in the trenches. I was probably one of the first C++ programmers in NL.

For small one-man projects you can manage the project but it does not scale well when many people are on board and the project becomes more complex. You are probably too young to appreciate this if you have not worked on e.g. large C++ pricing libraries that are > 20 years old then extrapolating is silly.

For the record, I have migrated the GOF patterns to the next generation using C++11. And the Quantnet/Baruch C++ courses handle both sets, the current and the new. aka future-proof.

So, we can offer a solution to keep software maintainable.

It shows just a healthy pragmatism.
Who picks up the tab?
 
Last edited:
Tip of the iceberg .. here is an article written by Mikael J. (QL developer in both C++ and C#!) based on an article that Avi (Palley) and myself wrote for Paul Wilmott's magazine.

BTW this is the (more) correct way to model SDE (and NOT class hierarchies). The correct mathematical approach is taken. Try it and see the difference..

Tools for finance: August 2017

I have no problems if you want to stick to pragmatic solution. The downside is low developer productivity.


Anyhoo, here's the Palley/Duffy article (esp. functional programming)

http://onlinelibrary.wiley.com/doi/10.1002/wilm.10606/epdf


Blog: Articles on C++11 and Computational Finance (by Daniel J. Duffy)
 
Last edited:
>I have worked on many (20-30) projects since 1989 (including RiskWatch in 1992).
In 1993 I wrote my first ASM-program for ZX Spectrum (Zilog Z80 Processor).
90s were the time as the elegance in software development was a must.
(Re)-Starting in 2005 my career in Germany as Quant Developer I have seen some legacy code, which had to fit in 640K RAM => elegance and well-thought optimization.

But this time is over!
Nowadays the primary lack is that of time, not of hardware resources or ready-to-use libraries.
Thus the business will not tolerate if you try to keep the code nice but don't deliver to deadline.
Respectively, the experience from the past should be applied with a great caution.
 
Back
Top