From: Benjamin Auder Date: Tue, 18 Apr 2017 14:18:18 +0000 (+0200) Subject: refactor reports.gj, prepare also 13h report X-Git-Url: https://git.auder.net/variants/Chakart/%7B%7B%20path%28%27fos_user_registration_register%27%29%20%7D%7D?a=commitdiff_plain;h=4d376294a6286ca1548d978055731dac175ffa3a;p=talweg.git refactor reports.gj, prepare also 13h report --- diff --git a/pkg/vignettes/talweg.html b/pkg/vignettes/talweg.html new file mode 100644 index 0000000..aa9cf1c --- /dev/null +++ b/pkg/vignettes/talweg.html @@ -0,0 +1,294 @@ + + + + + + + + + + + + + + + + +Vignette Title + + + + + + + + + + + + + + + + + +

Vignette Title

+

Vignette Author

+

2017-03-01

+ + + +

Vignettes are long form documentation commonly included in packages. Because they are part of the distribution of the package, they need to be as compact as possible. The html_vignette output type provides a custom style sheet (and tweaks some options) to ensure that the resulting html is as small as possible. The html_vignette format:

+ +
+

Vignette Info

+

Note the various macros within the vignette section of the metadata block above. These are required in order to instruct R how to build the vignette. Note that you should change the title field and the \VignetteIndexEntry to match the title of your vignette.

+
+
+

Styles

+

The html_vignette template includes a basic CSS theme. To override this theme you can specify your own CSS in the document metadata as follows:

+
output: 
+  rmarkdown::html_vignette:
+    css: mystyles.css
+
+
+

Figures

+

The figure sizes have been customised so that you can easily put two images side-by-side.

+
plot(1:10)
+plot(10:1)
+

+

You can enable figure captions by fig_caption: yes in YAML:

+
output:
+  rmarkdown::html_vignette:
+    fig_caption: yes
+

Then you can use the chunk option fig.cap = "Your figure caption." in knitr.

+
+
+

More Examples

+

You can write math expressions, e.g. \(Y = X\beta + \epsilon\), footnotes1, and tables, e.g. using knitr::kable().

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
mpgcyldisphpdratwtqsecvsamgearcarb
Mazda RX421.06160.01103.902.62016.460144
Mazda RX4 Wag21.06160.01103.902.87517.020144
Datsun 71022.84108.0933.852.32018.611141
Hornet 4 Drive21.46258.01103.083.21519.441031
Hornet Sportabout18.78360.01753.153.44017.020032
Valiant18.16225.01052.763.46020.221031
Duster 36014.38360.02453.213.57015.840034
Merc 240D24.44146.7623.693.19020.001042
Merc 23022.84140.8953.923.15022.901042
Merc 28019.26167.61233.923.44018.301044
+

Also a quote using >:

+
+

“He who gives up [code] safety for [code] speed deserves neither.” (via)

+
+
+
+
+
    +

  1. A footnote here.↩

    2. +
+
+ + + + + + + + diff --git a/reports/Experiments.gj b/reports/Experiments.gj new file mode 100644 index 0000000..0f102ad --- /dev/null +++ b/reports/Experiments.gj @@ -0,0 +1,255 @@ +----- +# Résultats numériques + +Cette partie montre les résultats obtenus avec des variantes de l'algorithme décrit au +chapitre , en utilisant le package présenté à la section 3. Cet algorithme est +systématiquement comparé à deux approches naïves : + + * la moyenne des lendemains des jours "similaires" dans tout le passé, c'est-à-dire +prédiction = moyenne de tous les mardis passés si le jour courant est un lundi. + * la persistence, reproduisant le jour courant ou allant chercher le lendemain de la +dernière journée "similaire" (même principe que ci-dessus ; argument "same\_day"). + +Concernant l'algorithme principal à voisins, trois variantes sont étudiées dans cette +partie : + + * avec simtype="mix" et raccordement "Neighbors" dans le cas "non local", i.e. on va +chercher des voisins n'importe où du moment qu'ils correspondent au premier élément d'un +couple de deux jours consécutifs sans valeurs manquantes. + * avec simtype="endo" + raccordement "Neighbors" puis simtype="none" + raccordement +"Zero" (sans ajustement) dans le cas "local" : voisins de même niveau de pollution et +même saison. + +Pour chaque période retenue $-$ chauffage, épandage, semaine non polluée $-$ les erreurs +de prédiction sont d'abord affichées, puis quelques graphes de courbes réalisées/prévues +(sur le jour "en moyenne le plus facile" à gauche, et "en moyenne le plus difficile" à +droite). Ensuite plusieurs types de graphes apportant des précisions sur la nature et la +difficulté du problème viennent compléter ces premières courbes. Concernant les graphes +de filaments, la moitié gauche du graphe correspond aux jours similaires au jour courant, +tandis que la moitié droite affiche les lendemains : ce sont donc les voisinages tels +qu'utilisés dans l'algorithme. +<% +list_titles = ['Pollution par chauffage','Pollution par épandage','Semaine non polluée'] +list_indices = ['indices_ch', 'indices_ep', 'indices_np'] +%> +-----r +library(talweg) + +P = ${P} #instant de prévision +H = ${H} #horizon (en heures) + +ts_data = read.csv(system.file("extdata","pm10_mesures_H_loc_report.csv", + package="talweg")) +exo_data = read.csv(system.file("extdata","meteo_extra_noNAs.csv", + package="talweg")) +# NOTE: 'GMT' because DST gaps are filled and multiple values merged in +# above dataset. Prediction from P+1 to P+H included. +data = getData(ts_data, exo_data, input_tz = "GMT", working_tz="GMT", + predict_at=P) + +indices_ch = seq(as.Date("2015-01-18"),as.Date("2015-01-24"),"days") +indices_ep = seq(as.Date("2015-03-15"),as.Date("2015-03-21"),"days") +indices_np = seq(as.Date("2015-04-26"),as.Date("2015-05-02"),"days") +% for i in range(3): +----- +##

${list_titles[i]}

+${"##"} ${list_titles[i]} +-----r +p1 = computeForecast(data, ${list_indices[i]}, "Neighbors", "Neighbors", horizon=H, + simtype="mix", local=FALSE) +p2 = computeForecast(data, ${list_indices[i]}, "Neighbors", "Neighbors", horizon=H, + simtype="endo", local=TRUE) +p3 = computeForecast(data, ${list_indices[i]}, "Neighbors", "Zero", horizon=H, + simtype="none", local=TRUE) +p4 = computeForecast(data, ${list_indices[i]}, "Average", "Zero", horizon=H) +p5 = computeForecast(data, ${list_indices[i]}, "Persistence", "Zero", horizon=H, + same_day=${'TRUE' if loop.index < 2 else 'FALSE'}) +-----r +e1 = computeError(data, p1, H) +e2 = computeError(data, p2, H) +e3 = computeError(data, p3, H) +e4 = computeError(data, p4, H) +e5 = computeError(data, p5, H) +options(repr.plot.width=9, repr.plot.height=7) +plotError(list(e1, e5, e4, e2, e3), cols=c(1,2,colors()[258],4,6)) + +# noir: Neighbors non-local (p1), bleu: Neighbors local endo (p2), +# mauve: Neighbors local none (p3), vert: moyenne (p4), +# rouge: persistence (p5) + +sum_p123 = e1$abs$indices + e2$abs$indices + e3$abs$indices +i_np = which.min(sum_p123) #indice de (veille de) jour "facile" +i_p = which.max(sum_p123) #indice de (veille de) jour "difficile" +----- +% if i == 0: +L'erreur absolue dépasse 20 sur 1 à 2 jours suivant les modèles (graphe en haut à +droite). Sur cet exemple le modèle à voisins "contraint" (local=TRUE) utilisant des +pondérations basées sur les similarités de forme (simtype="endo") obtient en moyenne les +meilleurs résultats, avec un MAPE restant en général inférieur à 30% de 8h à 19h (7+1 à +7+12 : graphe en bas à gauche). +% elif i == 1: +Il est difficile dans ce cas de déterminer une méthode meilleure que les autres : elles +donnent toutes de plutôt mauvais résultats, avec une erreur absolue moyennée sur la +journée dépassant presque toujours 15 (graphe en haut à droite). +% else: +Dans ce cas plus favorable les intensité des erreurs absolues ont clairement diminué : +elles restent souvent en dessous de 5. En revanche le MAPE moyen reste au-delà de 20%, et +même souvent plus de 30%. Comme dans le cas de l'épandage on constate une croissance +globale de la courbe journalière d'erreur absolue moyenne (en haut à gauche) ; ceci peut +être dû au fait que l'on ajuste le niveau du jour à prédire en le recollant sur la +dernière valeur observée. +% endif +-----r +options(repr.plot.width=9, repr.plot.height=4) +par(mfrow=c(1,2)) + +plotPredReal(data, p1, i_np); title(paste("PredReal p1 day",i_np)) +plotPredReal(data, p1, i_p); title(paste("PredReal p1 day",i_p)) + +plotPredReal(data, p2, i_np); title(paste("PredReal p2 day",i_np)) +plotPredReal(data, p2, i_p); title(paste("PredReal p2 day",i_p)) + +plotPredReal(data, p3, i_np); title(paste("PredReal p3 day",i_np)) +plotPredReal(data, p3, i_p); title(paste("PredReal p3 day",i_p)) + +# Bleu : prévue ; noir : réalisée +----- +% if i == 0: +Le jour "facile à prévoir", à gauche, se décompose en deux modes : un léger vers 10h +(7+3), puis un beaucoup plus marqué vers 19h (7+12). Ces deux modes sont retrouvés par +les trois variantes de l'algorithme à voisins, bien que l'amplitude soit mal prédite. +Concernant le jour "difficile à prévoir" (à droite) il y a deux pics en tout début et +toute fin de journée (à 9h et 23h), qui ne sont pas du tout anticipés par les méthodes ; +la grande amplitude de ces pics explique alors l'intensité de l'erreur observée. +% elif i == 1: +Dans le cas d'un jour "facile" à prédire $-$ à gauche $-$ la forme est plus ou moins +retrouvée, mais le niveau moyen est trop bas (courbe en bleu). Concernant le jour +"difficile" à droite, non seulement la forme n'est pas anticipée mais surtout le niveau +prédit est très inférieur au niveau de pollution observé. Comme on le voit ci-dessous +cela découle d'un manque de voisins au comportement similaire. +% else: +La forme est raisonnablement retrouvée pour les méthodes "locales", l'autre version +lissant trop les prédictions. Le biais reste cependant important, surtout en fin de +journée sur la courbes "difficile à prévoir". +% endif +-----r +par(mfrow=c(1,2)) +f_np1 = computeFilaments(data, p1, i_np, plot=TRUE) + title(paste("Filaments p1 day",i_np)) +f_p1 = computeFilaments(data, p1, i_p, plot=TRUE) + title(paste("Filaments p1 day",i_p)) + +f_np2 = computeFilaments(data, p2, i_np, plot=TRUE) + title(paste("Filaments p2 day",i_np)) +f_p2 = computeFilaments(data, p2, i_p, plot=TRUE) + title(paste("Filaments p2 day",i_p)) +----- +% if i == 0: +Les voisins du jour courant (période de 24h allant de 8h à 7h le lendemain) sont affichés +avec un trait d'autant plus sombre qu'ils sont proches. On constate dans le cas non +contraint (en haut) une grande variabilité des lendemains, très nette sur le graphe en +haut à droite. Ceci indique une faible corrélation entre la forme d'une courbe sur une +période de 24h et la forme sur les 24h suivantes ; **cette observation est la source des +difficultés rencontrées par l'algorithme sur ce jeu de données.** +% elif i == 1: +Les observations sont les mêmes qu'au paragraphe précédent : trop de variabilité des +lendemains (et même des voisins du jour courant). +% else: +Les graphes de filaments ont encore la même allure, avec une assez grande variabilité +observée. Cette observation est cependant trompeuse, comme l'indique plus bas le graphe +de variabilité relative. +% endif +-----r +par(mfrow=c(1,2)) +plotFilamentsBox(data, f_np1); title(paste("FilBox p1 day",i_np)) +plotFilamentsBox(data, f_p1); title(paste("FilBox p1 day",i_p)) + +# En pointillés la courbe du jour courant + lendemain (à prédire) +----- +% if i == 0: +Sur cette boxplot fonctionnelle (voir la fonction fboxplot() du package R "rainbow") on +constate essentiellement deux choses : le lendemain d'un voisin "normal" peut se révéler +être une courbe atypique, fort éloignée de ce que l'on souhaite prédire (courbes bleue et +rouge à gauche) ; et, dans le cas d'une courbe à prédire atypique (à droite) la plupart +des voisins sont trop éloignés de la forme à prédire et forcent ainsi un aplatissement de +la prédiction. +% elif i == 1: +On constate la présence d'un voisin au lendemain complètement atypique avec un pic en +début de journée (courbe en vert à gauche), et d'un autre phénomène semblable avec la +courbe rouge sur le graphe de droite. Ajouté au fait que le lendemain à prévoir est +lui-même un jour "hors norme", cela montre l'impossibilité de bien prévoir une courbe en +utilisant l'algorithme à voisins. +% else: +On peut réappliquer les mêmes remarques qu'auparavant sur les boxplots fonctionnels : +lendemains de voisins atypiques, courbe à prévoir elle-même légèrement "hors norme". +% endif +-----r +par(mfrow=c(1,2)) +plotRelVar(data, f_np1); title(paste("StdDev p1 day",i_np)) +plotRelVar(data, f_p1); title(paste("StdDev p1 day",i_p)) + +plotRelVar(data, f_np2); title(paste("StdDev p2 day",i_np)) +plotRelVar(data, f_p2); title(paste("StdDev p2 day",i_p)) + +# Variabilité globale en rouge ; sur les voisins (+ lendemains) en noir +----- +% if i == 0: +Ces graphes viennent confirmer l'impression visuelle après observation des filaments. En +effet, la variabilité globale en rouge (écart-type heure par heure sur l'ensemble des +couples "aujourd'hui/lendemain"du passé) devrait rester nettement au-dessus de la +variabilité locale, calculée respectivement sur un voisinage d'une soixantaine de jours +(pour p1) et d'une dizaine de jours (pour p2). Or on constate que ce n'est pas du tout le +cas sur la période "lendemain", sauf en partie pour p2 le jour 4 $-$ mais ce n'est pas +suffisant. +% elif i == 1: +Comme précédemment les variabilités locales et globales sont confondues dans les parties +droites des graphes $-$ sauf pour la version "locale" sur le jour "facile"; mais cette +bonne propriété n'est pas suffisante si l'on ne trouve pas les bons poids à appliquer. +% else: +Cette fois la situation idéale est observée : la variabilité globale est nettement +au-dessus de la variabilité locale. Bien que cela ne suffise pas à obtenir de bonnes +prédictions de forme, on constate au moins l'amélioration dans la prédiction du niveau. +% endif +-----r +par(mfrow=c(1,2)) +plotSimils(p1, i_np); title(paste("Weights p1 day",i_np)) +plotSimils(p1, i_p); title(paste("Weights p1 day",i_p)) + +plotSimils(p2, i_np); title(paste("Weights p2 day",i_np)) +plotSimils(p2, i_p); title(paste("Weights p2 day",i_p)) +----- +% if i == 0: +Les poids se concentrent près de 0 dans le cas "non local" (p1), et se répartissent assez +uniformément dans [ 0, 0.2 ] dans le cas "local" (p2). C'est ce que l'on souhaite +observer pour éviter d'effectuer une simple moyenne. +% elif i == 1: +En comparaison avec le pragraphe précédent on retrouve le même (bon) comportement des +poids pour la version "non locale". En revanche la fenêtre optimisée est trop grande sur +le jour "facile" pour la méthode "locale" (voir affichage ci-dessous) : il en résulte des +poids tous semblables autour de 0.084, l'algorithme effectue donc une moyenne simple $-$ +expliquant pourquoi les courbes mauve et bleue sont très proches sur le graphe d'erreurs. +% else: +Concernant les poids en revanche, deux cas a priori mauvais se cumulent : + + * les poids dans le cas "non local" ne sont pas assez concentrés autour de 0, menant à +un lissage trop fort $-$ comme observé sur les graphes des courbes réalisées/prévues ; + * les poids dans le cas "local" sont trop semblables (à cause de la trop grande fenêtre +optimisée par validation croisée, cf. ci-dessous), résultant encore en une moyenne simple +$-$ mais sur moins de jours, plus proches du jour courant. +% endif +-----r +# Fenêtres sélectionnées dans ]0,7] : +# "non-local" 2 premières lignes, "local" ensuite +p1$getParams(i_np)$window +p1$getParams(i_p)$window + +p2$getParams(i_np)$window +p2$getParams(i_p)$window +% endfor +----- +${"##"} Bilan + +Nos algorithmes à voisins ne sont pas adaptés à ce jeu de données où la forme varie +considérablement d'un jour à l'autre. Toutefois, un espoir reste permis par exemple en +aggrégeant les courbes spatialement (sur plusieurs stations situées dans la même +agglomération ou dans une même zone). diff --git a/reports/report.gj b/reports/OLD/report_OLD.gj similarity index 66% rename from reports/report.gj rename to reports/OLD/report_OLD.gj index e499ece..b8b9233 100644 --- a/reports/report.gj +++ b/reports/OLD/report_OLD.gj @@ -1,125 +1,16 @@ ----- -# Package R "talweg" +# Résultats numériques -Le package $-$ Time-series sAmpLes forecasted With ExoGenous variables $-$ contient le -code permettant de (re)lancer les expériences numériques décrites dans cette partie et la -suivante. Les fonctions principales sont respectivement - - * **getData()** pour construire un objet R contenant les données à partir de fichiers -CSV (extraits de bases de données). Le format choisi en R est une classe R6 (du package -du même nom) exposant en particulier les méthodes *getSerie(i)* et *getExo(i)* qui -renvoient respectivement la $i^{eme}$ série de 24h et les variables exogènes (mesurées) -correspondantes. Voir ?Data pour plus d'information, une fois le package chargé. - * **computeForecast()** pour calculer des prédictions sur une certaine plage temporelle -contenue dans *data <- getData(...)* - * **computeError()** pour évaluer les erreurs commises par différentes méthodes. - -Le package contient en outre diverses fonctions graphiques *plotXXX()*, utilisées dans la -partie suivante. ------r -# Chargement de la librairie (après compilation, "R CMD INSTALL .") -library(talweg) - -# Acquisition des données (depuis les fichiers CSV) -ts_data <- read.csv(system.file("extdata","pm10_mesures_H_loc.csv", - package="talweg")) -exo_data <- read.csv(system.file("extdata","meteo_extra_noNAs.csv", - package="talweg")) -data <- getData(ts_data, exo_data, input_tz="GMT", - date_format="%d/%m/%Y %H:%M", working_tz="GMT", - predict_at=7, limit=120) -# Plus de détails à la section 1 ci-après. - -# Prédiction de 10 courbes (jours 102 à 111) -pred <- computeForecast(data, 101:110, "Persistence", "Zero", memory=50, - horizon=12, ncores=1) -# Plus de détails à la section 2 ci-après. - -# Calcul des erreurs (sur un horizon arbitraire <= horizon de prédiction) -err <- computeError(data, pred, horizon=6) -# Plus de détails à la section 3 ci-après. - -# Puis voir ?plotError et les autres plot dans le paragraphe 'seealso' ------ -${"##"} getData() - -Les arguments de cette fonction sont, dans l'ordre : - - 1. **ts_data** : séries temporelles (fichier CSV avec entête ou data.frame) ; la -première colonne contient les heures, la seconde les valeurs. - 2. **exo_data** : variables exogènes (fichier CSV avec entête ou data.frame) ; la -première colonne contient les jours, les $m$ suivantes les variables mesurées pour ce -jour, et les $m$ dernières les variables prédites pour ce même jour. Dans notre cas $m=4$ -: pression, température, gradient de température, vitesse du vent. - 3. **input_tz** : zone horaire pour ts_data (défaut : "GMT"). - 4. **date_format** : format des heures dans ts_data (défaut : "%d/%m/%Y %H:%M", format -du fichier transmis par Michel). - 5. **working_tz** : zone horaire dans laquelle on souhaite travailler avec les données -(défaut : "GMT"). - 6. **predict_at** : heure à laquelle s'effectue la prévision $-$ et donc dernière heure -d'un bloc de 24h, relativement à working_tz. data`$`getSerie(3) renvoit ainsi les 24 -valeurs de 8h à 7h pour le $3^{eme}$ bloc de 24h présent dans le jeu de données. ------r -print(data) -#?Data ------ -${"##"} computeForecast() - -Les arguments de cette fonction sont, dans l'ordre : - - 1. **data** : le jeu de données renvoyé par getData() - 2. **indices** : l'ensemble de jours dont on veut prévoir les "lendemains" (prochains -blocs de 24h) ; peut être donnée sous forme d'un vecteur de dates ou d'entiers -(correspondants aux numéros des jours). - 3. **forecaster** : le nom du prédicteur principal à utiliser ; voir ?computeForecast - 4. **pjump** : le nom du prédicteur de saut d'une série à l'autre ; voir -?computeForecast - 5. **memory** : le nombre de jours à prendre en compte dans le passé pour chaque -prévision (par défaut : Inf, c'est-à-dire tout l'historique pris en compte). - 6. **horizon** : le nombre d'heures à prédire ; par défaut "data`$`getStdHorizon()", -c'est-à-dire le nombre d'heures restantes à partir de l'instant de prévision + 1 jusqu'à -minuit (17 pour predict_at=7 par exemple). - 7. **ncores** : le nombre de processus parallèles (utiliser 1 pour une exécution -séquentielle) ------r -print(pred) -#?computeForecast ------ -${"##"} computeError() - -Les arguments de cette fonction sont, dans l'ordre : - - 1. **data** : le jeu de données renvoyé par getData() - 2. **pred** : les prédictions renvoyées par computeForecast() - 3. **horizon** : le nombre d'heures à considérer pour le calcul de l'erreur ; doit être -inférieur ou égal à l'horizon utilisé pour la prédiction (même valeur par défaut : -"data`$`getStdHorizon()") ------r -summary(err) -summary(err$abs) -summary(err$MAPE) ------ -${"##"} Graphiques - -Voir ?plotError : les autres fonctions graphiques sont dans la section 'seealso' : - - ‘plotCurves’, ‘plotPredReal’, ‘plotSimils’, ‘plotFbox’, - ‘computeFilaments’, ‘plotFilamentsBox’, ‘plotRelVar’ - -?plotXXX, etc. -## $\clearpage$ How to do that? ------ -# Expérimentations - -Cette partie montre les résultats obtenus via des variantes de l'algorithme décrit à la -section 2, en utilisant le package présenté à la section 3. Cet algorithme est +Cette partie montre les résultats obtenus avec des variantes de l'algorithme décrit au +chapitre 5, en utilisant le package présenté au chapitre 6. +Les ........... options ........... +Cet algorithme est systématiquement comparé à deux approches naïves : - * la moyenne des lendemains des jours "similaires" dans tout le passé, c'est-à-dire -prédiction = moyenne de tous les mardis passé si le jour courant est un lundi par -exemple. + * la moyenne des lendemains des jours de même type dans tout le passé, c'est-à-dire +prédiction = moyenne de tous les mardis passés si le jour courant est un lundi. * la persistence, reproduisant le jour courant ou allant chercher le lendemain de la -dernière journée "similaire" (même principe que ci-dessus ; argument "same\_day"). +dernière journée de même type (même principe que ci-dessus ; argument "same\_day"). Concernant l'algorithme principal à voisins, trois variantes sont étudiées dans cette partie : @@ -188,13 +79,25 @@ plotError(list(e1, e5, e4, e2, e3), cols=c(1,2,colors()[258],4,6)) # mauve: Neighbors local none (p3), vert: moyenne (p4), # rouge: persistence (p5) +##############TODO: expliquer "endo" "none"......etc +## ajouter fenêtres essais dans rapport. --> dans chapitre actuel. +## re-ajouter annexe sur ancienne méthode exo/endo/mix +## ---------> fenetres comment elles sont optimisées +#--------> ajouter à la fin quelques graphes montrant/comparant autres méthodes +#chapitre résumé avec différents essais conclusions. ---> synthèse des essais réalisés, +#avec sous-paragraphes avec conclusions H3/H17 sans surprises on améliore les choses, +#mais il y a des situations où c'est pas mieux. +#---------> fichier tex réinsérer synthèse de l'ensemble des essais réalisés. +#++++++++ ajouter à 13h + sum_p123 = e1$abs$indices + e2$abs$indices + e3$abs$indices i_np = which.min(sum_p123) #indice de (veille de) jour "facile" i_p = which.max(sum_p123) #indice de (veille de) jour "difficile" ----- % if i == 0: L'erreur absolue dépasse 20 sur 1 à 2 jours suivant les modèles (graphe en haut à -droite). C'est au-delà de ce que l'on aimerait voir (disons +/- 5 environ). Sur cet +droite). ##C'est au-delà de ce que l'on aimerait voir (disons +/- 5 environ). +Sur cet exemple le modèle à voisins "contraint" (local=TRUE) utilisant des pondérations basées sur les similarités de forme (simtype="endo") obtient en moyenne les meilleurs résultats, avec un MAPE restant en général inférieur à 30% de 8h à 19h (7+1 à 7+12 : graphe en bas à @@ -227,11 +130,13 @@ plotPredReal(data, p3, i_p); title(paste("PredReal p3 day",i_p)) # Bleu : prévue ; noir : réalisée ----- % if i == 0: -Le jour "facile à prévoir", à gauche, se décompose en deux modes : un léger vers 10h +La courbe non centrée du jour facile à prévoir (en noir), +##Le jour "facile à prévoir", +à gauche, se décompose en deux modes : un léger vers 10h (7+3), puis un beaucoup plus marqué vers 19h (7+12). Ces deux modes sont retrouvés par les trois variantes de l'algorithme à voisins, bien que l'amplitude soit mal prédite. -Concernant le jour "difficile à prévoir" il y a deux pics en tout début et toute fin de -journée (à 9h et 23h), qui ne sont pas du tout anticipés par le programme ; la grande +Concernant le jour "difficile à prévoir" (à droite) il y a deux pics en tout début et toute fin de +journée (à 9h et 23h), qui ne sont pas du tout anticipés par les méthodes ; la grande amplitude de ces pics explique alors l'intensité de l'erreur observée. % elif i == 1: Dans le cas d'un jour "facile" à prédire $-$ à gauche $-$ la forme est plus ou moins @@ -276,10 +181,18 @@ par(mfrow=c(1,2)) plotFilamentsBox(data, f_np1); title(paste("FilBox p1 day",i_np)) plotFilamentsBox(data, f_p1); title(paste("FilBox p1 day",i_p)) +## Questions : +#7h VS 13h +#est-ce que prévoir 24h ou 13 ou 3 facilite. +#amplitude erreur raisonnable ? probleme facile difficile ? +#place des exogènes ? +#H = ? +#épandage > chauffage > np + # En pointillés la courbe du jour courant + lendemain (à prédire) ----- % if i == 0: -Sur cette boxplot fonctionnelle (voir la fonction fboxplot() du package R "rainbow") l'on +Sur cette boxplot fonctionnelle (voir la fonction fboxplot() du package R "rainbow") on constate essentiellement deux choses : le lendemain d'un voisin "normal" peut se révéler être une courbe atypique, fort éloignée de ce que l'on souhaite prédire (courbes bleue et rouge à gauche) ; et, dans le cas d'une courbe à prédire atypique (à droite) la plupart @@ -362,9 +275,9 @@ p2$getParams(i_p)$window ${"##"} Bilan Nos algorithmes à voisins ne sont pas adaptés à ce jeu de données où la forme varie -considérablement d'un jour à l'autre. Plus généralement cette décorrélation de forme rend -ardue la tâche de prévision pour toute autre méthode $-$ du moins, nous ne savons pas -comment procéder pour parvenir à une bonne précision. - -Toutefois, un espoir reste permis par exemple en aggréger les courbes spatialement (sur +considérablement d'un jour à l'autre. +Toutefois, un espoir reste permis par exemple en aggrégeant les courbes spatialement (sur plusieurs stations situées dans la même agglomération ou dans une même zone). +##Plus généralement cette décorrélation de forme rend +##ardue la tâche de prévision pour toute autre méthode $-$ du moins, nous ne savons pas +##comment procéder pour parvenir à une bonne précision. diff --git a/reports/PackageR.gj b/reports/PackageR.gj new file mode 100644 index 0000000..d62dc36 --- /dev/null +++ b/reports/PackageR.gj @@ -0,0 +1,109 @@ +----- +# Package R "talweg" + +Le package $-$ Time-series sAmpLes forecasted With ExoGenous variables $-$ contient le +code permettant de lancer les expériences numériques décrites dans le chapitre suivant. +Les fonctions principales sont respectivement + + * **getData()** pour construire un objet R contenant les données à partir de fichiers +CSV (extraits de bases de données). Le format choisi en R est une classe R6 (du package +du même nom) exposant en particulier les méthodes *getSerie(i)* et *getExo(i)* qui +renvoient respectivement la $i^{eme}$ série de 24h et les variables exogènes (mesurées) +correspondantes. Voir ?Data pour plus d'information, une fois le package chargé. + * **computeForecast()** pour calculer des prédictions sur une certaine plage temporelle +contenue dans *data <- getData(...)* + * **computeError()** pour évaluer les erreurs commises par différentes méthodes. + +Le package contient en outre diverses fonctions graphiques *plotXXX()*, utilisées dans la +partie suivante. +-----r +# Chargement de la librairie (après compilation, "R CMD INSTALL .") +library(talweg) + +# Acquisition des données (depuis les fichiers CSV) +ts_data <- read.csv(system.file("extdata","pm10_mesures_H_loc.csv", + package="talweg")) +exo_data <- read.csv(system.file("extdata","meteo_extra_noNAs.csv", + package="talweg")) +data <- getData(ts_data, exo_data, input_tz="GMT", + date_format="%d/%m/%Y %H:%M", working_tz="GMT", + predict_at=7, limit=120) +# Plus de détails à la section 1 ci-après. + +# Prédiction de 10 courbes (jours 102 à 111) +pred <- computeForecast(data, 101:110, "Persistence", "Zero", memory=50, + horizon=12, ncores=1) +# Plus de détails à la section 2 ci-après. + +# Calcul des erreurs (sur un horizon arbitraire <= horizon de prédiction) +err <- computeError(data, pred, horizon=6) +# Plus de détails à la section 3 ci-après. + +# Puis voir ?plotError et les autres plot dans le paragraphe 'seealso' +----- +${"##"} getData() + +Les arguments de cette fonction sont, dans l'ordre : + + 1. **ts_data** : séries temporelles (fichier CSV avec entête ou data.frame) ; la +première colonne contient les heures, la seconde les valeurs. + 2. **exo_data** : variables exogènes (fichier CSV avec entête ou data.frame) ; la +première colonne contient les jours, les $m$ suivantes les variables mesurées pour ce +jour, et les $m$ dernières les variables prédites pour ce même jour. Dans notre cas $m=4$ +: pression, température, gradient de température, vitesse du vent. + 3. **input_tz** : zone horaire pour ts_data (défaut : "GMT"). + 4. **date_format** : format des heures dans ts_data (défaut : "%d/%m/%Y %H:%M", format +du fichier transmis par Michel). + 5. **working_tz** : zone horaire dans laquelle on souhaite travailler avec les données +(défaut : "GMT"). + 6. **predict_at** : heure à laquelle s'effectue la prévision $-$ et donc dernière heure +d'un bloc de 24h, relativement à working_tz. data`$`getSerie(3) renvoit ainsi les 24 +valeurs de 8h à 7h pour le $3^{eme}$ bloc de 24h présent dans le jeu de données. +-----r +print(data) +#?Data +----- +${"##"} computeForecast() + +Les arguments de cette fonction sont, dans l'ordre : + + 1. **data** : le jeu de données renvoyé par getData() + 2. **indices** : l'ensemble de jours dont on veut prévoir les "lendemains" (prochains +blocs de 24h) ; peut être donnée sous forme d'un vecteur de dates ou d'entiers +(correspondants aux numéros des jours). + 3. **forecaster** : le nom du prédicteur principal à utiliser ; voir ?computeForecast + 4. **pjump** : le nom du prédicteur de saut d'une série à l'autre ; voir +?computeForecast + 5. **memory** : le nombre de jours à prendre en compte dans le passé pour chaque +prévision (par défaut : Inf, c'est-à-dire tout l'historique pris en compte). + 6. **horizon** : le nombre d'heures à prédire ; par défaut "data`$`getStdHorizon()", +c'est-à-dire le nombre d'heures restantes à partir de l'instant de prévision + 1 jusqu'à +minuit (17 pour predict_at=7 par exemple). + 7. **ncores** : le nombre de processus parallèles (utiliser 1 pour une exécution +séquentielle) +-----r +print(pred) +#?computeForecast +----- +${"##"} computeError() + +Les arguments de cette fonction sont, dans l'ordre : + + 1. **data** : le jeu de données renvoyé par getData() + 2. **pred** : les prédictions renvoyées par computeForecast() + 3. **horizon** : le nombre d'heures à considérer pour le calcul de l'erreur ; doit être +inférieur ou égal à l'horizon utilisé pour la prédiction (même valeur par défaut : +"data`$`getStdHorizon()") +-----r +summary(err) +summary(err$abs) +summary(err$MAPE) +----- +${"##"} Graphiques + +Voir ?plotError : les autres fonctions graphiques sont dans la section 'seealso' : + + ‘plotCurves’, ‘plotPredReal’, ‘plotSimils’, ‘plotFbox’, + ‘computeFilaments’, ‘plotFilamentsBox’, ‘plotRelVar’ + +?plotXXX, etc. diff --git a/reports/report_P7_H17.zip b/reports/report_P7_H17.zip deleted file mode 100644 index 65253b5..0000000 --- a/reports/report_P7_H17.zip +++ /dev/null @@ -1 +0,0 @@ -#$# git-fat 4a0e88af47c14a7cdb4d00b268517eefec453d90 2747183 diff --git a/reports/run.sh b/reports/run.sh index 044d00d..9d67a84 100755 --- a/reports/run.sh +++ b/reports/run.sh @@ -1,13 +1,11 @@ #!/bin/sh -# Usage: ./run.sh P H +# Usage: ./run.sh file[no_suffix] P H -./ipynb_generator.py report.gj - P=$1 H=$2 +./ipynb_generator.py $1.gj - P=$2 H=$3 -#htmlfile=report_P$1_H$2.html -nbfile=report_P$1_H$2.ipynb jupyter-nbconvert \ --ExecutePreprocessor.kernel_name='ir' \ --ExecutePreprocessor.timeout=1800 \ - --execute report.ipynb \ - --to notebook --output $nbfile -# --to html --output=$htmlfile + --execute $1.ipynb \ + --to notebook --output $1.out.ipynb +# --to html --output=$1.html