Seasonal Adjustment in EViews 14 – Calendar Variables and Lunar New Year
In our previous blog post we examined how JDemetra+ can be used to perform seasonal adjustment in EViews, producing results identical to (or at least extremely similar to) those given by the ubiquitous X-13 package from the US Census.
The previous post didn’t discuss one of the more popular features of seasonal adjustment; calendar adjustments. In this post we’ll rectify that by demonstrating how to use calendar adjustments in JDemetra+, as well as how to create your own calendar effects, should you wish to build upon the built-in features. In particular we’ll demonstrate adding a Lunar (Chinese) New Year variable for JDemetra+.
The X-11 based seasonal adjustment procedures offered by JDemetra+ and X-13 works by running an iterative decomposition of a series into trend, seasonality and irregular components though use of various moving average methods.
One of the assumptions of the decomposition step is that the underlying data are stochastic; not deterministic. This assumption is often violated, and so seasonal adjustment packages often offer the ability to be pre-process the data to detect and correct the impact of outliers, calendar effects, missing data, and other deterministic effects.
This pre-processing step uses an ARIMAX model remove any deterministics from the data process. The exogenous regressor part of the ARIMAX model can include dummy variable (or similar adjustment variables) to account for regular (or irregular) time based patterns. These variables may include the number of working/trading days in the month/quarter, the impact of irregular holidays (holidays that fall on different dates each year, such as Easter, Ramadan or Lunar New Year), or any other deterministic variables the user believes to be important.
Both X-13 and JDemetra+ have built in calendar effects that can optionally be included in the ARIMAX regression without the user having to create the variables themselves.
Built-in Calendar Effects
To demonstrate, as with our first blog post we’ll use monthly non-seasonally adjusted housing starts data from 1990 through 2023, which we retrieved from FRED.
JDemetera+ With Built-in Efects
As we mentioned in the previous post, JDemetra+ has a set of specifications that can be used to quickly set the options used for the seasonal adjustment. One of those specifications (the default, RSA4c) includes an ARIMAX model with outlier detection and correction, handling of the number of working days in each period, and adjustment for Easter effects.
To use this specification in EViews, all we need to do is open our series, and then select Proc->Seasonal Adjustment->JDemetra+… to bring up the JDemetra+ dialog:
Figure 1: JDemetra+ default dialog
Since RSA4c is the default specification, we do not need to make any changes to this page.
However, one of the built-in features of JDemetra+ is to automatically decide whether to include the deterministic variables or not. For this demonstration, we wish to always include them, so we’ll turn off the decision-making process. To do so we switch to the Regression tab and change both the Trading days Test and Easter Test dropdowns to None, and uncheck the leap year Auto-adjust box:
Then, we can click OK to produce the seasonally adjusted data:
Figure 3: JDemetra+ RSA4 output
We’ll rename the output HOUSTNSA_D11 series to be HOUST_D11_RSA4.
The difference between this RSA4c specification and the RSA3 specification we ran in the previous blog post is the inclusion of the working/trading day, leap-year effects, and Easter effects as built in exogenous variables.
Since JDemetra+ allows you to include your own exogenous variables, it should be possible to run the RSA3 specification with our own working day, leap year and Easter effects and match the results given by RSA4c.
To do so, we must first create our own variables in EViews – one for working days, one for leap year, and one for Easter.
Trading/Working Days
JDemetra+ has many different options for how to handle working days, but the default method, called TD2, is to count the number of Monday-Fridays in each period (month in our case) and subtract from it the number of Saturday and Sundays multiplied by 5/2.
Thanks to EViews’ useful @daycount function, we can create this variable manually in EViews with the following single line of code:
series td2 = @daycount(“Mon-Fri”) – 5/2*@daycount(“Sat-Sun”)
This TD2 specification incorporates the number of trading days in each month into a single regressor used in the ARIMAX estimation. There are 6 alternatives offered by JDemetra+, including:
TD7: Create a variable for the difference between the number of Mondays in each period and the number of Sundays, and then a second variable for the different between the number of Tuesdays in each period and the number of Sundays, and so on through to the difference between the number of Saturdays and the number of Sundays.
TD3: Create a variable for the difference between the number of week days and 5 times the number of Sundays, and a second variable for the difference between the number of Saturdays and the number of Sundays.
Leap year effects are also modelled through a regressor. For monthly data this is computed as a zero for all months other than February, and then a value of -0.25 for non-leap year Februarys and 0.75 for leap years. In EViews we could create this variable manually with:
series lp = (@daycount=28)*-0.25 + (@daycount=29)*0.75
Easter
Easter is handled in a slightly more complicated fashion. Firstly, Easter is, by default, thought of as an 8 day period ending on the day before Easter Sunday. These are 8 days where the underlying data’s seasonal patterns are affected by the Easter holiday. The Easter variable is calculated as the percentage of the 8-day-holiday that are in the current period minus the average percentage from the 8-day-holiday for that period between the years 1600 and 2099.
For example, in 2021 the 8 day Easter holiday ran from 27th March until 3rd April. Thus 5 (62.5%) of the 8 days were in March, and 3 (37.5%) were in April.
Between 1600 and 2099, the average percentage for March is 38.2%. The average percentage for April is 61.8%.
Therefore the Easter variable value for 2021 is zero for all months other than March, where it takes a value of 24.3 (62.5 – 38.2), and April where it takes a value of -24.3 (37.5 – 61.8).
Creating this variable in EViews takes a little bit of effort, since we need to create a new workfile page with dates running 1600 to 2099, and compute the Easter holiday. The latter is straight forward thanks to EViews’ useful @holiday function.
pagecreate(page=eastercalc) m 1600 2099
series easterspan = @holiday("easter(-8) easter(-1)")
series easter = easterspan - @meansby(easterspan, @month)
copy eastercalc\easter untitled\easter
pagedelete eastercalc
JDemetra+ With Manual Effects
With our set of exogenous variables created and put in our workfile:
Figure 4: Workfile
we can tell JDemetra+ to use them through the use of User Regressors. We use the default spec of RSA3 again, but switch to the User Regressors tab and Add our created variables:
Video 1: JDemetra+ User Regressor workflow
Note that when adding user regressors, JDemetra+ allows you to specify the type of regressor being added. For our purposes, the Undefined type of regressor suffices. (We could select Calendar/Trading Day, and then on the Regression tab switch the Trading Day type from None to User, which would give the same result.)
Clicking OK produces the output. We’ll rename the output series to HOUST_D11_RSA3CAL (to signify we used the RSA3 specification with our own calendar variables).
If we open this series along side the previous HOUST_D11_RSA4 series, we can see they are identical, proving that we can create our own calendar variables and add them to JDemetra+ producing the same results as the built-in calendar variables.
Figure 5: Comparison of RSA3CAL and RSA4 series
X-13 With Built-in Effects
If we wanted to perform the same sort of adjustment in the US Census X-13 package, we could do so by opening our series and selecting Proc->Seasonal Adjustment->Census X-13…
On the Transform tab we change the selection to Auto (None/log). On the X-13 built in regressor tab, we add a Trading-day 1 coef, and an 8 day Easter effect. We also add some automatic outliers, and change the ARIMA model to X-11 automatic:
Video 2: X-13 built-in regressors workflow
The results of the Census X-13 procedure are not numerically identical to those produced by JDemetra+, but they are close:
Figure 6: Comparison of RSA4 and X13 series
The following code reproduces what we have done so far:
wfcreate m 1990 2023
fetch(db=fred) houstnsa
houstnsa.jdemetra(spec=rsa4, noleapadj, eastertest=none, tradetest=none)
rename houstnsa_d11 houst_d11_rsa4
series td2 = @daycount("mon-fri")-5/2*@daycount("sat-sun")
series lp = (@daycount=28)*-0.25 + (@daycount=29)*0.75
pagecreate(page=eastercalc) m 1600 2099
series easterspan = @holiday("easter(-8) easter(-1)")
series easter = easterspan - @meansby(easterspan, @month)
copy eastercalc\easter untitled\easter
pagedelete eastercalc
houstnsa.jdemetra(spec=rsa3, userregs="td2 lp easter", usertypes="undef undef undef")
rename houstnsa_d11 houst_d11_rsa3cal
houstnsa.x13(save="d11", tf=auto, outtype="tc ao ls", html) @x11arima() @reg(regs="td1coef,easter[8]") @x11()
rename houstnsa_d11 houst_d11_x13
group compares houst_d11_rsa3cal houst_d11_rsa4 houst_d11_x13
show compares
Lunar New Year (aka Chinese New Year)
Now that we have demonstrated how to create our own Easter holiday variable for seasonal adjustment (as well as trading day and leap year), and how it matches the built-in variables, we can move on to creating variables for other holidays, such as Lunar New Year.
The Lunar New Year festival is an important holiday in many countries around the world, and the timing of the festival can have a large impact on economic variables.
In a recent paper, Song Yanfei, building upon a previous paper by Luan & Zhang, demonstrated how the festival can be modeled in Census X-13, and even suggested how the Akaike information criterion can be used to select the most appropriate number of days to model the festival when using X-13.
This methodology was incorporated into the CNY_EVP EViews Add-in by Ping An, which allows users to create exogenous variables for Lunar New Year, and include those variables in Census X-13. One of the suggestions of An (and previous authors) is to construct three separate variables for Lunar Near Year:
The period before the festival – ending on the day before Chuxi (Lunar New Year’s eve)
The period during the festival – starting on Chuxi and ending on Chuqi (the 7th day)
The period after the festival – starting on the day after Chuqi.
We’ll follow a similar process to model Lunar New Year effects in JDemetra’s seasonal adjustment. Following An’s suggestion, we will set the duration of the before period to 10 days, the duration of the during period to 8 days, and the duration of the after period to 10 days.
The computation of the individual variables is done in a similar manner to that used for Easter above – taking the percentage of the days of the period that fall in each month (or quarter) and subtract the average number of days that fall in that month over a number of years. Unlike Easter, we’ll just use the years within our data sample to take the average, rather than that 1600-2099 range used in Easter.
Again, using EViews’ built in @holiday function we can create these variables fairly easily with the following code:
series cny_b = @holiday("cny(-11) cny(-2)") - @meansby(@holiday("cny(-11) cny(-2)"), @month)
series cny_d = @holiday("cny(-1) cny(6)") - @meansby(@holiday("cny(-1) cny(6)"), @month)
series cny_a = @holiday("cny(7) cny(16)") - @meansby(@holiday("cny(7) cny(16)"), @month)
Where, for example, the term @holiday("cny(-11) cny(-2)") specifies the ten day period starting 11 days before Lunar New Year, and ending the day before Lunar New Year’s Eve.
With these variables created, we can perform JDemetra+ seasonal adjustment accounting for Lunar New Year in the same way we did previously:
Video 3: JDemetra+ Lunar New Year workflow
We can even instruct JDemetra+ to use one of its own trading day variables, alongside our own Lunar New Year variables:
Video 4: JDemetra+ use of trading day variables with Lunar New Year variables workflow
We can compare the output of this adjustment with that done by an unmodified RSA3 (i.e. without any calendar effects):
Figure 7: Comparison of LNY and RSA3 series
There is little difference. This is unsurprising – there is little economic reason to believe that Lunar New Year impacts house building in the United States. If we had economic data for an Asian country, there might be a significant impact!
No comments:
Post a Comment