[C++] Monte Carlo Variance Reduction

Transcription

1 [C++] Monte Carlo Variance Reduction Roma in R ouss eau / EN SAE Contexte L'objectif du projet était l'écriture d un code C++ capable de réaliser des simulations de Monte Carlo, tout en implémentant si possible des méthodes de réduction de la variance ; les exemples à utiliser pouvant être le calcul de la valeur d instruments financiers. Le projet final ne comporte pas de méthodes de réduction de variance et se concentre sur la génération de nombres aléatoires, la simulation de processus, et le calcul d espérance empirique de payoffs sur des produits dérivés plus ou moins classiques. Méthode de Monte Carlo La méthode de Monte Carlo consiste, dans sa définition la plus large, à approcher le résultat d un calcul analytique au moyen d instruments probabilistes: l introduction d une dimension statistique permet d augmenter le champ des problèmes qu il est possible de résoudre, tout du moins de façon approchée. Il peut exister au préalable une ou des solutions à ces problèmes, mais qui soient plus compliquées et/ou plus longues qu au travers de la méthode de Monte Carlo. On peut ainsi estimer la valeur d une intégrale en exprimant sa valeur comme l espérance d une variable aléatoire: le plus souvent comme l espérance d une fonction (mesurable) d une variable aléatoire plus simple (théorème de transfert). On peut par exemple prendre la fonction en question comme étant la fonction sous l intégrale cherchée, et la variable aléatoire plus simple comme suivant une loi uniforme (en réalité tout autre choix de densité est possible, il faut néanmoins être en mesure d effectuer expérimentalement des tirages selon la loi associée). La loi des grands nombres permet de déclarer la moyenne empirique comme un estimateur de l espérance d une variable aléatoire (sous certaines conditions: les différents éléments de l échantillon doivent notamment être identiquement distribués, et indépendants entre eux). Réduction de la variance Si les résultats mathématiques précédents sont «suffisants» dans l absolu, pour justifier la pratique des méthodes de Monte-Carlo, leur mise en place sans autre réflexion préalable pourrait bien s avérer décevante ou tout du moins déconnectée des contraintes réelles auxquelles tout un chacun peut se retrouver confronté: en effet si la convergence est garantie, rien n est dit sur sa vitesse ; il faut pour cela se tourner vers le théorème central limite! Le résultat apporté est à la fois intellectuellement plaisant, et néanmoins décevant du point de vue de la mise en application : en effet l écart-type est de l ordre de 1 (où n est la taille de l échantillon) ; pour réduire n l incertitude d un facteur 10, l échantillon doit être 100 fois plus conséquent! Il est néanmoins possible d affiner la méthode assez générale décrite jusqu alors, en la particularisant au problème étudié : dans l objectif de réduire la variance et donc in fine, si l on raisonne à variance fixée, de se contenter d un échantillon de taille plus modeste, ce qui revient à minimiser le temps de calcul nécessaire à l obtention d un résultat numérique. L idée la plus naturelle revient à changer la densité selon laquelle les variables aléatoires sont tirées dans le protocole décrit précédemment, afin de donner plus de poids aux valeurs importantes : puisque leur contribution à la moyenne est évidemment plus importante, il faut minimiser l imprécision sur celles-ci, et le moyen le plus logique est de «concentrer» les tirs dans ces zones à plus fortes contributions. Pour que l espérance demeure la même, il convient de compenser le changement de densité en appliquant à la nouvelle variable aléatoire une nouvelle fonction qui sera le rapport de l ancienne fonction sur la nouvelle densité (c'est-à-dire la densité de Radon-Nikodym, de la distribution initiale par rapport à la distribution nouvellement choisie pour optimiser la variance) ; ce ratio est défini de façon unique (hormis sur un ensemble de mesure nulle) d après le théorème de Radon-Nikodym-Lebesgue.

2 Langage et outils C++ Le langage choisi devait bien sûr permettre de mettre en pratique les concepts présentés en cours et en séances de TD, mais il se révélait de toute façon fortement adapté aux contraintes propres au problème considéré : la complexité du problème et donc indirectement le temps de calcul représente une des contraintes les plus fondamentales lors de la mise en œuvre de projets de simulation ; or le C++ se révèle très avantageux face à d autres langages en terme de performances à l exécution : il permet de produire du code natif, exécutable directement par le processeur. Ça n est pas le cas des autres langages orientés objet les plus répandus : Java, C# ne produisent qu'un bytecode pour machines virtuelles, dont la perte de performance est en simplifiant à la hauteur de la portabilité induite. D autres langages orientés objet font «pire» en terme de vitesse : Python, Ruby et PHP pour ne citer que les plus populaires, sont interprétés à la volée, laissant toujours plus de souplesse aux utilisateurs de ces langages au détriment de la performance brute. En matière de performance, le C++ n'est pas non plus exactement à la hauteur de son prédécesseur historique dont il hérite très largement : le C. Il offre en revanche les nombreux apports de la conception dite «objet» de la programmation : l utilisation de concepts propres tels que l encapsulation, l héritage ou encore le polymorphisme doivent permettre selon ce paradigme la mise en place de programmes plus facilement lisibles, aux fragments plus réutilisables, tout en apportant une certaine rigueur et en permettant théoriquement de mieux anticiper les étapes du développement. Parmi les langages offrant ces avancées, et bien qui vieillissant de plus en plus, le C++ demeure un des langages les plus utilisés dans beaucoup d industries car il incarne ainsi une sorte de compromis entre fiabilité, facilité et performance. En matière de simulation il serait d autant plus étrange de choisir un autre langage moins performant, qu on cherche dans le cas présent à implémenter des méthodes de réduction de variance donc d optimisation des performances de calcul! Si un investissement est réalisé sur la recherche de méthodes judicieusement adaptées au problème, il ne s agirait pas de sacrifier cet investissement en choisissant ensuite d effectuer l implémentation dans un langage de script aux performances en retrait. IDE Le choix de l environnement s est porté sur Visual Studio de Microsoft, sous Windows, afin d être familiarisé à titre personnel avec cet outil très largement utilisé en milieu professionnel. Le code écrit est relativement standard et devrait donc pouvoir être compilé dans vraisemblablement toute autre plateforme de développement C++ quelle qu elle soit, sous tout OS puisqu aucune fonction spécifique de l API Windows n a par exemple été utilisée. Même si d autres outils libres de qualité sont disponibles, le choix de Visual Studio était donc assez pragmatique dans la mesure où il me semblait important de connaitre de façon assez minimale tout du moins ses spécificités (options de configuration, outils de débuggage, etc.). Il ne s agit par ailleurs pas d une solution nécessairement payante puisque la version «Express» de Visual C s est révélée tout à fait satisfaisante. (La version 2010 actuellement en Beta a également été utilisée mais les fichiers de projet et de solution doivent être convertis à chaque ouverture, ce qui ne facilitait pas l interaction avec les postes de l ENSAE par exemple). UML Des fonctions utiles de la version complète sont toutefois absentes, notamment celles liées aux diagrammes de classe. Pour ce besoin spécifique, le logiciel libre BOUML (signalons au passage que son géniteur est français) a été utilisé. La version complète de Visual Studio permet également la génération facile de diagrammes de classes mais ça n est pas disponible dans la version gratuite et moins de détails sont affichés. Versionning D autres fonctionnalités très utiles mais absente de l IDE de Microsoft ont été trouvées auprès d autres projets libres : RapidSVN a ainsi permis de pouvoir effectuer des commit et checkout sur le repository mis en place à l occasion via la plateforme Google Code. Subversion est un système de gestion des versions qui succède à son ancêtre CVS, ce dernier faisait preuve de nombreuses faiblesses (les modifications sont par exemple non «atomiques», ce qui peut entrainer la corruption des données en cas d interruption d une

3 transmission). Bien que moins moderne que Git, système de versionning entièrement distribué, fondé par l auteur du noyau Linux, Subversion est extrêmement répandu : Google offre notamment une plateforme pour les projets de développement, permettant d utiliser un dépôt pour les sources. Encore plus utile dans le cas où plusieurs développeurs travaillent simultanément sur un projet, l utilisation de cet outil qu est le versionning s est tout de même révélé fort utile : cela permet de s assurer de posséder un cliché de toutes les versions passées du code et les versions différentes d un même fichier peuvent être comparées à différents instants. Cela peut par exemple permettre de revenir facilement en arrière pour récupérer un fragment effacé par inattention. Enfin, en travaillant sur différents postes (ENSAE, ordinateur personnel), le dépôt permet de faire le lien, plutôt que d avoir recours à d autres solutions, qui si elles existent, sont moins satisfaisantes (clé USB, envoi par , Dropbox, ). Un paradoxe de la politique de sécurité des postes de l école a été soulevé à cette occasion : ne disposant pas des droits suffisants pour pouvoir installer un outil traditionnel tel TortoiseSVN sous Windows, j ai du recourir à une version dite «portable» (sans installation) de RapidSVN. Le problème réside dans le fait qu il ne s agit pas d une version «officielle» mais d un hack réalisé par un tiers et dont l exécutable peut seulement être téléchargé depuis une page personnelle ou des sites comme Rapidshare. Si le programme ne risque pas de compromettre toute la machine, puisqu il est justement conçu pour ne pas avoir besoin des droits administrateurs nécessaires à la version installable, il pourrait toutefois parfaitement être compromis et permettre à son créateur l accès à toutes les données utilisateur. Cela ne pourrait arriver qu avec une probabilité beaucoup plus faible sinon nulle dans le cas de la version «authentique» de RapidSVN qui est un logiciel libre dont les sources sont disponibles. Librairies La GSL était utilisée dans un premier temps, avant que le projet ne s en affranchisse intégralement. En revanche la génération de nombres aléatoires par l algorithme Mersenne Twister fait appel à une implémentation (Rick Wagner) totalement utilisée comme telle, sous forme de source compilée avec le reste du projet mais absolument pas modifiée. Divers Les deux logiciels libres Notepad++ et SciTE ont été utilisés occasionnellement : condensant tous deux une pléthore de fonctions dans un poids plume, ce sont de véritables couteaux suisses de l édition de code. Enfin, certaines sorties graphiques ont été permises par le logiciel R qui peut s interfacer facilement en important les sorties textes au moyen de la commande scan(), la vérification des données et la production d histogrammes sont ensuite très simple à effectuer ; il s agissait donc du complément idéal pour vérifier le bon fonctionnement du programme. Structure du code Les techniques employées et les objectifs satisfaits par chacune des parties du projet sont détaillés ici, cette partie du rapport étant organisé autour des classes de base. Le code est en effet organisé sous forme d un graphe de classes, où les relations d héritage peuvent se représenter par un arbre orienté, la racine possédant 8 nœuds comme successeurs immédiats qui constituent les classes de base du projet : Range, V, RandomGenerator, BlackScholes, Payoff, MonteCarlo, Tests, Pipe et Chrono. Parmi celles-ci, toutes n ont pas la même «importance» dans la mesure où certaines sont la base d une hiérarchie sur plusieurs niveaux alors que d autres n existent qu en tant que telles et ne sont pas réutilisées par d autres classes filles. La description de toutes les classes du projet sera donc effectuée selon leur classe de base. class Range Première des classes crées pour le projet, il s agit d une structure destinée à contenir les informations sur un intervalle, au sens mathématique du terme ; l objectif étant par la suite de pouvoir faire évoluer un processus le long de cet intervalle. Cette classe est vouée à être passée en paramètre à une classe chargée d effectuer les calculs proprement dits. Les membres les plus évidents d une telle classe sont évidemment ses bornes : inférieure et supérieure (respectivement lbound et ubound).

4 Il faut ensuite s affranchir de la nature strictement mathématique de l objet pour prendre en compte les spécificités d une approximation numérique : il faudra nécessairement effectuer des calculs sur un nombre fini de points : steps définit le nombre d étapes que l on peut parcourir au sein de cet intervalle: on le discrétise pour en faire au final un ensemble de points (attention : steps n est pas le nombre de points mais le nombre d étapes, autrement dit le nombre de points moins un). Par soucis de simplicité, dans l implémentation retenue les points au sein de l intervalle discrétisé sont régulièrement espacés ; ça n est bien sûr pas justifié mathématiquement dans la mesure où il peut être bien plus judicieux d intégrer une fonction selon un schéma différent. Pour permettre une telle évolution future, une méthode Next() est disponible, et renvoie la valeur du prochain point. Il s agit donc d un objet qui peut être «parcouru». Il convenait donc de rajouter également une méthode Reset() et un simple membre public current pour manier plus facilement cet objet. D autres méthodes sont également disponibles afin de connaitre la longueur totale de l intervalle, de renvoyer ses deux bornes simultanément sous forme d un tableau (d un pointeur vers la première case de ce tableau, en réalité), ou encore de renvoyer dans un flux une chaine de caractère (correspondant à l affichage des bornes et de la distance entre deux points, dans l implémentation effectuée, mais cela se change facilement) lors de l utilisation de l opérateur <<, dans le but de pouvoir simplifier d éventuels affichages ou autres sorties. Tout ce qui est mis en place dans cette classe n est pas directement utilisé et il s agissait aussi d un premier exercice puisque c était le point de départ du codage du projet. class V Le manque d inspiration dans le choix du nom de cette classe n est pas le reflet d une importance minime, au contraire il s agit d une structure au cœur de l organisation du code puisqu elle permet le stockage de données numériques, il s agit plus banalement d un vecteur. La librairie standard du C++ définit déjà une classe vector<>, par exemple quelle est donc l utilité d en coder une nouvelle? À vrai dire, rien n est réinventé et il ne s agit jamais que d envelopper la classe standard par une interface, pour simplifier le reste du code : 2 (en fait 3) classes héritent de la classe V, et sont ensuite utilisées à tour de bras dans le reste du projet. L implémentation sous-jacente peut totalement changer, l interface demeure la même au travers des méthodes publiques. C est d ailleurs ce qui a été fait : jusqu au dernier moment la librairie scientifique GSL était requise par le projet car V se basait intégralement sur gsl_vector. Il a été ensuite très facile de s en affranchir puisqu il n y est fait référence nulle part, il suffisait donc de réécrire une seule classe : V! L interface définie par V est la suivante : Get() / Set() permettent d accéder en lecture / écriture à une valeur du tableau, et GetLast() / SetLast() sont des «raccourcis» pour accéder directement au dernier élément, plutôt que d avoir recours à Size qui renvoie le nombre d éléments. Push() permet d ajouter un élément en fin de vecteur (la taille est incrémentée d une unité), et Reset() réassigne un nouveau vecteur dont il faut spécifier la nouvelle taille. À nouveau, l opérateur << est surchargé pour un paramètre de gauche de type std::ostream, toujours afin de pouvoir simplifier les sorties : cela évite d écrire et réécrire les mêmes boucles lorsque l on souhaite tester son code. De même, l opérateur >> est surchargé pour un membre de gauche de type std::vector<double> ou bien std::istream, pour pouvoir «importer» des données depuis un vecteur ou une entrée de type flux. L intérêt est notamment pour pouvoir tester avec une trajectoire connue un Payoff (classe définie par la suite). Le même opérateur est également surchargé afin de permettre la copie depuis et vers un gsl_vector*, mais si elles ont servies lors d étapes de test au préalable, le code est désormais commenté afin de pouvoir débarrasser le projet de ses dépendances avec gsl.lib puisqu il n y fait plus appel ailleurs. Les opérateurs de recopie et d assignation ont été redéfinis, conformément à la «règle des 3», qui affirme (ou plutôt «alerte») qu en cas de définition du destructeur alors les 2 opérateurs en question doivent également être modifiés en conséquence (cela signifie simplement qu il ne faut pas copier «bêtement» des pointeurs mais recopier le contenu par exemple).

5 Cette classe est assez lourde mais elle permet ensuite de manipuler avec aisance les différentes séries de nombre, d importer rapidement une série, etc. class Trajectory, Degen eratedtraject ory, Sample L objectif lors de la mise en place de ces classes qui héritent de V était principalement (tout du moins pour Trajectory et DegeneratedTractory) de permettre un typage fort : ces classes n apportent rien en soi mais permettent d éviter des erreurs par la suite en confondant des données de nature différente. Un objet de type Trajectory correspond à la réalisation (à tous les instants) d un processus stochastique (au sens d'une variable aléatoire indexée par une famille représentant le plus souvent le temps). DegeneratedTrajectory constitue un cas particulier où il n y a qu une seule valeur (il s agit donc de la réalisation d une variable aléatoire ; la bonne manière de l envisager est en fait de considérer qu il s agit d une trajectoire «dégénérée» dans le sens où elle ne contiendrait plus que son dernier élément). La distinction entre les deux vient du fait que les payoffs de certains instruments financiers sont path-independant et posséder toute la filtration est inutile : on peut se contenter de la valeur terminale. Une relation d héritage simple entre Trajectory et DegeneratedTrajectory respectant le principe de substitution de Liskov (si une propriété est vérifiable pour tout élément de type «mère», elle doit encore l être pour tous les éléments de type «fille» qui héritent du type parent) : certains payoffs path-dependant ne sont pas calculables sur un point unique, à l inverse la propriété «1 == size()» empêche Trajectory d hériter de DegeneratedTrajectory. Il est donc plus logique de considérer les deux classes comme formant une partition (attention : il n est pas non plus vérifié dans le code de Trajectory que la taille est plus grande que 1!) d un ensemble plus large ici non défini car les 2 classes n ayant de toute façon aucunes méthodes, cela aurait été inutile. En toute logique, un cast de Trajectory en DegeneratedTrajectory doit pouvoir être possible (au prix d une perte d information, évidemment) : c est ce qu effectue la définition de Trajectory::operator DegeneratedTrajectory(). Ce cast est même nécessaire par la suite, lorsque nous verrons que la classe PathIndependantPayoff peut être utilisée avec des Trajectory* comme des DegeneratedTrajectory*, dans le premier cas un cast est effectué pour se ramener au second. La classe Sample n est pas d une nature fondamentalement différente d un point de vue purement informatique puisqu il s agit toujours d un tableau contenant des valeurs de type double. Il s agit néanmoins d un objet orthogonal aux deux précédents dans la mesure où un échantillon est censé contenir différentes réalisations indépendantes d une variable aléatoire. Deux méthodes permettant l obtention de la moyenne et de la variance (calculée par le théorème de König-Huygens) sont implémentées. class RandomGenerator La méthode de Monte Carlo étant statistique par nature, il est important de disposer d une source fiable de nombres aléatoires. En réalité il s agit bien évidemment de nombres pseudos-aléatoires puisqu on ne dispose pas d une vraie source d entropie. La nature réellement aléatoire n est au final pas si essentielle que ça dans le contexte d une simulation de Monte-Carlo : dans le cas des méthodes dites de «Quasi»-Monte Carlo, on emploie même des suites (entièrement connues, donc) dites à discrépance faible : les nombres tirés occupent uniformément l espace que l on souhaite (de façon plus rigoureuse : la probabilité de tirer un nombre dans un certain ensemble est presque égale au ratio de la mesure de cet ensemble sur la mesure de l ensemble total). La classe RandomGenerator définit simplement une interface via sa méthode Next() mais est abstraite. class UniformGenerator Il s agit à nouveau d une classe abstraite dont deux classes héritent : LinearCongruentialGenerator et MersenneTwisterGenerator. Les deux classes sont similaires à ce qui avait été vu à ce sujet en TD. La première classe implémente une suite d ordre 1, la congruence du terme précédent (à un multiplicateur et un incrément près) modulo une troisième constante, donnant le terme suivant. Les propriétés peuvent fortement varier d un choix de constantes à un autre, pour certaines valeurs ces propriétés sont très bien étudiées.

6 La seconde classe n est qu une encapsulation d une implémentation de l algorithme MersenneTwister, codée en C++ par Richard J. Wagner de l Université du Michigan, ici réutilisée. L algorithme est très réputé car sa période est très grande ( ), tous les bits sont aléatoires (contrairement au cas précédent où pour certains paramètres les bits de poids faible ne le sont pas!), le calcul n est pas plus long que pour d autres générateurs, et enfin le nombre de dimensions choisies peut être élevé, ce qui se révèle important dans le cas des méthodes de Monte Carlo. class GaussianGenerator Classe abstraite, GaussianGenerator définit la méthode Next(void) relativement à une nouvelle méthode virtuelle pure : Next(double, double). Il est désormais question de la génération de nombres aléatoires suivant une loi normale ; celle-ci admettant deux paramètres que sont l espérance et la variance, on déclare donc cette nouvelle méthode acceptant les paramètres moyenne et variance écart-type (par convention ; il aurait bien été possible de choisir la variance, mais cela aurait nécessité le calcul supplémentaire d une racine carrée). La classe Next(void) est déclarée par l héritage de RandomGenerator et définie comme un appel à Next(0,1) : il s agit en quelque-sorte de valeurs par défaut. Ici également, il aurait été tout autant possible de procéder à l inverse : en définissant la méthode Next(double mu, double sigma) comme retournant «mu+sigma*next(void)», et en faisant de Next(void) une méthode virtuelle pure. Deux classes héritent de GaussianGenerator et constituent deux implémentations différentes de la génération de nombres aléatoires selon une loi normale. Dans les deux cas, il faut au départ posséder une source de nombres aléatoires suivant une loi uniforme, d où le pointeur vers une instance de UniformGenerator dans le constructeur de la classe GaussianGenerator. La première méthode, dite de Box-Muller revient simplement à dire que si l on choisit indépendamment un rayon suivant une loi exponentielle de paramètre 1/2 (obtenue depuis une loi uniforme par la méthode de la transformée inverse), et un angle suivant une loi uniforme sur tout le cercle, alors les coordonnées cartésiennes du point ainsi obtenu suivront toutes les deux une loi normale centrée réduite. Elles seront de plus indépendantes entre elles. La seconde méthode, dite de Marsaglia, est très proche de la première mais on tire cette fois-ci au hasard des points dans le cercle unitaire par le biais de leurs coordonnées cartésiennes. On peut ensuite calculer le rayon, et s affranchir des fonctions trigonométriques en les écrivant comme le rapport des coordonnées cartésiennes sur le rayon. Chacune des deux méthodes possède des inconvénients : dans le premier cas le recours à des fonctions trigonométriques représente une perte de performance ; la valeur de π, nécessaire pour tirer un angle uniformément autour du cercle, est d ailleurs exprimée comme la solution de l équation cos x 2 = 0, c'est-à-dire au travers des fonctions trigonométriques réciproques : «double const m_pi = 2 * acos(0.0)». Dans le second cas, le ralentissement réside dans le tirage au hasard d un point dans le cercle, qui se fait par la méthode d acceptation-rejet: on tire au hasard un point dans le carré [(-1 ;- 1) ;(1 ;1)] et on rejette les points dont la distance au centre est plus grande que l unité. Cela augmente donc le nombre de tirages nécessaires d un facteur 4/π. Dans la pratique, la répartition des temps de génération obtenus sont visibles dans le graphique : on tire un million de nombres aléatoires suivant une loi normale centrée réduite, une centaine de fois selon chacune des deux méthodes. La méthode de Box-Muller (en bleu) offre un temps moyen de 219 ms contre 281 ms pour celle de Marsaglia (en rouge): la seconde méthode entraine expérimentalement un surcoût de l ordre de 28%... soit à peu de choses près 4 π 1 ( 27.3%). Le calcul des fonctions trigonométriques est donc négligeable en termes de temps, par rapport au surcoût de l acceptation rejet.

7 Notons que dans les deux façons de procéder, la méthode permet d obtenir «simultanément» deux nombres aléatoires (le coût de calcul pour obtenir le 2 ème est beaucoup plus avantageux que celui pour obtenir le 1 er ) indépendants, quoi qu on veuille (même si l on n en souhaite qu un seul) : il est donc important de mettre en place un système de cache, afin de ne pas gaspiller ce 2 ème nombre obtenu presque «gratuitement». C est mis en place au travers d un membre privé de l instance de classe. Un booléen (également privé) permet de tester en début de demande d un nouveau nombre aléatoire s il y a besoin d en calculer une nouvelle paire ou bien s il suffit de renvoyer celui déjà stocké lors de l appel précédent. class BlackScholes Cette classe être chargée de renvoyer les valeurs simulées d un actif financier, que l on fait évoluer selon le modèle de Black-Scholes. Les paramètres du modèle doivent être passés en paramètre au constructeur : la valeur initiale de l actif, ainsi que sa volatilité et son trend. Il faut également fournir un pointeur vers une instance de GaussianGenerator pour que le BlackScholes soit en mesure d évoluer de façon aléatoire. Dans cette classe de base, on peut obtenir une valeur en appelant la méthode NextValue() qui prend en paramètre un double représentant le temps qui sépare le nouvel instant demandé de l instant précédemment calculé («dt»). Il s agit d une classe abstraite car cette méthode n est pas explicitée (=0). Il est également possible de faire appel à la méthode GetT() qui renvoie la somme des «dt» passés successivement en paramètre. Enfin, tout peut être réinitialisé aux valeurs de départ avec Reset(). Les deux classes qui héritent de la classe BlackScholes de base représentent deux façons différentes d utiliser le modèle : La classe BlackScholesSDE permet de simuler l évolution pas à pas de l actif, grâce à l équation stochastique habituelle du modèle. La mise en place numérique n est pas rigoureuse : on approche simplement dwt par une gaussienne centrée et de variance dt : on passe en couple de paramètres «(moyenne, écart-type)» les valeurs «(0, dt)». L équation différentielle stochastique donnant l évolution de l actif par rapport à sa valeur précédente, la dernière valeur calculée est stockée en membre privé. Les valeurs ainsi obtenues vont dépendre du pas de temps, ce qui peut être problématique. Le graphique présente à titre d exemple neuf trajectoires simulées grâce à BlackScholesSDE :

8 La classe Lognormal est une façon plus rapide d obtenir une variable aléatoire à un instant donné : il s agit de l équation précédente résolue analytiquement : cela «accélère e» donc le calcul puisqu on connait l expression à tout instant T de l actif, sans connaitre les instants précédents : celui-ci suit une loi lognormale. Pour pouvoir hériter de la classe Blackscholes, il est toujours possible d «avancer» par petits «dt» au travers de la méthode NextValue(), mais une nouvelle méthode Value() est donc offerte. class Payoff Une dernière brique de l édifice est manquante avant de pouvoir effectuer les calculs souhaités : il faut encore une hiérarchie de classes pour les produits dérivés : ceux-ci font tous hériter de la classe abstraite Payoff. Leur point commun : la classe Payoff impose la surcharge de l opérateur (Trajectory*) : il s agit après tout d une méthode comme une autre, le choix aurait pu se porter vers un autre nom, mais il est assez satisfaisant de pouvoir «appliquer» le Payoff comme une fonction. Il faut toutefois penser à déréférencer au préalable, si on dispose d un pointeur vers une instance de Payoff, et on se retrouve le plus souvent avec une écriture de la forme «(*pp)(pt)» où pp est un pointeur vers un Payoff et pt un pointeur vers une Trajectory. Une classe abstraite qui hérite de Payoff est la classe des PathIndependantPayoff, dont le nom est explicite. Il est logique de pouvoir calculer ce type de Payoff à partir d une trajectoire toute entière (d où l héritage), mais une nouvelle surcharge de l opérateur () est effectuée, cette fois-ci pour des paramètres de type DegeneratedTrajectory*. On autorise donc l appel du calcul pour des trajectoires ne comportant que leur point final. Il n était pas nécessaire à tout prix d effectuer ce cloisonnement, mais en toute logique, il est préférable de maintenir le typage déjà initié à tous les niveaux du projet. Les classes Call et Put héritent toutes deux de PathIndependantPayoff puisque ces deux produits dérivés ne rémunèrent qu en fonction de la valeur à maturité du sous-jacent, et d un certain paramètre qui leur est propre : le Strike, passé en paramètre du constructeur. En revanche, d autres produits plus complexes sont des descendants de Payoff «path-dependant», par opposition aux précédents : sont ainsi implémentés les options dites «Parisiennes» dont le payoff est nul si le temps consécutif passé au dessus d une certaine barrière est supérieur à un certain seuil, ou encore les options «Parasiennes», semblables aux précédentes, hormis le fait que le temps passé au dessus de la barrière n est pas remis à zéro si l actif repasse en dessous. Il s agit donc du temps cumulé au dessus de la barrière qui peut provoquer l annulation du payoff. Ces options à barrière ont pour principal objectif d éviter les manipulations de marché autour d une date donnée : un acteur au poids important pourrait par exemple effectuer des transactions en grandes quantités sur le sousjacent afin d être gagnant sur des produits dérivés achetés ou vendus à une certaine maturité. Si désormais le paiement de ces dérivés ne dépend pas seulement de la valeur à un instant donné mais de toute la trajectoire, il est beaucoup plus difficile de «tricher» ainsi. Sont également implémentés des options dites «Lookback» dont la valeur est le max de la valeur des options vanille prises sur l ensemble des échéances inférieures ou égale à la vraie échéance. class MonteCarlo La classe MonteCarlo fait appel aux classes de base présentées plus haut : son constructeur requiert un pointeur vers un Range, un pointeur vers un modèle BlackScholes, et un dernier pointeur vers un Payoff. L utilisation de pointeurs pour les paramètres a une influence négligeable dans la mesure les objets maniés ne sont pas d une taille très importante en mémoire, néanmoins il n y a ainsi pas de copies inutiles d objets en mémoire qui soient effectuées. Deux boucles sont imbriquées dans le «cœur» de la classe MonteCarlo, c'est-à-dire sa méthode Run() : la boucle externe effectue autant de tours que l appel de la méthode l a demandé, en passant un nombre de simulations à effectuer en paramètre. Pour chaque simulation effectuée, une boucle interne parcourt les états de temps, dont les différentes étapes sont fournis par le Range, et dont le différentiel dt est fourni en paramètre à l appel de la méthode NextValue() du BlackScholes. Après la dernière étape c'est-à-dire à la sortie de la boucle interne, l adresse mémoire de la trajectoire ainsi simulée est passée en paramètre au payoff, et la valeur renvoyée est placée dans l échantillon instanciée au début de la méthode. A la sortie de la boucle externe, les moments empiriques de l échantillon peuvent être calculés et renvoyés. La classe QuickMonteCarlo hérite de MonteCarlo et surcharge la méthode de simulation Run() afin d être «spécialisée» pour les PathIndependantPayoff. Il est en effet à priori inutile de chercher à connaitre la valeur à tous les instants intermédiaires, il y a donc

9 plus la boucle interne exposée précédemment et à la place, la valeur finale est calculée grâce à un pointeur vers une instance de Lognormal (fourni en paramètre au constructeur). Cette valeur est ensuite passée en paramètre au DegeneratedPayoff (dont un pointeur avait également été fourni en paramètre du constructeur de QuickMonteCarlo). Pour résumer, il s agit vraiment d une spécialisation de la classe précédente dans la mesure où les paramètres héritent tous des paramètres précédents, dans la hiérarchie des classes du projet, et simplement l étape de calcul est simplifiée en supprimant une boucle inutile dans le cas qui nous intéresse. class Tests Afin de pouvoir tester facilement les nombreuses classes, il est intéressant d écrire des fragments de programme dans un but bien précis, afin de tester spécifiquement telle ou telle portion du code. Mieux vaut les rassembler dans une classe afin d éviter la tentation de les écrire dans le main par exemple, puis de les supprimer l instant d après lorsqu on teste une autre portion du code. Les tests écrits précédemment peuvent ainsi être réutilisés par la suite si le besoin s en fait sentir. La classe Tests n a nullement besoin d être instanciée et toutes ses méthodes seront donc statiques. Elle agit uniquement comme «conteneur», les fonctions membres n ont pas besoin d accéder à des membres privés. Les tests sont regroupés par catégories (pour pouvoir être appelés en bloc plus proprement au sein d autres méthodes, aux nombres de 5 : BaseTests(), RNGTests(), BSTests(), PayoffTests(), MCTests(). Chaque catégorie de tests exportent ses sorties dans des fichiers textes nommés «_out-.txt» afin de pouvoir récupérer plus facilement les sorties dans un autre logiciel, par exemple, les sorties de RNGTests et BSTests peuvent être exploitées sous R au moyen d un fichier également fourni. En revanche, les sorties de BaseTests, PayoffTests et MCTests sont d avantage à consulter à la main (la 1 ère des 3 ne disposant que de peu d intérêts, elle était surtout utile à des fins de débuggage). Attention, RNGTests() est longue à s exécuter en raison du grand nombre de valeurs générées et est donc commentée dans le main(), diminuer les valeurs numériques ou bien préparer du café avant de l exécuter (L étape la plus longue consiste justement à chronométrer le tirage de quantités importantes de nombres aléatoires afin de comparer les vitesses d exécution). class Pipe Cette classe est simplement la réponse au besoin pragmatique de pouvoir rediriger à souhait les sorties, notamment dans le cas des Tests (cf. précédent). Il est possible, grâce aux méthodes des objets de type stream de la librairie standard, d accéder en lecture et en écriture à leurs buffers (rdbuf, appelé respectivement sans ou avec paramètre). La classe Pipe lorsqu elle est instanciée va copier l adresse du buffer de la sortie standard (std::cout) dans un membre privé et affecter comme nouveau buffer celui créé par l ouverture en écriture d un flux vers un fichier, le destructeur sera en fin de vie de l instance chargé de rétablir le buffer d origine de la sortie standard. Il serait possible de switcher les buffers directement dans le corps d une fonction, l inconvénient étant qu en pareil cas, si jamais une exception est levée entre les deux inversions de buffer, le changement ne sera jamais rétabli! Bien que le projet ne comporte aucune levée d exceptions, il n est sans doute jamais trop tôt pour écrire du code exception-safe. L utilisation de la classe Pipe se fait très simplement : il suffit d instancier avec en paramètre du constructeur un nom de fichier (si celuici comporte des «/», le dossier doit être déjà existant, en revanche le fichier sera créé s il est inexistant, et le mode d ouverture du flux choisi (std::ios::trunc) fera que le contenu préexistant du fichier sera écrasé. Pour donner fin à la vie d un objet de type Pipe, le plus trivial demeure de jouer avec le scope en instanciant au sein d un bloc d accolade(«{ }»), qu il suffit ainsi de refermer pour faire disparaitre le Pipe, et donc ré inverser les buffers de la sortie standard. La fonction main() donne un exemple d utilisation : chaque test est appelé au sein d un bloc d accolade au sein duquel est également instancié un Pipe au préalable, afin que tous les tests produisent leurs sorties de façons individuelles dans des fichiers séparés. Le besoin d utiliser une autre sortie que la sortie standard se fait rapidement sentir si les sorties sont importantes en volume, en effet la console, sous Windows, dispose elle-même d un buffer limité qui censure la sortie aux dernières dizaines de lignes. Il est possible de rediriger la sortie du programme en dehors du programme lui-même («mcvr.exe > mcvr.txt» par exemple) mais le plus simple était donc de le traiter à l intérieur du programme. Par ailleurs les sorties étant ici le plus souvent constituées de simples valeurs numériques, il est

10 difficile de les distinguer si elles sont consécutives dans un même fichier, d autre part ajouter autre chose que les valeurs numériques en guise de «séparateur» complique l importation des données dans un autre logiciel, d où l utilité de les exporter dans des fichiers distincts. class Chrono La classe Chrono fait appel à la librairie time.h afin de mesurer l écart entre deux instants (la fonction GetTickCount() qui renvoi l uptime de la machine est également utilisable à cette fin mais elle est spécifique de l API Windows). L instanciation déclenche automatiquement une mesure de l «heure», on peut ensuite avoir le différentiel avec l heure courante à tout instant, en appelant la méthode Elapsed(), et enfin le comportement par défaut (modifiable en passant 0 en paramètre au constructeur) est d envoyer sur la sortie standard le résultat d un appel à cette méthode Elapsed() lors de l appel du destructeur. L objectif est de permettre une utilisation aussi simple que pour les objets de type Pipe, en effectuant l opération souhaitée (c'est-à-dire chronométrer une opération et afficher le résultat) simplement au moyen du maniement du scope, en disposant des accolades autour de l instanciation et des opérations à chronométrer. Difficultés rencontrées Les difficultés ont été assez nombreuses, notamment à cause des spécificités du C++ qui en font un langage très technique. La première (quantitativement) source de maux de tête a été de trouver (de façon stable ) une hiérarchie de classes satisfaisant toutes les contraintes ; la dualité entre les Payoffs path-dependant ou non ayant été la source de plus de difficulté concernant l organisation des relations d héritages. Le changement de la hiérarchie est assez lourd et aurait été facilité en utilisant des outils de refactoring ; il aurait également été possible de construire en premier lieu le diagramme de classe puis de générer un squelette vide, mais il est difficile d imaginer les directions que l on va prendre car c est parfois en essayant une implémentation que l on doit tout changer. Les paramètres par défaut sont triplement piégeurs il faut soit les choisir judicieusement soit ne pas les oublier : ainsi la taille par défaut de Sample était initialement fixée à 1 ce qui était problématique et rajoutait des éléments arbitraires lors de certaines boucles, sans pour autant provoquer d erreur visible directement! Les paramètres par défaut complexifient par ailleurs l écriture des constructeurs en cas d héritage, si on souhaite maintenir une certaine cohérence. Enfin, lorsque les paramètres en question sont des pointeurs, je n ai pas trouvé de solution permettant d inscrire un delete dans le destructeur «uniquement» dans le cas où la valeur par défaut a été utilisée : c'est-à-dire qu il ne faut pas effectuer un delete si l appel est légitime, mais dans le cas inverse l objet créé n est jamais supprimé (à priori? mais ce point là est peut être faux, je n ai pas réussi à trouver de réponse). L oubli du mot clé virtual est absolument traitre, il s agit sans doute d une des erreurs la pire à corriger! Ce fut particulièrement «horrible» lors de l omission de ce mot devant la déclaration de BlackScholes::Reset(), des processus différents générés avec la même instance se «poursuivaient» donc mutuellement au lieu d être indépendants! Il faut également connaitre toutes les subtilités du langage : lorsque deux classes s incluent mutuellement dans leurs définitions. Ça n est pas le cas dans la version définitive de la hiérarchie de classes retenues, mais ce fut temporairement le cas à une étape intermédiaire du projet où DegeneratedTrajectory et Trajectory étaient davantage liées, le problème se résout très facilement (à condition de connaitre l astuce), en ajoutant une déclaration incomplète, «class DegeneratedTrajectoy ;» dans Trajectory.h par exemple La surcharge des opérateurs de recopie/assignation dans la classe V n a pas été implémentée dès le début, provoquant de magnifiques segfault allant jusqu à planter à répétition Visual Studio, expérience douloureuse s il en est lorsqu on cherche la cause du bug L utilisation du type unsigned, au départ pour coller à un type de la GSL (qui n est pourtant plus utilisée dans le projet) s est révélée lourde puisque pour éviter les cast, toutes les boucles ou presque font appel à des types unsigned, qui ne posent pas d inconvénient en soi mais il aurait sans doute été plus simple de se conformer au type int, plus standard ; le gain d un facteur 2 lié à l utilisation d un type unsigned est inutile compte tenu de la nature des variables utilisant ce type : il s agit de compteurs dans des boucles et de dimensions de vecteur.

11 D autre part, les erreurs d arrondis sont à prendre compte consciemment, ou bien les erreurs sont catastrophiques, il faut donc se détacher de l arithmétique purement «mathématique» pour envisager la précision réelle d un ordinateur. Ainsi, la méthode Range::Next() était prévue à l initiale pour «boucler», et revenir sur le premier élément après avoir atteint le dernier. Ceci était fait grâce à l instruction suivante : «current = (current>ubound+1e-4)?lbound:current», au départ sans la portion soulignée (qui représente un ε, une quantité «négligeable»), ce qui s est révélé problématique car la condition était sous-évaluée et il était possible d arriver au bout de l objet sans que la condition écrite sous cette forme ne le détecte. Cette fonctionnalité de bouclage de toute façon été supprimée car inutile pour le reste. En guise de conclusion, on peut dire que la plupart des cauchemar du programmeur en C++ se sont «instanciés», et le debugger est une aide inestimable dans ces situations, il ne faudrait dans l idéal jamais hésiter avant de le lancer car le temps perdu à naviguer de ligne en ligne est très largement rattrapé en permettant l identification efficace des bugs s il est utilisé à bon escient. Limites du projet La première d entre elle a justement été de définir des limites, il est parfois tentant de tout reconstruire ; mais cela se ramène parfois à ouvrir la boite de Pandore : comme pour élaborer une tour de sable où le volume de grains à apporter exploserait avec la hauteur du tas désiré, monter le projet en hauteur peut nécessiter d élargir très fortement la base. Les opérateurs de recopie et d assignation de certaines classes devraient être redéfinis, ou il faudrait tout du moins passer ceux par défaut en private ou protected pour éviter leur utilisation. Copier une instance de Blackscholes doit par exemple produire des résultats aberrants en raison de la présence d un pointeur parmi les membres. Certains algorithmes sont loin d être optimaux d un point de vue temps de calcul, les tests effectués dans le cas des produits «exotiques» sont en partie redondants et une logique plus poussée avec des boucles while permettrait de gagner des étapes dans certains scénarios. Aucune gestion des erreurs n est effectuée : il faut en particulier bien veiller à ce que les fichiers d input nécessaires notamment dans le test des Payoffs («_in-payoff-_.txt») soient présents dans le path, c'est-à-dire à côté des fichiers sources lorsque le programme est lancé depuis Visual Studio, ou dans le sous-dossier Debug ou Release si on lance l exécutable à la main depuis ce dossier. Sinon, un vecteur de taille nulle sera généré sans avertissement mais sera problématique dans la suite de l exécution. Il n y a pas d exceptions levées même leur éventuelle future implémentation est prise en compte : la recopie d un V se fait via un swap censé être fail-safe pour éviter de se retrouver dans une situation «batard». D autre part la redirection des sorties standard est réversible en cas d erreur entre le début et la fin, grâce à l instanciation dédiée d une classe Pipe. Certaines réorganisations seraient possibles, on pourrait par exemple imaginer Range comme hérité de V, ce qui permettrait notamment de gérer des valeurs intermédiaires autres que régulièrement espacées. Il serait par ailleurs intéressant de mettre en place des méthodes de réduction de variance comme c était le cas au départ, afin de comparer le temps qu il est possible de gagner. L ensemble du projet est disponible à l adresse suivante : Il existe notamment un serveur SVN où la source a été mise à jour avec plus ou moins de régularité (les releases antérieures ne compilent pas toutes : il s'agissait davantage de pouvoir sauvegarder et réutiliser le code d un poste de travail à l autre).