# BDA Projet 2021 (Group E)
**Auteurs** : Favre Léonard, Tran Eric, Willy Sylvain
**Date** : 12.06.2021
# Introduction
Dans le cadre de notre cours de master *Big Data Analytics* à la [HES-SO](https://www.hes-so.ch/master), nous avons étudié et mis en pratique l'évalutation de risques financiers à l'aide de la méthode de Monte-Carlo.
Ce projet est l'application du chapitre 9 du livre *[Advanced Analytics with Spark](https://www.oreilly.com/library/view/advanced-analytics-with/9781491912751/)* par Sandy Ryza, Uri Laserson, Sean Owen, Josh Wills.
La réalisation du projet peut être découpée en trois phases :
1. Comprendre la théorie fournie et le jeu de données associées avant de formuler trois questions qui deviendrons nos axes d'études.
2. Mettre en place un environnement de développement fonctionnel sur la base d'un code fourni sur un dépôt github.
3. Étendre les fonctionnalités du code fourni pour analyser les données et répondre aux questions que nous nous sommes posées.
# Théorie
## VaR et CVaR
En finance, on utilise l'indicateur statistique de la *Value at Risk* (VaR) pour mesurer la probabilité de perdre une somme. Il s'agit d'estimer cette probabilité sur une période de temps donné selon un portefolio d'actifs avec une certitude fixée à l'avance.
Par exemple, on peut s'intéresser à la probabilité de perdre plus d'un million de dollars américains, en une semaine, pour un portefolio d'action en bourse, en acceptant 5% de probabilité d'erreur.
Cette valeur indiquant (par définition) une probabilité de perte, elle peut avoir une valeur négative. Cela indique alors non seulement que la probabilité de perdre de l'argent est inférieur à 5% mais aussi qu'un gain est prévu.
Une deuxième mesure similaire est la *Conditional Value at Risk* (CVaR), qui est une variante de la VaR qui défini la probabilité moyenne de perdre un capital donné dans les X% pire cas définis.
# Mise en place de l'environement de développement et problèmes liés
Les analyses financières font, en général, intervenir une très grande quantité de données. Souvent plus qu'il est raisonable - voire possible - de gérer sur une unité de calcul. Dans le cadre de notre cours *Big Data Analytics* nous avons appris à utiliser le framework Spark qui permet de distribuer des tâches ou des calculs sur un cluster (ensemble) de machines.
Spark peut être utilisé dans de nombreux langages de programmation tels que Python, Scala et bien d'autres.
Dans la continuité du code fourni avec le livre sur lequel ce projet est basé notre projet est écrit en Scala. Il s'agit, de plus, du langage utilisé dans les exercices de notre cours.
## Scala, Maven et la JVM
Scala est un language de programmation qui se base sur la machine virtuelle de Java ([JVM](https://fr.wikipedia.org/wiki/Machine_virtuelle_Java)). Bien que l'outil de gestion de projet conventionel du Scala soit [sbt](https://www.scala-sbt.org/), il est possible et courant d'utiliser les solutions du monde Java telle que Maven comme c'est le cas dans ce projet.
Après avoir cloné le dépôt github permettant de démarrer le projet [https://github.com/sryza/aas](https://github.com/sryza/aas), nous avons essayé de le faire fonctionner en l'état et avons rencontré plusieurs problèmes.
### Version de Java
Durant les laboratoires effectués dans le cadre de ce cours, nous avions utilisé une version relativement récente de sbt et non pas Maven. Notre première déconvenue a été de découvrir que des erreurs de compilations apparaissaient en lien avec des librairies non-existantes. Il nous a fallu un temps conséquent pour comprendre que le problème venait de la version de la JVM et non des dépendances du projet fournit de base. Ce dernier ne fonctionne pas avec une version du JDK supérieure à la version 8. Nous avions fait fonctionner les laboratoires précédants avec OpenJDK-11, il nous a donc fallu installer la version OpenJDK-8 pour pouvoir faire fonctionner ce projet-ci.
Il est à noter que cela contredit le readme du dépôt github mentionnant :
> Apache Maven 3.2.5+ and Java 8+ are required to build.
### Version de Spark
Une fois le problème de la version de java résolu, la compilation a pu démarrer mais s'arrêtait brusquement dû a des dépendances manquantes avec la librairie Spark. Là aussi, il s'agissait d'un problème de version et non pas de dépendance. Au lieu d'utiliser la dernière version à la date de ce projet (3.1.1) nous avons dû installer la version majeure précédente (2.4.8) sur nos environements de développement respectifs.
Comme pour le point précédent, il est à noter que les instructions du dépôt GitHub ne donnent pas la bonne indication. Il est en effet démandé d'installer la dernière version de Spark :
> Install [Apache Spark](https://spark.apache.org) for your platform, following the instructions for the [latest release](https://spark.apache.org/docs/latest/).
## Programme non "serialisable"
Nous avons rencontré une exception de type "Object not-serializable" car la classe RunRisk n'étendait pas la classe Serializable. Cette opération est nécessaire pour permettre passer la compilation du programme.
```scala
class RunRisk(private val spark: SparkSession) extends Serializable {
...Code omis...
}
```
## Fichiers vides
Le programme fourni de base ne permettait pas de traiter de manière propre les fichiers vides. Lorsque le programme rencontrait un fichier vide contenant uniquement les entêtes, un "null-pointer exception" était jeté et faisait planter le programme. Nous avons donc dû implémenter des contrôles stricts permettant de mettre de côtés tous les fichiers vides.
```scala
def readGoogleHistory(file: File): Array[(LocalDate, Double)] = {
val formatter = DateTimeFormatter.ofPattern("d-MMM-yy")
val lines = scala.io.Source.fromFile(file).getLines().toSeq
// Contrôle ajouté pour la gestion des fichiers vides
if(lines.size < 2 )
throw new IOException("Empty file")
lines.tail.filter(!_.contains(",-")).map { line =>
val cols = line.split(',')
val date = LocalDate.parse(cols(0), formatter)
val value = cols(4).toDouble
(date, value)
}.reverse.toArray
}
def trimToRegion(history: Array[(LocalDate, Double)], start: LocalDate, end: LocalDate)
: Array[(LocalDate, Double)] = {
var trimmed = history.dropWhile(_._1.isBefore(start)).takeWhile(x => x._1.isBefore(end) || x._1.isEqual(end))
if (trimmed.length == 0) { // Le programme ne traite pas le cas limite où l'historique peut potentiellement être vide.
Array()
} else {
if (trimmed.head._1 != start) {
trimmed = Array((start, trimmed.head._2)) ++ trimmed
}
if (trimmed.last._1 != end) {
trimmed = trimmed ++ Array((end, trimmed.last._2))
}
trimmed
}
}
```
## Correction des Stocks (valeurs NaN)
Lors du pré-traitement des stocks, certaines valeurs obtenues sont des NaN qui ne sont pas écartées dans le programme de base. En gardant ces valeurs NaN, on fausse la valeur de retour de la simulation et l'opération de calcul du quantile plante car il n'arrive pas à traiter ce type de valeurs.
```scala
def trialReturn(trial: Array[Double], instruments: Seq[Array[Double]]): Double = {
var totalReturn = 0.0
for (instrument <- instruments) {
val returnVal = instrumentTrialReturn(instrument, trial)
if (!returnVal.isNaN) { // Permet d'éviter d'additionner des valeurs NaN et transformer notre valeur de retour en NaN.
totalReturn += returnVal
}
}
totalReturn / instruments.size
}
```
# Description du projet
Cette section décrit le projet selon la structure exigée :
1. Description du jeu de donnée (taille, informations)
2. Description des fonctionnalités / pré-traitement pour extraire des informations supplémentaires
3. Questions traitées durant le projet
4. Algorithmes utilisés
5. Optimisations implémentées
6. Validation des évaluations
7. Résultats obtenus
8. Améliorations futures
## Partie 1 : Description du jeu de donnée (taille, informations)
### Quel type d'informations contient le jeu de donnée ?
Les informations traitées sont de deux types :
- Marchés boursiers : état interne du marché
Les fichiers des marchés boursiers contiennent chacuns les données historiques d'un actif financier spécifique.
- Facteur de marché : informations externes ou indirectes sur le marché.
Les facteurs de marché permettent d'inférer l'état global du marché et d'en déduire l'impact sur les actifs du portfolio.
Le deux jeu de données contienent les informations suivants :
- Date : Date de l'entrée.
- Open : Valeur de l'action à l'ouverture.
- High : Valeur de l'action au plus haut durant la période d'ouverture.
- Low : Valeur de l'action au plus bas durant la période d'ouverture.
- Close : Valeur de l'action à la fermeture.
- Volume : Nombre de transactions effectuées durant la période d'ouverture.
- Adj Close : Valeur de l'action à la fermeture ajustée selon différents paramètres.
Exemple de contenu d'un fichier de donnée :
```
Date,Open,High,Low,Close,Volume,Adj Close
2014-10-24,554.98,555.00,545.16,548.90,2175400,548.90
2014-10-23,548.28,557.40,545.50,553.65,2151300,553.65
2014-10-22,541.05,550.76,540.23,542.69,2973700,542.69
2014-10-21,537.27,538.77,530.20,538.03,2459500,538.03
2014-10-20,520.45,533.16,519.14,532.38,2748200,532.38
```
## Partie 2 : Description des fonctionnalités/pré-traitements utilisés pour extraire des informations supplémentaires
On considère que les opérations de types "pré-traitement" sont toutes les opérations effectuées avant l'étape de distribution des calculs entre les "workers".
### Calcul de l'évolution de l'action
Le programme fourni de base réalise un pré-traitement sur les actions (stocks) pour calculer le mouvement de l'action au lieu de sa valeur absolue à un temps donnée. Cette opération est réalisée car le calcul de la VaR se base sur la perte d'investissement sur un temps donné. C'est pourquoi il est plus pratique de calculer directement le mouvement de l'action plutôt que sa valeur absolue et par la suite calculer la différence.
### Calcul du poids des facteurs du marché de manière non-linéaire
Etant donné que les facteurs du marché ont potentiellement un impact sur les actions, le poids des facteurs qui sont linéaires de base, sont utilisés sur le modèle de prédiction des actions et doivent être non-linéaires pour simuler au mieux le comportement du marché boursier. Ceci est nécessaire étant donné que le marché boursier n'est pas linéaire mais a un comportement très volatile.
Pour les rendre non-linéaires, chaque valeur de retour d'un facteur est modifiée en additionnant, à la valeur de base, sa racine carrée et sa mise au carré.
## Partie 3 : Questions traitées durant le projet
### Question 1. Comment la taille du jeu de données impacte-t-elle la VaR (Value at Risk) ?
#### Modification de la question
La question de base était :
> Comment la taille du jeu de donnée impacte-t-elle la courbe d'apprentissage ?
Elle a été modifiée car nous n'avons pas pu implementer l'étude de la courbe d'apprentissage sur la précision du modèle.
#### Méthode et critère
Le jeu de données est découpé par tranche de 5% et la simulation est lancée 20 fois en augmentant la taille du jeu de données par palier de 5%. Pour chaque simulation, les résultats vont être récupérés, notamment la VaR et CVaR.
### Question 2. Est-ce que la fonction de génération de valeur aléatoire a un effet sur les simulations ?
#### Modification de la question
La question de base était :
> Quel est l'effet de la fonction aléatoire utilisé sur le résultat.
> Trois tests possibles :
> - Mersenne Twister
> - /dev/random
> - liste de nombres générés de manière "plus aléatoire" (génération quantique, etc.)
Nous avons retiré l'utilisation de /dev/random ainsi que de la liste de valeur générés de manière "plus aléatoire" car nous n'avons pas eut le temps de l'implémenter. Nous envisagions d'utiliser un des nombreux services en ligne gratuit offrant des streams de bits provenant de générateurs quantiques. A la place, nous avons ajouté l'utilisation de JDKRandom.
#### Méthode et critère
L'évalutation du risque est calculée une fois avec chaque générateur et les résultats (VaR et CVaR) sont comparés.
- Deux tests possibles :
- MersenneTwiser : Fonction de génération de valeurs aléatoires utilisée de base par le programme.
- JDKRandom : Fonction de génération de valeurs aléatoires existant dans les librairies Java.
### Question 3. A quel point les "market factors" peuvent modifier notre VaR et CVaR ?
#### Modification de la question
La question de base était :
> Quelle est la pertinence des différents facteurs de marché ?
Notre évaluation de base s'était concentrée sur la précision de notre modèle à prédire la valeur de l'action. Cependant, nous n'avons pas eu le temps d'implémenter cette fonctionnalité. Nous avons donc changé notre fusil d'épaule et regardé l'impact sur la VaR et la CVaR
##### Idées de markets factors initiaux :
- S&P
- US GDP
- US Treasury bonds
- Taux de change des devises (USD, EUR, CHF, etc...)
- Prix de l'or
- PIB mondial
- Prix du pétrole
- Prix du Bitcoin
##### Markets factors finalement utilisés :
- Prix de l'or
- Prix du pétrole
Les idées de facteurs initiaux n'étaient pas tous utilisables.
Certains facteur n'existaient pas (dans nos sources) dans la tranche temporelle considérée pour ce projet (2002-2013) comme par exemple le BitCoin ou l'Euro.
D'autres n'avaientt pas de données à l'échelle journalière comme par exemple le PIB mondial et plus généralement des données non boursières.
Finalement, certains facteurs étaient tous simplement impossibles à trouver dans le bon format.
#### Méthode et critère :
Tester diverses combinaisons de "markets factors" différents et comparer les VaR, CVaR et les intervales de confiances résultantes.
### Question 4. A quel point l'algorithme de Monte-Carlo est-il fiable pour la prise de décision sur la gestion du porte-feuille ?
En raison d'un manque de temps et de la complexité d'évaluation, cette question n'a pas pu être étudiée.
### Question 5. Quel est l'impact du nombre d'itération par simulation sur les valeurs VaR et CVaR ?
Cette question a été ajoutée en remplacement de la question 4 qui a été retirée. Il s'agit de tester plusieurs nombre d'itération différents afin de mesurer leur impact sur la VaR et la CVaR.
## Partie 4 : Algorithmes utilisés
La méthode de Monte-Carlo est une approche probabiliste de la résolution de problème complexe. Il s'agit essentiellement de traiter les variables clés du problème comme des variables aléatoires de distribution connue (ou estimée) et de procéder à de nombreux tirages aléatoires dans un espace correspondant à la définition du problème. On peut alors déduire la probabilité d'occurence de différents scénarios en combinant ces variables aléatoires.
Dans le cadre de ce projet, l'application de la méthode de Monte-Carlo consiste à modéliser chaque actif du portfolio comme un ensemble de *facteurs* de marché représentés par des variables aléatoires. Le livre sur lequel est basé ce projet utilise trois facteurs :
- S&P 500
- NASDAQ
- Prix des bons du trésor US sur 5 et 30 ans
Les évolutions de ces facteurs influencent l'évolution du portfolio. Dans un premier temps, il sera déterminé *comment* leurs évolution impactent les différents actifs.
Ensuite, en générant un grand nombre d'évolution aléatoires de ces facteurs, il est possible d'estimer l'évolution du portfolio pour chacun de ces cas et par la suite déterminer les VaR et CVaR résultantes. Le choix des évolutions, qui est aléatoire, permet de simuler grand nombre de futurs possibles, car l'évolution réelle du marché ne peut être connue à l'avance.
## Partie 5 : Optimisations implémentées
Nous n'avons réalisé aucune optimisation au niveau des opérations dans le code. Cependant nous avons configuré le partitionnement du jeu de données de manière plus optimale pour nos machines personelles (10 partitions au lieu de 1000) et nous avons executé le programme en définissant 10 "workers" lors de l'exécution des simulations.
- Master local[10]
## Partie 6 : Validation des évaluations
### Question 1. Comment la taille du jeu de données impacte-t-elle la VaR (Value at Risk) ?
L'évaluation se base sur l'étude de la courbe de valeur de la VaR et la CVaR selon la taille du jeu de données utilisées.
### Question 2. Est-ce que la fonction de génération de valeur aléatoire a un effet sur les simulations ?
L'évaluation de cette partie consiste à remplacer la fonction aléatoire présente de base dans l'algorithme par d'autres fonctions aléatoires et comparer les résultats obtenus.
La fonction aléatoire présente initialement est l'algorithme Mersenne Twister. Nous avons choisi d'utiliser comme autre algorithme la méthode JDKRandom.
Les valeurs de VaR et CVaR obtenues sont utilisées pour comparer l'effet de l'aléatoir sur l'algorithme.
### Question 3. A quel point les "market factors" peuvent modifier notre VaR et CVaR ?
Afin de tester l'impact des facteurs supplémentaires sur l'évaluation de la *VaR*, nous avons choisi d'intégrer de nouvelles données à celles incluent initialement dans le projet.
Nous avons pris les données sur le site de Yahoo, ce dernier mettant à disposition des données proches du format des données déjà présentent dans le projet.
Nous avons choisi d'ignorer les entrées comportant des valeurs `null`, ne voulant pas fausser les prédictions en les remplaçant par des estimations.
Nous avons également modifié le code afin de permettre la lecture des dates de Yahoo. Ces dernières étaient encodées selon un format différent des données de base.
Nous avons également limité la précision afin d'avoir une similarité avec les données déjà présentes.
Toutes ces modifications sont visibles dans le code suivant :
```
def readGoogleHistory(file: File): Array[(LocalDate, Double)] = {
val formatter = DateTimeFormatter.ofPattern("d-MMM-yy")
val formatter2 = DateTimeFormatter.ofPattern("yyyy-MM-dd")
val lines = scala.io.Source.fromFile(file).getLines().toSeq
if(lines.size < 2 )
throw new IOException("Empty file")
lines.tail.filter(!_.contains(",-")).map { line =>
val cols = line.split(',')
var date = LocalDate.parse("2000-01-01", formatter2)
try{
date = LocalDate.parse(cols(0), formatter)
} catch {
case err: DateTimeParseException => date = LocalDate.parse(cols(0), formatter2)
}
var value = cols(4).toDouble
value = BigDecimal(value).setScale(2, BigDecimal.RoundingMode.HALF_UP).toDouble
(date, value)
}.reverse.toArray
}
```
### Question 5. Quel est l'impact du nombre d'itération par simulation sur les valeurs VaR et CVaR ?
Pour évaluer l'impact du nombre d'itération, nous avons utilisé la VaR et la CVaR en regardant si leur valeur étaient impactées et avons essayé de mesurer cet impact. Il s'agit d'une appréciation subjective.
## Partie 7 : Résultats obtenus
#### Quel est l'impact de l'aléatoire sur les prédictions ?
On peut constater que l'utilisation d'un générateur aléatoire différent n'impact en aucun cas les simulations. En effet, les valeurs sont quasi identiques au niveau de la VaR et de la CVaR.
#### Quel est l'impact du nombre de trials sur les prédictions ?
**1'000'000 de "trials" :**
```
VaR 5%: -0.01571
CVaR 5%: -0.02468
VaR confidence interval: (-0.015826,-0.015597)
CVaR confidence interval: (-0.02479,-0.02457)
Kupiec test p-value: 8.20454E-14
```
**5'000'000 de "trials" :**
```
VaR 5%: -0.01567
CVaR 5%: -0.02461
VaR confidence interval: (-0.01570,-0.01563)
CVaR confidence interval: (-0.02465,-0.02456)
Kupiec test p-value: 8.20454E-14
```
On peut voir que sur les différents résultats obtenus ci-dessus que l'augmentation du nombre d'itération (trials) dans une simulation n'impact en rien le résultat final. On peut voir que la valeur de la VaR, CVaR, des intervales de confiance ainsi que la valeur de test "Kupiec" entre la simulation à 1'000'000 d'itérations et à 5'000'000 d'itérations sont quasi identiques et que la différence est très peu significative.
#### Quel est l'impact de la taille du jeu de données sur les prédictions ?
Utilisation du jeu de données de base, taille initiale de 0 avec incréments de 5% jusqu'à arriver au maximum.
Résultats :
On constate que la taille du dataset impact la VaR et la CVaR relativement fortement au début de l'augmentation de la taille des données utilisées mais commence à se stabiliser rapidement à partir de 750'000 entrées. On peut donc considérer qu'augmenter la taille du dataset n'est pas nécessaire car elle se stabilise assez rapidement.
#### Quel est l'impact des facteurs utilisés pour prédire le comportement du marché ?
Les résultats bruts obtenus sont les suviants :
**Facteurs initialement présents :**
```
VaR 5%: -0.02044
CVaR 5%: -0.03115
VaR confidence interval: (-0.02329,-0.01566)
CVaR confidence interval: (-0.03601,-0.02679)
```
Dans cette situation, on peut voir que la VaR ainsi que la CVaR sont négatives. Cela nous indique que le système prévoit un gain, le portfolio devrait donc gagner en valeur dans le futur.
La CVaR est quant à elle inférieure à la VaR, indiquant aussi un gain potentiellement plus petit. En théorie, on a moins de chance de gagner de l'argent en moyenne que si l'on compare uniquement les pires situations.
Leurs intervales sont respectivement de 0.0076 et 0.0092, on ne peut pas conclure grand chose de ces données pour l'instant mais cela nous sera utile par la suite.
**Facteurs initialement présents + facteurs du prix de l'or**
```
VaR 5%: -0.02398
CVaR 5%: -0.03429
VaR confidence interval: (-0.02602,-0.02067)
CVaR confidence interval: (-0.04074,-0.0299)
```
Lorsque l'on ajoute le prix de l'or, le résultat reste négatif. Cela veut donc dire que les prédictions sont toujours sur un potentiel gain. La VaR et la CVaR deviennent plus petites, le gain en question est donc prédit comme étant plus faible.
L'intervale de confiance de la VaR diminue et baisse à 0.0053 alors que celui de la CVaR augmente à 0.0108. Le calcul de la VaR paraît plus précis ainsi, mais la CVaR ne le serait pas.
Il est difficile de juger plus précisemment la véracité de ces résultats, mais on peut déjà remarquer une influence des facteurs sur le résultat final, ce que l'on s'attendait à observer.
**Facteurs initialement présents + facteurs du prix de l'or + du pétrole**
```
VaR 5%: -0.02249
CVaR 5%: -0.03590
VaR confidence interval: (-0.02803,-0.01970)
CVaR confidence interval: (-0.04174,-0.03130)
```
Là encore, nous observons des différences. La VaR est plus grande que pour le résultat précédent mais toujours plus petite que les valeurs initiales,. La CVaR en revanche est quant à elle encore plus petite que les résultats précedemment trouvés. L'algorithme nous prédit donc toujours un gain sur le portfolio dans la période prédite, mais à priori plus faible.
Les intervales de confiance quand à eux sont plus grand que les facteurs initiaux : 0.0083 pour pour la VaR et 0.0104 pour la CVaR. Les chances d'obtenir des résultats qui varient sont donc un peu plus grandes. Il se peut donc que le prix du pétrole varie plus que les autres facteurs et perturbe les prédictions. Mais, à nouveau, nous ne pouvons en être sûrs sans méthode de vérification de ces prédictions.
Il ne nous suprend pas de remarquer cela, car avec plus de facteur la complexité augmente et il est plus difficile de lier l'évolution des stocks avec des facteurs qui évoluent de manière différentes les uns les autres, même s'il est possible qu'ils soient corrélés.
**Facteurs du NASDAC + de l'or + du pétrole**
```
VaR 5%: -0.016257
CVaR 5%: -0.02696
VaR confidence interval: (-0.019121,-0.013778)
CVaR confidence interval: (-0.03119,-0.02304)
```
Nous avons choisi pour ce dernier test de supprimer des facteurs présents initialement. Le nombre de facteurs utilisés est donc le même qu'au début (3) mais sont de nature différente.
Les résultats diffèrent à nouveau, mais cette fois-ci "dans l'autre sens". La VaR est plus grande qu'initialement et la CVaR également. L'algorithme nous prédit donc des gains plus grands.
Les intervales de confiance sont les plus petits observés jusqu'ici : 0.0053 pour la VaR et 0.0081 pour la CVaR. Comparés aux 3 facteurs initiaux, ceux utilisés ici permettent à l'algorithme de prédire avec plus de précision l'évolution. Cela peut être dû à la corrélation entre les facteurs.
**Conclusion de l'effet des facteurs**
Les résultats obtenus sont intéressants. On peut clairement observer des différences sur les résultats en fonction des facteurs utilisés.
On remarque aussi que, plus il y a de facteurs utilisés, moins le système est confiant de ses prédictions. En effet, en évaluant l'évolution du portfolio en se basant sur l'évolution aléatoire des facteurs, ajouter des facteurs en plus complexifie la prédiction.
Il n'est pas négatif d'avoir des valeurs d'écart plus grandes, c'est normal qu'en ajoutant plus de variables l'algorithme "doute" plus. Le futur des marchés financiers étant incertains de toute manière. Il serait, cependant, intéressant d'obtenir une méthode de validation plus pertinante afin de juger de ces prédictions et ainsi pourvoir sélectioner les facteurs les plus pertinents.
Nous pouvons donc clairement dire que les facteurs influencent le résultat, la VaR et la CVaR ainsi que leurs intervales de confiance. C'est ce que nous voulions vérifier initialement.
## Partie 8 : Améliorations futures
Si nous devions continuer ce projet sur une plus longue période, plusieures améliorations pourraient encore y être apportées.
### Evaluation de la précision du modèle sur les prédictions des actions
Nous pourrions essayer de mesurer la qualité des prédictions. Avec un test prenant en compte l'évolution future du marché, dans notre cas connu (les données utilisées pour ce projet ne s'arrêtant pas au présent mais dans le passé, dans notre cas décembre 2013), il serait possible d'évaluer le VaR et le CVaR exprimé par l'algorithme pour pouvoir évaluer sa pertinence.
En effet, il serait possible d'obtenir les données des marchés durant les 2 semaines qui suivent les prédictions pour comparer les résultats, ou encore utiliser les données déjà en notre posséssion. Il suffit de séparer les données en les arrêtant 2 semaines plus tôt et ainsi utiliser les 2 dernières semaines pour tester la pertinence des résultats.
De plus, lors de la génération des paramètres utilisés pour la prédiction, il serait intéressant de les estimer par une technique plus poussée que celle utilisée actuellement. On pourrait par exemple utiliser un modèle de séparation des données (train, validation, test) et ainsi effectuer plusieurs régressions et sélectionner celui qui performe le mieux.
Les données étant temporellement liées, il ne serait pas possible de valider avec autre chose que les données les plus récentes. Mais il serait possible d'augmenter au fur et à mesure le jeu de données pour générer plusieurs solutions et les valider avec les données inutilisées pour le créer, obtenant ainsi plusieurs modèles et permettant de choisir le meilleur.
Avec une telle méthode, il serait possible d'obtenir des résultats plus pertinents et augmenter les chances de prédire avec plus de précision le futur.
Cette dernière idée avait déjà été soulevée en amont du projet, mais nous n'avons malheureusement pas eut le temps d'explorer cette option.
Une fois une meilleure méthode de génération des facteurs mise en place et une méthode de validation des résultats finaux implémentée, il serait possible par la suite d'évaluer une grande série de facteurs avec plus d'information quant à leurs pertinance.
Les facteurs qui, regroupés ensemble, donnent les meilleures résultats, permettront ainsi d'avoir un algorithme le plus précis possible pour prédire les VaR et CVaR de notre portfolio et espérer prédire le futur le plus précisemment possible.
### Utiliser un autre algorithme de simulation
Une autre amélioration intéressante serait de tester un autre algorithme pour la simulation du marché boursier. En utilisant uniquement Monte-Carlo, nous ne somme pas sûrs d'avoir les simulations les plus réalistes.
Nous aurions voulu tester un autre algorithme qui serait peut-être plus adapté pour la simulation du marché boursier.
# Conclusion
Ce projet a été très intéressant, nous avons pu avoir une introduction sur les concepts des investissements sur le marché boursier et l'évaluation des risques.
Malheureusement, la prise en main du code a été compliqué et les problèmes que nous avons rencontrés et que nous avons dû corriger nous ont fait perdre un temps important. Nous aurions préféré mettre à ce temps profit pour étudier en détails les questions qui ont été définies au début du projet.
Néanmoins, nous avons réussi à démarrer le projet et obtenir des résultats intéressants dans les 48 dernières heures.
Sign in with Wallet
Connect another wallet