TomDoan wrote:You have the problem that I cited in the last reply---you are testing for exact 1's for calculations that will rarely be exact 1's. Try testing sin(x)^2+cos(x)^2==1 for various values of x, and you'll probably find half don't satisfy that. And the roots aren't even computed as exactly as sin and cos---roots are estimated to about eight digit precision.
In the procedure I have included the following
Code: Select all
set unitr 1 1001 = %round(unitr, 8)
set unitc 1 1001 = %round(unitc, 8)
and rounded these to 8
Code: Select all
set arrealz_0 1 %size(arroots) = %round(arrealz_0, 8)
set arimagz_0 1 %size(arroots) = %round(arimagz_0, 8)
set arrealz_1 1 %size(arroots) = %round(arrealz_1, 8)
set arimagz_1 1 %size(arroots) = %round(arimagz_1, 8)
set arrealz_2 1 %size(arroots) = %round(arrealz_2, 8)
set arimagz_2 1 %size(arroots) = %round(arimagz_2, 8)
also print
Code: Select all
prin / unitr unitc arrealz_0 arimagz_0 arrealz_1 arimagz_1 arrealz_2 arimagz_2
In the main program run the following model
Code: Select all
boxjenk(const,diffs=0,sdiffs=1,ar=0,sar=0,maxl,define=deq) writing
@acbjICRS deq writing
Resulting in, (only first 12 printed the rest are NA's)
ENTRY UNITR UNITC ARREALZ_0 ARIMAGZ_0 ARREALZ_1 ARIMAGZ_1 ARREALZ_2
1963:01 1.00000000 0.00000000 NA NA 1.0000000 0.0 NA
1963:02 0.99998026 0.00628314 NA NA 0.0000000 1.0 NA
1963:03 0.99992104 0.01256604 NA NA -0.8660254 0.5 NA
1963:04 0.99982235 0.01884844 NA NA NA NA -0.5000000
1963:05 0.99968419 0.02513010 NA NA NA NA -0.5000000
1963:06 0.99950656 0.03141076 NA NA -0.0000000 -1.0 NA
1963:07 0.99928947 0.03769018 NA NA NA NA 0.5000000
1963:08 0.99903293 0.04396812 NA NA -1.0000000 0.0 NA
1963:09 0.99873696 0.05024432 NA NA NA NA 0.5000000
1963:10 0.99840155 0.05651853 NA NA NA NA 0.8660254
1963:11 0.99802673 0.06279052 NA NA NA NA -0.8660254
1963:12 0.99761251 0.06906003 NA NA NA NA 0.8660254
ENTRY ARIMAGZ_2
1963:01 NA
1963:02 NA
1963:03 NA
1963:04 -0.8660254
1963:05 0.8660254
1963:06 NA
1963:07 0.8660254
1963:08 NA
1963:09 -0.8660254
1963:10 -0.5000000
1963:11 -0.5000000
1963:12 0.5000000
WRITING
inverse AR roots:
Real Imag Modulus Period
1.000 0.000 1.000
0.000 1.000 1.000 4.000
-0.866 0.500 1.000 2.400
-0.500 -0.866 1.000
-0.500 0.866 1.000 3.000
-0.000 -1.000 1.000
0.500 0.866 1.000 6.000
-1.000 -0.000 1.000
0.500 -0.866 1.000
0.866 -0.500 1.000
-0.866 -0.500 1.000
0.866 0.500 1.000 12.000
inverse MA roots:
Real Imag Modulus Period
I would expect the following
_0's = all NA's
_1's = UNITR and UNITC, aligned but not exact to 8 digit say
_2's = all NA's
i.e. SDIFFS=1, 12 unit roots equally spaced with the DOTS colored BLACK on the BLUE complex unit circle, as calculated in the report/table.
TomDoan wrote: But more important, you seem to be under the impression that if you change the labels, or make the graph more complicated, that you will get something useful out of it. You won't.
No. It is useful as a visual-aid. Further via color's I am just trying to make the DOTS easier to define. The labels is an explanation for ease in interpretation. As previously stated IMHO this is already a lot of code to color DOTS based on boundary values!
TomDoan wrote: The roots tell you basically nothing other than what you put into the model. If SDIFFS=1, you will get 12 unit roots equally spaced at the same locations regardless of the whether SDIFFS=1 was a good choice. ARMA models are useful because for a wide variety of types of dynamic behavior, you can find an ARMA model which at least reasonably approximates it. In fact, they are particularly useful because someone there is more than one such model. There are series that are a reasonable fit for an AR(2), for an ARMA(1,1) and for a relatively low order MA. Those will have widely different root patterns even though they imply very similar dynamic behavior---because the AR and MA roots don't really tell you much.
I have gained a better appreciation for ARIMA modelling. Thanks.