Édition majeure: Je voudrais dire un grand merci à Dave et Nick jusqu'à présent pour leurs réponses. La bonne nouvelle est que j'ai réussi à faire fonctionner la boucle (principe emprunté à la publication du professeur Hydnman sur la prévision par lots). Pour consolider les requêtes en attente:
a) Comment puis-je augmenter le nombre maximal d'itérations pour auto.arima - il semble qu'avec un grand nombre de variables exogènes, auto.arima atteint le nombre maximal d'itérations avant de converger vers un modèle final. Veuillez me corriger si je ne comprends pas bien.
b) Une réponse, de Nick, souligne que mes prédictions pour les intervalles horaires ne sont dérivées que de ces intervalles horaires et ne sont pas influencées par des événements plus tôt dans la journée. Mon instinct, en traitant ces données, me dit que cela ne devrait pas souvent causer un problème important, mais je suis ouvert à des suggestions sur la façon de traiter cela.
c) Dave a souligné que j'avais besoin d'une approche beaucoup plus sophistiquée pour identifier les temps de latence / retard entourant mes variables prédictives. Quelqu'un a-t-il une expérience avec une approche programmatique de cela dans R? Bien sûr, je m'attends à ce qu'il y ait des limites, mais je voudrais pousser ce projet aussi loin que je le peux, et je ne doute pas que cela doit également être utile à d'autres ici.
d) Nouvelle requête mais entièrement liée à la tâche à accomplir - auto.arima prend-il en compte les régresseurs lors de la sélection des commandes?
J'essaie de prévoir les visites dans un magasin. J'ai besoin de la capacité de rendre compte des vacances mobiles, des années bissextiles et des événements sporadiques (essentiellement des valeurs aberrantes); sur cette base, je suppose que ARIMAX est mon meilleur pari, en utilisant des variables exogènes pour essayer de modéliser la saisonnalité multiple ainsi que les facteurs susmentionnés.
Les données sont enregistrées 24 heures à intervalles horaires. Cela s'avère problématique en raison de la quantité de zéros dans mes données, en particulier à des moments de la journée qui voient de très faibles volumes de visites, parfois pas du tout lorsque le magasin vient d'ouvrir. De plus, les heures d'ouverture sont relativement irrégulières.
De plus, le temps de calcul est énorme lorsque l'on prévoit une série chronologique complète avec 3 ans + de données historiques. Je pensais que cela le rendrait plus rapide en calculant chaque heure de la journée sous forme de séries chronologiques distinctes, et lorsque le tester à des heures plus occupées de la journée semble donner une plus grande précision, mais se révèle à nouveau devenir un problème avec les heures tôt / tard qui ne fonctionnent pas '' t recevoir régulièrement des visites. Je pense que le processus gagnerait à utiliser auto.arima mais il ne semble pas pouvoir converger sur un modèle avant d'atteindre le nombre maximal d'itérations (d'où l'utilisation d'un ajustement manuel et de la clause maxit).
J'ai essayé de gérer les données «manquantes» en créant une variable exogène pour quand les visites = 0. Encore une fois, cela fonctionne très bien pour les moments plus occupés de la journée où la seule fois où il n'y a pas de visites est lorsque le magasin est fermé pour la journée; dans ces cas, la variable exogène semble gérer cette situation avec succès pour les prévisions à venir et sans tenir compte de l'effet de la clôture de la journée précédente. Cependant, je ne sais pas comment utiliser ce principe en ce qui concerne la prévision des heures plus calmes où le magasin est ouvert mais ne reçoit pas toujours de visites.
Avec l'aide du message du professeur Hyndman sur les prévisions par lots dans R, j'essaie de mettre en place une boucle pour prévoir les 24 séries, mais il ne semble pas vouloir prévoir à 13 heures et je ne peux pas comprendre pourquoi. J'obtiens "Erreur dans optim (init [mask], armafn, method = optim.method, hessian = TRUE,: valeur de différence finie non finie [1]" mais comme toutes les séries sont de longueur égale et j'utilise essentiellement la même matrice, je ne comprends pas pourquoi cela se produit. Cela signifie que la matrice n'est pas de plein rang, non? Comment puis-je éviter cela dans cette approche?
https://www.dropbox.com/s/26ov3xp4ayig4ws/Data.zip
date()
#Read input files
INPUT <- read.csv("Input.csv")
XREGFDATA <- read.csv("xreg.csv")
#Subset time series data from the input file
TS <- ts(INPUT[,2:25], f=7)
fcast <- matrix(0, nrow=nrow(XREGFDATA),ncol=ncol(TS))
#Create matrix of exogenous variables for forecasting.
xregf <- (cbind(Weekday=model.matrix(~as.factor(XREGFDATA$WEEKDAY)),
Month=model.matrix(~as.factor(XREGFDATA$MONTH)),
Week=model.matrix(~as.factor(XREGFDATA$WEEK)),
Nodata=XREGFDATA$NoData,
NewYearsDay=XREGFDATA$NewYearsDay,
GoodFriday=XREGFDATA$GoodFriday,
EasterWeekend=XREGFDATA$EasterWeekend,
EasterMonday=XREGFDATA$EasterMonday,
MayDay=XREGFDATA$MayDay,
SpringBH=XREGFDATA$SpringBH,
SummerBH=XREGFDATA$SummerBH,
Christmas=XREGFDATA$Christmas,
BoxingDay=XREGFDATA$BoxingDay))
#Remove intercepts
xregf <- xregf[,c(-1,-8,-20)]
NoFcast <- 0
for(i in 1:24) {
if(max(INPUT[,i+1])>0) {
#The exogenous variables used to fit are the same for all series except for the
#'Nodata' variable. This is to handle missing data for each series
xreg <- (cbind(Weekday=model.matrix(~as.factor(INPUT$WEEKDAY)),
Month=model.matrix(~as.factor(INPUT$MONTH)),
Week=model.matrix(~as.factor(INPUT$WEEK)),
Nodata=ifelse(INPUT[,i+1] < 1,1,0),
NewYearsDay=INPUT$NewYearsDay,
GoodFriday=INPUT$GoodFriday,
EasterWeekend=INPUT$EasterWeekend,
EasterMonday=INPUT$EasterMonday,
MayDay=INPUT$MayDay,
SpringBH=INPUT$SpringBH,
SummerBH=INPUT$SummerBH,
Christmas=INPUT$Christmas,
BoxingDay=INPUT$BoxingDay))
xreg <- xreg[,c(-1,-8,-20)]
ARIMAXfit <- Arima(TS[,i],
order=c(0,1,8), seasonal=c(0,1,0),
include.drift=TRUE,
xreg=xreg,
lambda=BoxCox.lambda(TS[,i])
,optim.control = list(maxit=1500), method="ML")
fcast[,i] <- forecast(ARIMAXfit, xreg=xregf)$mean
} else{
NoFcast <- NoFcast +1
}
}
#Save the forecasts to .csv
write(t(fcast),file="fcasts.csv",sep=",",ncol=ncol(fcast))
date()
J'apprécierais pleinement les critiques constructives de la façon dont je procède et toute aide pour faire fonctionner ce script. Je suis conscient qu'il existe d'autres logiciels mais je suis strictement limité à l'utilisation de R et / ou SPSS ici ...
De plus, je suis très nouveau sur ces forums - j'ai essayé de fournir une explication aussi complète que possible, de démontrer les recherches antérieures que j'ai faites et de fournir également un exemple reproductible; J'espère que cela suffit, mais faites-moi savoir s'il y a autre chose que je peux fournir pour améliorer mon message.
EDIT: Nick a suggéré que j'utilise d'abord les totaux quotidiens. Je dois ajouter que j'ai testé cela et que les variables exogènes produisent des prévisions qui saisissent la saisonnalité quotidienne, hebdomadaire et annuelle. C'était l'une des autres raisons pour lesquelles je pensais prévoir chaque heure comme une série distincte, mais comme Nick l'a également mentionné, mes prévisions pour 16 heures un jour donné ne seront pas influencées par les heures précédentes de la journée.
EDIT: 09/08/13, le problème avec la boucle était simplement lié aux commandes d'origine que j'avais utilisées pour les tests. J'aurais dû repérer cela plus tôt et mettre plus d'urgence sur l'auto.arima pour travailler avec ces données - voir les points a) et d) ci-dessus.
Réponses:
Malheureusement, votre mission est vouée à l'échec car vous êtes limité à R et SPSS. Vous devez identifier la structure des relations entre les pistes et les décalages pour chacun des événements / vacances / variables exogènes qui peuvent entrer en jeu. Vous devez détecter d'éventuelles tendances temporelles que SPSS ne peut pas faire. Vous devez incorporer les tendances / prévisions quotidiennes dans chacune des prévisions horaires afin de fournir une prévision consolidée et réconciliée. Vous devez vous préoccuper de changer les paramètres et de changer la variance. J'espère que cela t'aides. Nous modélisons ce type de données depuis des années de manière automatique, sous réserve bien sûr de contrôles facultatifs spécifiés par l'utilisateur.
EDIT: Comme OP l'a demandé, je présente ici une analyse typique. J'en ai pris une si les heures étaient plus chargées et j'ai développé un modèle quotidien. Dans une analyse complète, les 24 heures seraient développées ainsi qu'un modèle quotidien afin de concilier les prévisions. Voici une liste partielle du modèle . En plus des régresseurs significatifs (notez que la structure réelle du plomb et du décalage a été omise), il y avait des indicateurs reflétant la saisonnalité, les changements de niveau, les effets quotidiens, les changements dans les effets quotidiens et les valeurs inhabituelles non cohérentes avec l'histoire. Les statistiques du modèle sont . Un graphique des prévisions pour les 360 prochains jours est présenté ici . Le graphique réel / ajustement / prévision résume parfaitement les résultatsFace à un problème extrêmement complexe (comme celui-ci!), Il faut faire preuve de beaucoup de courage, d'expérience et d'aides à la productivité informatique. Informez simplement votre direction que le problème est résolu mais pas nécessairement en utilisant des outils primitifs. J'espère que cela vous encourage à poursuivre vos efforts car vos commentaires précédents ont été très professionnels, orientés vers l'enrichissement personnel et l'apprentissage. J'ajouterais qu'il faut connaître la valeur attendue de cette analyse et l'utiliser comme ligne directrice lors de l'examen de logiciels supplémentaires. Peut-être avez-vous besoin d'une voix plus forte pour aider à orienter vos «directeurs» vers une solution réalisable à cette tâche difficile.
Après avoir examiné les totaux quotidiens et chacun des modèles de 24 heures, je penserais certainement que le nombre de visites est en grave baisse! Ce type d'analyse par un acheteur potentiel suggérerait un non-achat tandis qu'un vendeur serait sage de redoubler d'efforts pour vendre l'entreprise sur la base de cette projection très négative.
la source
Ce n'est qu'un paquet de commentaires mais ce sera trop long pour ce format. Je ne suis qu'un amateur de séries chronologiques, mais j'ai quelques suggestions simples.
Vous pouvez être sous les ordres ici, mais je pense que cela a besoin d'être affiné en termes de ce que vous attendez de réaliser et de ce qui est le plus important pour vous. La prévision des visites est malheureusement un objectif flou. Par exemple, supposons qu'il soit 16 heures et que vous souhaitiez prévoir les visites une heure à l'avance. Avez-vous vraiment besoin d'un super-modèle intégrant un traitement de toute la série précédente? Cela doit provenir d'une certaine considération des véritables objectifs pratiques et / ou scientifiques, qui peuvent être stipulés par vos supérieurs ou un client ou peuvent être les vôtres en tant que chercheur. Je soupçonne qu'il est plus probable que différents modèles soient nécessaires à des fins différentes.
La séparation des séries horaires semble être motivée par l'idée de réduire le calcul sans trop se soucier de son sens. Donc, l'implication est que vous n'utilisez pas (n'utiliserez pas) des informations plus tôt aujourd'hui pour prédire ce qui se passera à 16 heures, juste toutes les observations précédentes de 16 heures? Il me semble que cela nécessite beaucoup de discussions.
Vous êtes évidemment un apprenant dans les séries chronologiques (et je me mets sur un pied d'égalité) mais aucun apprenant ne devrait commencer avec un problème aussi gros. Vraiment! Vous avez beaucoup de données, vous avez des périodicités à plusieurs échelles, vous avez des irrégularités d'horaires et de jours fériés, vous avez des variables exogènes: vous avez choisi un problème très difficile. (Qu'en est-il aussi des tendances?) C'est facile à dire, mais cela vous a évidemment échappé jusqu'à présent: vous devrez peut-être d'abord travailler sur des versions très simplifiées du problème et avoir une idée de la façon d'adapter des modèles plus simples. Tout jeter dans un grand modèle compliqué ne fonctionne évidemment pas bien, et quelque chose de radicalement plus simple semble nécessaire, ou une prise de conscience que le projet est peut-être trop ambitieux.
la source