Hola.

Yo trabajo bastante con modelos ARIMA para previsiones mensuales y
auto.arima (de forecast) y yo no solemos coincidir en la especificación.
auto.arima se resiste a diferenciar y eso da lugar a un p muy alto y
también, a veces, a unos q inaceptables (y como consecuencia correlación
excesiva entre los parámetros estimados). A veces lo utilizo como punto de
partida o como complemento a la identificación y diagnosis, pero no uso
automáticamente los modelos que devuelve.

Por otra parte, no estoy dispuesto a que me cambie la especificación de un
ARIMA sin "mi permiso", así que yo guardo los órdenes p,d,q, P,D,Q de mis
modelos en un archivo y reestimo la misma especificación cada mes (cuando
actualizo datos). Sólo si los residuos indican otra cosa me planteo cambiar
el modelo, cosa que no debería ocurrir con frecuencia.

Un saludo
Gregorio R. Serrano

El 6 de mayo de 2011 10:58, <jluis.gilsanz@tasacionesh.com> escribió:

> Hola:
>
> Si no recuerdo mal creo que este es mi primer post, así que espero no
> cometer ninguna "barbaridad"  y  que sean comprensivos conmigo.
> Retomo mi contacto con R después de una pequeña introducción que hice hace
> un par de años gracias a un curso de la UNED.
>
> El proyecto trata, a grandes rasgos de:
> 1.- Conectarse a un servidor Microsoft SQL y bajarse a R  unos datos de
> evolución de precios unitarios de vivienda (publicados por el Mto. de
> Fomento de España) por cuatrimestres (desde 1995 a 2010 hacen un total de
> 64 trimestres) y por provincias.
> 2.- Generar un bucle en el que para cada una de las 52 provincias se
> obtenga un modelo ARIMA automático, así como sus estimaciones a 3 años
> vista.
> 3.- Al final del bucle se guardara  en el SQL una tabla que contiene, para
> cada provincia, entre otras cosas, el modelo ajustado , los AIC,AICC,BIC,
> log-likehood, sigma2, así como una variable booleana que especifica si el
> modelo tiene TODOS sus coeficientes significativos. También guardare una
> tabla con las estimaciones efectuadas por cada modelo ajustada a cada
> provincia.
>
> Si alguien tiene interés en el código que he desarrollado se lo puedo
> proporcionar, o si se considera de interés publicarlo en la lista. No lo
> envío ahora por ser demasiado extenso.
>
> Para ello utilizo los paquetes RODBC para conectarme al SQL Server donde
> están los datos y forecast para calcular los modelos automatizados ARIMA,
> y aquí es donde radica el problema.
>
> A pesar de que según el autor del paquete se especifica en este articulo
> http://www.jstatsoft.org/v27/i03/paper que el algoritmo garantiza la
> obtención de un modelo valido, me he encontrado que alguno de los 52
> modelos ajustados tiene alguno de sus coeficientes no significativos
> (usando un nivel de significación de 0,05), a pesar de que usando tsdiag
> los gráficos muestran una buena diagnosis del modelo.
>
> Extrañado por ello me he decido aplicar, a modo de prueba,  el
> procedimiento de obtención de ARIMA automatizados del paquete forecast a
> la secuencia de datos AirPassengers con la que muchos aprendimos a
> trabajar con modelos ARIMA. Para dicha secuencia de datos el mejor modelo
> obtenido segun se especifico en su día por Box & Jenkins es un
> ARIMA(0,1,1)(0,1,1)[12] , mientras que el procedimiento automatizado del
> paquete forecast propone un modelo ARIMA(0,1,0)(0,0,2)[12]   usando la
> opción por pasos o bien un modelo ARIMA(2,1,1)(0,0,2)[12] with drift
> usando la opción que prueba con todos los modelos posibles.
> En ambos casos me sorprende que no haga ninguna diferenciación estacional
> a pesar de que se trata de una serie claramente estacional.
>
> Se me plantean muchas dudas que espero que me puedan resolver.
> ¿Estoy equivocando la forma de enfocar el proyecto?
> ¿Puedo confiar en el paquete forecast a pesar de estos resultados tan
> desconcertantes?
> ¿Existe algún otro paquete alternativo que me permita realizar algo
> similar?.
>
> Desde ya, muchísimas gracias por haber leído esta extensa exposición
>
> Muchas gracias
>
> Un saludo
>
> José Luis Gilsanz Gómez
>
>
>
> -- AVISO LEGAL --
>
> Los datos personales que en esta comunicación aparecen, así como los que
> nuestra
> empresa mantiene de Vd. y de su empresa, son tratados con la finalidad de
> mantener
> el contacto así como realizar las gestiones que en esta aparecen (Ley
> Orgánica
> 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal).
> Puede ejercer sus derechos de acceso, rectificación, cancelación y
> oposición
> dirigiéndose a atencion.clientes@tasacionesh.com
> La utilización de su dirección de correo electrónico por parte de nuestra
> empresa
> queda sujeta a las disposiciones de la Ley 34/2002, de Servicios de la
> Sociedad de
> la Información y el Comercio Electrónico. Si Vd. recibe comunicación
> comercial por
> nuestra parte y desea dejar de recibirla, rogamos nos lo comunique por vía
> electrónica
> a través de la dirección atencion.clientes@tasacionesh.com
>
>        [[alternative HTML version deleted]]
>
>
> _______________________________________________
> R-help-es mailing list
> R-help-es@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-help-es
>
>


-- 
Dr. Gregorio R. Serrano
Dpto. Economía Cuantitativa (UCM)
Voz:+34 91394 2361
Fax:+34 91394 2591
http://www.grserrano.es

	[[alternative HTML version deleted]]

