You can specify any estimation method when fitting the ARIMA model to the input to determine the ARMA parameters used in the prewhitening filter, but when you compute the prewhitened series manually, residuals computed using METHOD = CLS match those obtained from applying the prewhitening filter, hence the final cross correlations will match. Different estimation methods would result in different forecasts hence different residuals. ... View more

In PROC AUTOREG, in addition to ARCH/GARCH model specification, you can also use HETERO statement to specify error variance function:   https://go.documentation.sas.com/doc/en/pgmsascdc/9.4_3.5/etsug/etsug_autoreg_syntax11.htm   And the HETERO statement can also be used with GARCH model together to specify additional variables in the variance function to the standard GARCH equation as discussed here:   https://go.documentation.sas.com/doc/en/pgmsascdc/9.4_3.5/etsug/etsug_autoreg_details12.htm#etsug.autoreg.heterogarch     PROC MODEL allows more flexible specification of error variance structures as discussed here:   https://go.documentation.sas.com/doc/en/pgmsascdc/9.4_3.5/etsug/etsug_model_sect133.htm   If you have specific form of heteroscedasticity but not sure how to specify your model, please provide more details.   ... View more

Hi @SAS_Illyrian  We did some further investigation, and our test confirmed that: (1). if you only specify P = option, and no Q = option is specified, then PROC VARMAX automatically forecasts future independent variables if they are not provided in the data set, using the same VAR model (the same order of P = option) for the dependent variables, then obtain forecast on the dependent variables using the thus forecasted independent variables for future periods ;   (2). if you specify Q = option(with or without P = option), then unfortunately the procedure does not automatically obtain forecasts if future independent variables are not provided in the data set, and issue the warning you observed in the log. This is a bug in the procedure and we are working on fix of this issue, so that in the future it will behave the same as when only p = is specified discussed in (1) above.    In the mean time, if you want future forecasts in case (2) then you may need to first forecast future independent variables yourself and save the future forecasts on the independent variables, then append the future forecasts to the end of the data. Then you can run PROC VARMAX on the appended data set to obtain future forecasts on the dependent variables.   I hope this helps. ... View more

Hi @Taliah  I think this is probably what you are confused about: If you look at the regression model with AR error process discussed in PROC AUTOREG documentation:   SAS Help Center: Autoregressive Error Model   you can see that there is a negative sign in front of the AR parameter φ1 in PROC AUTOREG specification, if you write the complete model with AR(1) error:   yt=xt′β+νt νt=ϵt−φ1*νt−1   since vt-1 = yt-1 - xt-1*β, this implies that    yt = xt*β - φ1*(y_t-1 - x_t-1*β) + ϵt        (1)     Note the negative sign in front of φ1 in the above equation. This has opposite sign for the AR parameter than that specified in the usual ARIMA model expression, as in PROC ARIMA:                                   yt = xt′β +   ϵt/ϕ(B) ,    where ϕ(B)=1−ϕ1B for AR(1) case.   If you multiply both sides of the above equation by (1−ϕ1B), then you get the following:   yt - ϕ1*y_t-1  = xt′β - ϕ1*x_t-1*β + ϵt    this implies   yt = ϕ1*y_t-1  +  xt′β - ϕ1*x_t-1*β + ϵt        (2)   If you compare (1) and (2), you can see that the two specifications have opposite signs on the AR parameter ϕ1.    I hope this helps.         ... View more

Is the OUTEST = option in PROC CALIS statement what you are looking for? see below:   https://go.documentation.sas.com/doc/en/pgmsascdc/9.4_3.5/statug/statug_calis_syntax13.htm#statug.calis.calisoutest   OUTEST=SAS-data-set creates an output data set that contains the parameter estimates, their gradient, Hessian matrix, and boundary and linear constraints. For METHOD=ML, METHOD=GLS, and METHOD=WLS, the OUTEST= data set also contains the information matrix, the approximate covariance matrix of the parameter estimates ((generalized) inverse of information matrix), and approximate standard errors.    For more details on this data set, see: https://go.documentation.sas.com/doc/en/pgmsascdc/9.4_3.5/statug/statug_calis_details07.htm#statug.calis.calisoutestds   The _TYPE_ = COV corresponds to covariance matrix of the parameter estimates.       ... View more

The %BOXCOXAR macro does not output AR parameter estimates.   I do not know if there is a specific process that one must follow which is considered 'the correct' approach. When I posted my previous response, I honestly did not think of such process you outlined:-) My previous response was only meant for some things you may consider to help you decide what large number to specify for AR = option for a process with MA terms in using the %BOXCOXAR macro. My thought was simply this, if you fit an AR model, with the differencing applied, though not transformed, the significance of the AR parameters will give you some indication, may not be accurate indication, if certain lags are better included when you specify the AR = option. You can also try some different AR orders and see if and how %BOXCOXAR results change.        ... View more

In order to further look into this and determine the cause, it may be necessary to have your data set to test the code. If you cannot upload the .sas7bdat file sufficient to produce the error here, perhaps you can open a case with Technical Support to get further help:   https://support.sas.com/en/technical-support.html     ... View more

Thank you! ... View more

Hi  @sasalex2024    When I said the two codes are 'essentially the same',  I was only saying in the sense that in both cases, first differencing is applied on both response series and input series before applying the prewhitening filter, even though the first code did not specify differencing on either the response series or the input series in the second IDENTIFY statement.  However, the two codes are *not exactly the same code*,  the different specifications could imply different handlings in some steps during the prewhitening stage, resulting in somewhat different prewhitened series, hence different ccfs. So it is a bit loose to say they are the same, and I should take the statement back to avoid confusion.   I hope that helps.         ... View more

hello @samp945    I cannot say doing the following will help you find a 'better ' model, but here are a couple of things you may consider when trying to explore model diagnostics:   1. you may find it helpful to plot the time series and see if you can visually identify some patterns. I used the following to produce a time series plot and the first thing that I noticed from the plot, is that there may be some level shift around 2016~2017, so having a CHECKBREAK option in the LEVEL statement may help.   proc timeseries data = a(where = (CauseOfDeath='Traffic')) plot = series; id DeathMonth interval = month; var count ; run;   2. you may consider starting from a baseline model similar to the following example in the doc(or some other baseline model you find appropriate for your data), and check for breaks in the baseline model using the CHECKBREAK option in the LEVEL statement,   SAS Help Center: A Seasonal Series with Linear Trend   I tried the above baseline model and the results seem to indicate level shift in Aug. 2016 in the baseline model.    3.  If level shift is confirmed in the baseline model (as is the case using the above baseline model),  you may want to include the level shift dummy variable as a regressor in the model, following shows an example of level shift detection and how to account for it:   https://go.documentation.sas.com/doc/en/pgmsascdc/9.4_3.5/etsug/etsug_ucm_examples07.htm     You may want to do some further data explorations that may help you find alternative candidate models that suite your data, but I hope the above several notes are helpful to you.         ... View more