• 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!

Blog: Articles on C++11 and Computational Finance (by Daniel J. Duffy)

Analysis of COVID-19 Mathematical and Soware Models: Or How NOT to Set Up a Soware Project


(already published as a preprint; thanks to Paul Wilmott and the team.)
 
@Daniel Duffy Any plans to introduce C++20 into the program curriculum, videos, assignments, etc?
yes, all of those. They will be integrated into the Advance C++. In fact, some new features in C++17/20 course are in Boost (so, essentially replace boost namespace by std).

Plan is in 2nd week of January 2021 up and running.
 
yes, all of those. They will be integrated into the Advance C++. In fact, some new features in C++17/20 course are in Boost (so, essentially replace boost namespace by std).

Plan is in 2nd week of January 2021 up and running.
Just curious to know if there's any updates on this? Haven't seen any announcements on this yet. I'm excited to see what you done.
 
I have all the code ready. I just need to do the videos. Sorry for the slipped schedule (had a new pde/fdm deadline..) So, soon 2-3 weeks I reckon

Here is video #1 for kick off

 
I have all the code ready. I just need to do the videos. Sorry for the slipped schedule (had a new pde/fdm deadline..) So, soon 2-3 weeks I reckon

Here is video #1 for kick off

Fantastic! Christmas has come early for me! :)
 
The beginning of wisdom for a programmer is to recognize the difference between getting his program to work and getting it right. A program which does not work is undoubtedly wrong; but a program which does work is not necessarily right. It may still be wrong because it is hard to understand; or because it is hard to maintain as the problem requirements change; or because its structure is different from the structure of the problem; or because we cannot be sure that it does indeed work.

Michael A. Jackson
 
[CODE lang="cpp" title="C++20 and SDE"]
// Concepts
// 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 SDEAbstract
{ // System under discussion, using composition
// Really a Bridge pattern

private:
T _t;
public:
SDEAbstract(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);
}

};



class SDE
{ // Defines drift + diffusion + data
private:
std::shared_ptr<OptionData> data; // The data for the option
public:
SDE(const OptionData& optionData) : data(new OptionData(optionData)) {}

double drift(double t, double S)
{ // Drift term

return (data->r - data->D)*S; // r - D
}


double diffusion(double t, double S)
{ // Diffusion term

return data->sig * S;
}

};

...

SDE sde(myOption);
SDEAbstract<SDE, double> sud(sde);
[/CODE]
C++11 for the Impatient (with Mr. A. Palley)

Error - Cookies Turned Off

That article used C++11 functions to model stochastic differential equations (SDE) which resolves efficiency and maintenance problems of class hierarchies.
Now that C++20 Concepts are here, life has become a lot easier with almost no disruption to existing code.

C++ is getting better and better.
 
Last edited:
Here's a very simple runnable example to show how Concepts work.

[CODE lang="cpp" title="C++20 Concepts 101"]// Test101Concepts.cpp
//
// Simplest example of a system. Context diagram consists only
// of Input and Output systems.
//
// We use C++20 Concepts to replace policy-based design
//
// Composition
//
// V2: design using C++20 modules
//
// (C) Datasim Education BV 2015-2021
//

#include <string>
#include <iostream>

// Interface contract specification
template<typename T>
concept IInput = requires (T x) { x.message(); };

template<typename T>
concept IOutput = requires (T x, const std::string& s) { x.print(s); };

// I/O stuff
template <typename I, typename O> requires IInput<I> && IOutput<O>
class SUD
{ // System under discussion, using composition

private:
I i; O o;
public:
SUD(const I& input, const O& output) : i(input), o(output) {}
void run()
{ o.print(i.message()); }
};

// Instance Systems
class Input
{
public:

std::string message() const
{
// Get data from hardware device
return std::string("Good morning");
}
};

class Output
{
public:

void print(const std::string& s) const
{
std::cout << s << std::endl;
}

};

int main()
{
Input i; Output o;
SUD<Input, Output> s(i,o);
s.run();

return 0;
}[/CODE]
 
C++ Nostalgia.
In the old days there was no string class. Here's how we did it. You can run the "1992" code.

//

// dynstr.hxx
//
// This class creates and manipulates variable length character strings.
//
// (C) Copyright Datasim BV 1992-1995
//
// The information contained in this file is property of Datasim BV Amsterdam Nederland.
// The information contained herein is subject to change without notice. No part
// of this information may be reproduced or transmitted in any form or by any means,
// electronic or mechanical, for any purpose, without the express written permission
// of Datasim BV.
 

Attachments

Here's an interesting approach: using ODEs to solve optimisation problems. High potential.

C++:
// TestExp5.cpp
//
// Using ODEs for optimisation. The very very simplest example to show how it works in the scalar
// case.
// DJD
// Systems? this is an execise.
//
//
// http://www.unige.ch/~hairer/preprints/gradientflow.pdf
//
// dx/dt = - nabla(U(x)) - lambda * nabla(c*x))
//
// Transform f(x) = 0 to a least-squares problem.
//
// (C) Datasim Education BV 2018-2022
//


#include <iostream>
#include <vector>
#include <cmath>
#include <complex>


#include <boost/numeric/odeint.hpp>

using value_type = double;
using state_type = std::vector<value_type>;

template <typename T>
    using FunctionType = std::function<T(const T& arg)>;
using CFunctionType = FunctionType<std::complex<value_type>>;

value_type CSM(const CFunctionType& f, value_type x, value_type h)
{ // df/dx at x using tbe Complex step method

    std::complex<value_type> z(x, h); // x + ih, i = sqrt(-1)
    return std::imag(f(z)) / h;
}

// We choose min (f(x) - a)*(f(x)-a), f(x) = exp(x)
// Change the value of a to suit needs
const std::complex<value_type> a(std::exp(5.0), 0.0);
auto func = [](const std::complex<value_type>& z)
{
    return (z - a) * (z - a);
};

value_type h = 1.0e-9;

// Free function to model RHS in dy/dt = RHS(t,y)
void Ode(const state_type &x, state_type &dxdt, const value_type t)
{
    // dx/dt = - grad(f(x)
    // We need to compute gradient
    // 1. Exact
    //
    value_type a = std::exp(5.0);
    dxdt[0] = 2.0 * (x[0] - a);

    // 2. Complex Step method

    //dxdt[0] = CSM(func, x[0], h);

    // Transform semi-infinite time to (0,1)
    // I use this technique in many places, dx/dtau = dx/dt (dt/dtau)
    value_type tau = (1.0 - t) * (1.0 - t);
    dxdt[0] = -dxdt[0]/tau;
}

int main()
{
    namespace Bode = boost::numeric::odeint;

    // Initial condition
    value_type L = 0.0;
    value_type T = 0.99;
    value_type dt = 0.01001;

    // Initial condition
    state_type x{0.8};

    // Middle-of-the-road solver
    std::size_t steps = Bode::integrate(Ode, x, L, T, dt);
    std::cout << "Number of steps Cash Karp 54: " << std::setprecision(16) << steps
                << "approximate: " << x[0] << '\n';
     {
        state_type x{0.8};

        // Adaptive solver
        Bode::bulirsch_stoer<state_type, value_type> bsStepper;        // O(variable), controlled stepper
        steps = Bode::integrate_const(bsStepper, Ode, x, L, T, dt);
        std::cout << "Number of steps Bulirsch-Stoer: " << steps << ", approximate: " << x[0] << '\n';
    }

    return 0;

}
 
Just out of curiosity - I watched Bjarne's keynote from Cppcon. In it, he advocates for moving away from preprocessing (such as #include, etc.) and towards using import. Curious to know your thoughts on this and whether it's acceptable to start using this as part of the Advanced C++ course.


1643169529302.png
 
Absolutely! I have been waiting on this feature since 1996 but it has taken some time for the industry to realise that pure OOP is not enough!! The related analysis is called Functional Decompositon in combination with my Domain Architectures.
In order to use C++ modules (I discuss them in the course) it is optimal to partition the problem into components before a single line of code has been written. As warmer-upper, you could take existing code and port it to modules.
Yes?

// For motivation, Python supports modules. C# goes one step further-> modules become run-time assemblies/dlls.
I incude an example for motivation. BTW those ball-and-socket protocol can be done in C++20 Concepts, but that's another story :)

BTW Avi has the last word 😎
 

Attachments

Last edited:
Anyways, fiddle-faddle language skirmishes in the last 40 years are of no consequence in the bigger scheme of things. A major blunder in the 1990s leading to the current software legacy crisis was:


1. Structured Analysis bad, OOP good (actually, I use the two since 1995 in my From Chaos to Classes book).

2. Objects do not model the real world in contrast to popular wisdom.

3. For fixed price projects, it take a lot of money to make bad software.


A short summary is here.



„A subsystem is a set of classes (and possibly other subsystems) collaborating to fulfill a set of responsibilities. Although subsystems do not exist as the software executes, they are useful conceptual entities.“ — Rebecca Wirfs-Brock American software engineer 1953
 
Last edited:
Back
Top