What chances nowadays to get into Quant Developer roles with a PhD in Computational Mech. Eng.

[Daniel Duffy]

You don't really strive for agreeableness, do you?

As you say in your first post, you are looking for advice. For agree... there are other sites.

 

[KillingField]

How to achieve this overhaul (for <£100)? ---> by S. Meyers - Effective Modern C++?
And then dabbling a little with QuantLib, once more privy with the Concepts and Practices of Mathematical Finance?

Effective Modern C++ is not outdated (it's about C++11/14), nor is Meyers syntax only (though the way this particular book opens is on some very tedious arcane differences between auto, template etc. type inference that is basically about syntax). I, however, would not recommend it to you straight out of the box as I regard the book rather advanced (unless I misremember, it does assume a passing knowledge of lvalue, rvalue, std::move etc).

What I would recommend, and I think Daniel disagrees with me here, is for you to start with the old Meyers books, in particular Effective C++. The syntax may be outdated, and it will obviously not have all the bells and whistles of modern C++, but I still think its advice has aged well and it is a good starting point of the dos and don'ts of C++. As I said earlier, your knowledge of C++ seems decades---plural---behind (the next book in Meyers series, More Effective C++ published in 95 goes into detail of implementation and usecase of a shared pointer), and Meyers' old books are basically written for someone with your background moving from "C with classes" to C++.

Now I'm not here to convince you to learn new things if you have already decided that you know better, and that ignorance is something to be proud of. I will way a couple of things though. A line cook at a Michelin star restaurant does not work with the same equipment you do at home nor could they deliver food consistently perfectly cooked, presented and on time were the operations not organized to the level of small details. The experience has little to do with that of a homr cook. Same goes for writing code. Coding is simple and doing that at home is completely different from programming, or software engineering, which is a discipline unto itself and a form of engineering, large part of it being concerned on how to do things at scale.

Rust is a new and a particularly influential systems programming language taking on C++ and fixing its flaws. Memory ownership and killing OOP as it is often (mis)used in C++ being some of its central tenets. C++ in modern times has similarly moved towards smart pointers and borrowed several concepts from languages such as Haskell. It is not simply for fun that people do this or just because someone might forget to type delete (and why this happens is not a matter of simply forgetting delete, but about the more general concept of memory ownership-for someone coding funxtionally simple noninteractive programs at home, these ideas may not come up), but for elegance and to make things work at scale.

 

[Daniel Duffy]

Actually, C++17/C++20 is the current standard! BTW C++14 is essentially bug fixes for C++11.
My main issue is the examples in Meyers' book .. everything is a vanilla Widget class which is not to everyone's taste. From there my somewhat nasty remark on syntax. Many application developers consult www.cppreference.com for updated syntax. Each to his own.

I always like giving good examples to show off syntax.

Here is how I explain syntax before jumping into applications. Always give good examples.

click this

Error - Cookies Turned Off

onlinelibrary.wiley.com

 

[Daniel Duffy]

I loved the C++ book "Thinking in C++" by Bruce Eckel. That's where I started end 80s.

On a more general rant/note, most of the new fancy syntax is premature optimization (some CS developers do like it nonetheless) and it cannot be implemented in the short term. They try to optimize even before they have a working prototype, speaking as trainer, designer, project manager (time costs money).

 

[Daniel Duffy]

Rust is a new and a particularly influential systems programming language taking on C++ and fixing its flaws

C++ has no flaws, just features
Rust is probably another 'quiche' language? It is mainstream?

If anything, Julia looks very exciting for finance, but I have not used it.

https://en.wikipedia.org/wiki/Julia_(programming_language)

C++ is like democracy; not perfect but the best of the rest.

 

[KillingField]

Rust is probably another 'quiche' language? It is mainstream?

I never said Rust to be widespread, just influential. That said it is the driving force at Mozilla (for Firefox) and widely used at some other tech companies (off the top of my head, DropBox and Facebook have announced some major projects). Even the Linux kernel has welcomed Rust drivers as of late and without naming names at least a couple of large fintechs/funds have embraced the language. While personally I do like the language, my point was not that it was good, but that a language that consistently gets voted as most liked on Stack Overflow (thus the influencer clout) gets several features that have made a recent appearance in C++ in the core language itself (so the compiler helps you---the entire point of typed/compiled languages) is in itself significant and an indicator of moving software engineering practices (beyond new/delete in this case).

As for Julia, I've tested it in the past and liked it as a replacement for Matlab. But Python, too, is a decent replacement; though slightly worse, I don't see Python's position being threatened, especially given how well it has dug its heels in in the ML community.

 

[Berenger]

Effective Modern C++ is not outdated (it's about C++11/14), nor is Meyers syntax only (though the way this particular book opens is on some very tedious arcane differences between auto, template etc. type inference that is basically about syntax). I, however, would not recommend it to you straight out of the box as I regard the book rather advanced (unless I misremember, it does assume a passing knowledge of lvalue, rvalue, std::move etc).

What I would recommend, and I think Daniel disagrees with me here, is for you to start with the old Meyers books, in particular Effective C++. The syntax may be outdated, and it will obviously not have all the bells and whistles of modern C++, but I still think its advice has aged well and it is a good starting point of the dos and don'ts of C++. As I said earlier, your knowledge of C++ seems decades---plural---behind (the next book in Meyers series, More Effective C++ published in 95 goes into detail of implementation and usecase of a shared pointer), and Meyers' old books are basically written for someone with your background moving from "C with classes" to C++.

Praise for Meyers' books is pretty much universal ( here for instance, or more specifically targeted at quantitative finance jobs ). These books shall be profitable reading, given that I happen to know what lvalues ("left value", assigned and modifiable) and rvalues ("right", temporaries such as function returns) are. I would not have made it very far in debugging gcc error messages otherwise.

Now I'm not here to convince you to learn new things if you have already decided that you know better, and that ignorance is something to be proud of. [...] It is not simply for fun that people do this or just because someone might forget to type delete (and why this happens is not a matter of simply forgetting delete, but about the more general concept of memory ownership-for someone coding funxtionally simple noninteractive programs at home, these ideas may not come up), but for elegance and to make things work at scale.

Well yes I wrote something crass about people forgetting to type 'delete' lines, but making assumptions based on some light-hearted remark is very much an exercise in creativity.
On the contrary, I find that holding trenchant opinions helps with remembering the topics they are about.

Opinions are after all of scarce value. Allow me to digress: the Spartans knew this, they were renown in the ancient world for being somewhat monosyllabic ('laconic' stems from here). This was because deep down they understood that it is important to see things and to discern situations for what they are, rahter than instead mediating reality with words (=opinions), which is conductive to doubt, lies and treachery.
The Spartans left us just a few deaf stones, and yet they won the war of the Peloponnese for dominance over ancient Greece against their rivals, the unrivaled Athenians, the originators of rhetoric and dialectics, who on the contrary left a huge material and above all cultural legacy.
Yet Plato, from democratic Athens, held the Spartan society in the highest esteem.

In real life I have spent a few years coding a numerical solver for nonstandard systems of PDEs in complex domains, with environmental pressures being on the ends (obtaining results, publish, write thesis) and not on the means (admittedly no "make it work, make it right, make it fast" mentality).

I have the feeling this is after all a head start in quantitative finance, because I get the impression that learning about Software Development on top of a numerically-literate substrate is somewhat easier than the other way around, of teaching a smattering of Applied Mathematics to a software developer. Care to confirm?

Back to the topic, @Daniel_Duffy too reports in the opening of paragraph 2.2.1 of his Financial Instrument Praising using C++ (2nd ed.) , that the main issue here is not as much about elegance, but more prosaically about dangling pointers and memory leaks caused by error-prone bookkeeping of 'raw' pointers. This in turn makes the memory Heap a heap of a mess.
I also understand there are other less impairing problems involved (exceptions being thrown before a pointer is deleted): I can appreciate the nuances, I am coming across as a fanatic of raw pointers here and this was unintended.

 

[Daniel Duffy]

@Daniel_Duffy too reports in the opening of paragraph 2.2.1 of his Financial Instrument Praising using C++ (2nd ed.) , that the main issue here is not as much about elegance, but more prosaically about dangling pointers and memory leaks caused by error-prone bookkeeping of 'raw' pointers. This in turn makes the memory Heap a heap of a mess.
I also understand there are other less impairing problems involved (exceptions being thrown before a pointer is deleted): I can appreciate the nuances, I am coming across as a fanatic of raw pointers here and this was unintended.

Cherry picking; read sections 2.3 to 2.6.
Section 2.2.1 was a short history lesson on raw old style memory management. Sections 2.3 to 2.3 are devoted to smart pointers.
Yeah, maybe take the high ground and focus on writing some applications for finance.

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

I am coming across as a fanatic of raw pointers here and this was unintended
Want to talk about it?

 

[Daniel Duffy]

The late Mark Joshi's C++ book with Design Patterns + basic examples in finance might be a good place to get some initial exposure. It dates from 2005 (same time as 1st edition of my own book), so much has changed.

 

[Daniel Duffy]

A follow-on and related discussion on C++11 and using it in applications

1. Pareto rule: 20% of C++ syntax delivers 80% of its efficacy.
2. Some developers wax lyrical on super-cool syntax such as constexpr, too much emphasis on auto, generic lambdas. Determine why you want to use them and what the consequences are before wasting time that you may never use. Always provide a business case (time costs money).
3. 25 years ago multiple inheritance in C++ was the new hype; it was in fact a train wreck. I _never_ used it because there are better ways to do software design. In fact, inheritance is neither necessary nor sufficient:

https://en.wikipedia.org/wiki/Object_composition

4. There are different kinds of programmers

https://forum.wilmott.com/viewtopic.php?f=10&t=99650

5. Syntax for syntax sake is mind-numbing.

6. Code is written once and read/modified/debugged/hacked many times for the next 20 years. And this costs $$$ and it doesn't grow on trees. It is always good to first write a proof-of-concept.
7. Forget step 6 if you have money to burn.

Of course, these remarks apply universally.

 

[Berenger]

https://forum.wilmott.com/viewtopic.php?f=10&t=99650

Wow, this thread is almost as lengthy as your book, took two years to develop it.
But I agree - or, at least, it sits well with me - that different languages describe different worlds, rather than just attach different labels to the same world. Who said that?

2. Some developers wax lyrical on super-cool syntax such as constexpr, too much emphasis on auto, generic lambdas. Determine why you want to use them and what the consequences are before wasting time that you may never use. Always provide a business case (time costs money).
3. 25 years ago multiple inheritance in C++ was the new hype; it was in fact a train wreck. I _never_ used it because there are better ways to do software design. In fact, inheritance is neither necessary nor sufficient:

https://en.wikipedia.org/wiki/Object_composition

5. Syntax for syntax sake is mind-numbing.

6. Code is written once and read/modified/debugged/hacked many times for the next 20 years. And this costs $$$ and it doesn't grow on trees. It is always good to first write a proof-of-concept.
7. Forget step 6 if you have money to burn.

Of course, these remarks apply universally.

This is funny:

He could have used RUST, instead of C++, for further comedic effect

The late Mark Joshi's C++ book with Design Patterns + basic examples in finance might be a good place to get some initial exposure. It dates from 2005 (same time as 1st edition of my own book), so much has changed.

Yes I have that one as companion of his other Concepts and Practice.. book.

Section 2.2.1 was a short history lesson on raw old style memory management. Sections 2.3 to 2.3 are devoted to smart pointers.

Sections 2.3 to 2.3 don't seem to contradict section 2.2.1. Would have been worrying otherwise I think ...

 

[Daniel Duffy]

The demo!

1. GetPerimeter(), Area() do not belong in Shape ... not all shapes are closed
2. He did not delete the array of Shape* in main()

See the C++ code from boost. Best in class.

Wow, this thread is almost as lengthy as your book, took two years to develop it.
But I agree - or, at least, it sits well with me - that different languages describe different worlds, rather than just attach different labels to the same world. Who said that?

Sapir_Whorfe said it. Humboldt is better
“Die gefährlichste Weltanschauung ist die Weltanschauung derer, die die Welt nie angeschaut haben."


Language is not the problem. They have 98% of the genes of C.

It's one of the shorter marathon threads on Wilmott.

 

[Berenger]

The demo!

1. GetPerimeter(), Area() do not belong in Shape ... not all shapes are closed
2. He did not delete the array of Shape* in main()

1. Anyone not a mathematician would tacitly assume Shape to be simply connected...
2. That's what I was talking about all along. Not elegance, not exception handling, ... this.

Besides, look at the lengths he goes out of fear to be framed as "C with classes". He also gets generic programming in, amongst the other nonsense, so he can dodge such a scathing label.
In the comment section they are criticising him for not having used the Factory pattern.

Sapir_Whorfe said it. Humboldt is better
“Die gefährlichste Weltanschauung ist die Weltanschauung derer, die die Welt nie angeschaut haben."

Richtig

 

[Daniel Duffy]

Anyone not a mathematician would tacitly assume Shape to be simply connected...
Nothing got to do with maths, it's no insurance again not understand CAD and good design.
And design patterns are great for CAD, esp. Factory, Composite, Bridge, Strategy and above all. VISITOR (multiple dispatch).

Disclaimer: I wrote the first ever CAD Object library in C++ 1992 and later in C# for Mech, process, holography and an API interface to AutoCAD. And before that the top-notch Medusa package.

 

[Berenger]

2. He did not delete the array of Shape* in main()

Ha ving watched the video again , I now notice he added a virtual destructor

 

[Daniel Duffy]

Ooompfh 1168 pages, you guys really want to keep me unemployed

My book is really several books in 1:

1168 pages??? It's only 1142 pages, what?

1. C++11 syntax A-Z without being a copy of the reference manual. Syntax alone + silly examples I am allergic to (sorry, I am not a CS).
2. New libraries e.g. random, tuple for maths
3. STL A-Z
4. ODE, SDE, PDE and FDM for Black Scholes
5. Parallel programming and libraries
6. Modern design and architecture
7. + other stuff

That's why it's 1142 pages. And for the price of 1 book + full tested source code (nobody else does/dares this )

 

[Berenger]

Ooompfh 1168 pages, you guys really want to keep me unemployed

My book is really several books in 1:

1168 pages??? It's only 1142 pages, what?

1. C++11 syntax A-Z without being a copy of the reference manual. Syntax alone + silly examples I am allergic to (sorry, I am not a CS).
2. New libraries e.g. random, tuple for maths
3. STL A-Z
4. ODE, SDE, PDE and FDM for Black Scholes
5. Parallel programming and libraries
6. Modern design and architecture
7. + other stuff

That's why it's 1142 pages. And for the price of 1 book + full tested source code (nobody else does/dares this )

Surely I'll get ahold of your book once I am done with Joshi's ones.
On amazon it states 1168 pages, maybe including empty pages, prefaces etc.
I liked the 2 chapters readable as amazon preview, it is written in a no nonsense style that suits the practitioner.

 

[Daniel Duffy]

Thank you. One goal is to get the reader up to speed as quick as possible. In training sessions, it is similar to 20 minutes lecturing and then 30 minutes practice. This is the optimal mix imho.

 

[Berenger]

Thank you. One goal is to get the reader up to speed as quick as possible. In training sessions, it is similar to 20 minutes lecturing and then 30 minutes practice. This is the optimal mix imho.

1 section in a chapter is equivalent to 20 + 30 min lessons + exercises?

 

[Daniel Duffy]

1 section in a chapter is equivalent to 20 + 30 min lessons + exercises?

Good question. A given topic has a begin(), middle and end(), So new C++11 stuff needs to be motivated before jumping into code, for example chapter 3 on modelling functions is vital

1. What kinds of functions
2. Functional programming
3. FP in C++11, what, how, why, when
4. Examples

For chapter 5 (Tuple) about 1 hour A-Z.

Off-hand (it's in my QN courses) I can get the student up to speed in say 3-4 sessions of 20-30 minutes,. C++ is not a spectator sport and then the best way to learn is to code it up. 20% of the syntax fills 80% of the core business.

I usually stop talking when the students become a bit restless and then I let them do some hands-on work.