C++ Design Patterns and Derivatives Pricing VS Financial instrument pricing using C++

[WZhang]

So I was wondering ultimately which book is better to learn if you were advance c++ user and if you want to learn about Quantiative finance development in C++.

 

[Daniel Duffy]

You mean, the Joshi book or my book (2018 2nd edition is the most uptodate C=+11). The former is outdated. And traditional design patterns have been given a facelift in my courses.

https://www.datasim.nl/application/files/5615/3778/5054/Chapter1Watermark.pdf

The best way to learn C++11 etc. is the Baruch Advanced C++ course.

 

[Daniel Duffy]

C++20 is shipping; It supports Concepts and it will subsume traditional Design Patterns. For example, here is the Bridge pattern, it' the best way to do it.
42
This is coming on Advanced C++ course.

[CODE lang="cpp" title="Bridge"]// Interface contract specification
template<typename T, typename Data>
concept IDiffusion = requires (T c, Data t, Data x) { c.diffusion(t,x); };

template<typename T, typename Data>
concept IDrift = requires (T c, Data t, Data x) { c.drift(t, x); };

template<typename T, typename Data>
concept IDriftDiffusion = IDiffusion<T, Data> && IDrift<T, Data>;

template <typename T, typename Data> requires IDriftDiffusion<T, Data>
class SUD
{ // System under discussion, using composition
// Really a Bridge pattern

private:
T _t;
public:
SUD(const T& t) : _t(t) {}
Data diffusion(Data t, Data x)
{
return _t.diffusion(t, x);
}
Data drift(Data t, Data x)
{
return _t.drift(t, x);
}

};[/CODE]

Traditional OOP patterns are fine and work OK but Concepts are at a higher cognitive level, more like protocols.

@APalley, @GONG CHEN

 

[Berenger]

C++20 is shipping; It supports Concepts and it will subsume traditional Design Patterns. For example, here is the Bridge pattern, it' the best way to do it.

Traditional OOP patterns are fine and work OK but Concepts are at a higher cognitive level, more like protocols.

What's the logic behind these updates to the language happening every three years that make books obsolete and have you scramble over tedious documents online to get the gist of the changes? Tends to be annoying, luckily compilers always lag a few years behind new language specifications.

 

[Daniel Duffy]

What's the logic behind these updates to the language happening every three years that make books obsolete and have you scramble over tedious documents online to get the gist of the changes? Tends to be annoying, luckily compilers always lag a few years behind new language specifications.

It's called progress.

Strange reply and incorrect. If you had followed the C++ committee down the years you would know why. C++11 and Boost C++ use this stuff .. it's called Template Metaprogramming.

Those GOF patterns are 30 years old. I use them since 1992,. They were OK when C++ was a baby (did you know the first native C++ compiler was only in 1990?). It was a painful period and GOF was a welcome fix.

compilers always lag a few years behind new language specifications.
Wrong.
Visual Studio 16.10 supports C++20. NOW NOW

hth

 

[Berenger]

It's called progress.

Strange reply and incorrect. If you had followed the C++ committee down the years you would know why. C++11 and Boost C++ use this stuff .. it's called Template Metaprogramming.

Those GOF patterns are 30 years old. I use them since 1992,. They were OK when C++ was a baby (did you know the first native C++ compiler was only in 1990?). It was a painful period and GOF was a welcome fix.

compilers always lag a few years behind new language specifications.
Wrong.
Visual Studio 16.10 supports C++20. NOW NOW

hth

In that message I was venting a frustration that I think any programmer can relate to.
The content of that message is not factual but emotional, hence cannot be labelled 'strange', and even less so 'incorrect'. And let's put aside considering whether it would even be proper or polite to do so.

The constant need of knowledge update and of learning new tools is the main reason of burnout in software development.
Compilers have always lagged behind language specifications, that's also a fact. If Visual Studio 16.10 supports C++20 now, it's an exception to this rule that does not make it less true.

 

[Daniel Duffy]

Please try to investigate before posting half-truths. It just wastes so much time.

 

[Berenger]

Please try to investigate before posting half-truths. It just wastes so much time.

What half truth, be specific. There is no true or false involved here.
How much time did it take you to write half a line?

 

[MichaelLewis]

This is coming on Advanced C++ course:

when? I plan on taking it, so maybe I’d wait for this new content.

 

[Daniel Duffy]

when? I plan on taking it, so maybe I’d wait for this new content.

I've finished _everything_. So it's a matter to get it into the forum. Very soon indeed.
I would say I have done 80% at least of C++17/C++20.
and C++20 will be at the end of the course, so you can start.

 

[Daniel Duffy]

What half truth, be specific. There is no true or false involved here.
How much time did it take you to write half a line?

e.g.

Compilers have always lagged behind language specifications, that's also a fact. If Visual Studio 16.10 supports C++20 now, it's an exception to this rule that does not make it less true.
This is a remark that not even wrong. It's a variation of the True Scotsman Fallacy.

In that message I was venting a frustration that I think any programmer can relate to.
How many do you know? I would not employ such guys.

FYI the reason for the C++20 update was that several industry quants requested it.

I think you are projecting what you think reality is.

 

[Berenger]

e.g.

Compilers have always lagged behind language specifications, that's also a fact. If Visual Studio 16.10 supports C++20 now, it's an exception to this rule that does not make it less true.
This is a remark that not even wrong. It's a variation of the True Scotsman Fallacy.

First you said it was a half truth, now it's not even wrong.
True/false and right/wrong are two different categories of thought, go back to your Aristotle.
What I stated is simply factual: the all-natural delay in implementation of new language standards on compilers is obvious and to be expected. As in all endeavours, there is a gulf between theory and practice.
Maybe I am bringing myself down a level or two in just caring to provide evidence of the above, but see for instance this on C++14 still not yet fully supported by VS2017... in 2017. Quoting from the link:
"Our compiler conformance progress shows the benefits of both the rejuvenation [...] We’ve implemented almost all of the features introduced in the C++11 and C++14 standards. There are always bugs, of course."
And this is one in a million examples, there are new standards of other, less widespread languages that are still purely theoretical, years after these new standards have been released.

In that message I was venting a frustration that I think any programmer can relate to.
How many do you know?

Similarly to the above, you are arguing against the obvious just for the sake of playing the troll, I guess?
In fact you are not even arguing it, you are skirting around the subject.
As I wrote in a previous message (we are going in circles), "The constant need of knowledge update and of learning new tools is the main reason of burnout in software development.".
I don't think you'd want to debate that. In fact, you didn't the first time I've posted it.

I would not employ such guys.

FYI the reason for the C++20 update was that several industry quants requested it.

I think you are projecting what you think reality is.

Whether you would employ someone or not is immaterial, given the state of your current activities. Kind of reminds me of locals selling spades to gold diggers during the Yukon rush, thinking they knew better.
Luckily I don't need to resort to pop psychology ("true scotman" something, "projecting" this and that) to make my points but if I were to, I'd say you are the one projecting here, with your priceless "I am a fussy employer" delusions.

 

[Daniel Duffy]

As I wrote in a previous message (we are going in circles), "The constant need of knowledge update and of learning new tools is the main reason of burnout in software development.".

Not at all. It just feels like that at the moment.
You'll find out in due course after you land your first job.
You will be competing with guys and gals who don't get burnout from a bit of innovation.

//Since your background is Mechanical Engineering one way to make an impression could be FEM for 1 and 2 factor American options. In C++.

 

[Daniel Duffy]

"Regarding C++98/03, I am glad to have learned it instead of the modern revisions."

...

 

[Berenger]

As I wrote in a previous message (we are going in circles), "The constant need of knowledge update and of learning new tools is the main reason of burnout in software development.".

Not at all. It just feels like that at the moment.

C# .NET Core Win/Linux, Python, Laravel, Go, PostgreSQL, AWS, Bash, Kubernetes, Docker, Angular, Django, Flask, Julia, Qt . . .

You'll find out in due course after you land your first job.
You will be competing with guys and gals who don't get burnout from a bit of innovation.

Oh my, the avuncular tone. Chapeau, this is professional trolling.