basic questions/comments on X13
by Sven Schreiber
Hi,
I'm not usually in the business of needing to do seasonal adjustment
myself, but it seems I will be, and I'm wondering about the following
things about gretl:
- The documentation still mostly talks about X12. This concerns the
contents or menu column on the left of the main web page, the page
http://gretl.sourceforge.net/x12a/x12a.html to which it leads, various
places in the user guide, and also stuff like the $x12a and $x12adir
accessors. Even though I know that x13 works as a drop-in replacement, I
find this situation confusing. Isn't X12 by now really obsolete?
- AFAICS, there is no hansl scripting way to actually call X13 and get
its output, is there? When I use the GUI to invoke X13, I find no trace
of that in the command log.
- For a couple of years now, the open-source software JDemetra+ is the
official thing to do seasonal adjustment in Europe.
(https://github.com/jdemetra) Unfortunately, as the name suggests, it is
Java-based. There is an official R wrapper. I guess it should be
feasible to write a hansl wrapper for the R wrapper as a function
package, which sounds more complicated than it would be, I think. Of
course, the core still runs on Java, which therefore needs to be installed.
thanks
sven
4 years
probable bug with lost panel time
by Sven Schreiber
Hi,
it looks as if the panel-time information in the current dataset is lost
when:
1) a user-written hansl function is executed which internally plays
around with and repeatedly resets the sample
2) before calling that function, the current panel dataset is restricted
(in the time dimension)
Symptom: trying to use $obsdata works before calling the function, but
yields an error "won't work with the current periodicity". But $pd and
$datatype still work correctly.
Workaround: re-issue the setobs command after execution of the hansl
function, in my case: "setobs 4 1991:1 --panel-time"
Or to formulate my hypothesis differently: it seems that on exit from
the function, gretl somehow forgets to reinstate the previous panel time
properties when it reconstructs the state of the dataset that prevailed
at the time of calling the function. I believe that the problem didn't
show up for me when I was previously working with a dataset which was
*not* restricted at the outer level. So the sample restriction appears
to play a role.
This is with the latest snapshot (Dec 29th).
thanks
sven
4 years
Re: bug with fcast
by Allin Cottrell
On Tue, 4 Jan 2022, ESTEVEZ NUÑEZ JUAN CARLOS wrote:
> Hi Jack,
> Your code shows any error message with the Windows-32 zip version
> until 2018/05/11, but it fails with 2018/08/11 zip version, and
> following. Maybe some was made meanwhile that causes it.
Thanks for this observation!
I'm working on the bug. Following Juan Carlos's observation I diff'd
the relevant source files between gretl versions 2018s and 2018b. It
turns out that 2018b introduced a check on the length of the var->B
coefficient vector (in the function VAR_coeff_matrix_from_VECM in
irfboot.c), and this check wasn't general enough to validate the
var->B that results when an EC coefficient is restricted to equal 0.
The check expected a vector of length 4 but var->B was of length 3,
omitting the coefficient that was forced to zero.
I'm looking into this question: Should the check should be relaxed
under the restriction in question, or should var->B be sized as
expected by the existing check, including an explicit zero entry? I
suspect the latter is better, but once that's resolved a fix will be
applied.
Allin
4 years
Re: bug with fcast
by Riccardo (Jack) Lucchetti
On Tue, 4 Jan 2022, ESTEVEZ NUÑEZ JUAN CARLOS wrote:
> Hi Jack,
> Your code shows any error message with the Windows-32 zip version until 2018/05/11,
> but it fails with 2018/08/11 zip version, and following. Maybe some was made meanwhile that causes it.
> Hope helps.
Aaaah thanks Juan Carlos, this is very helpful.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
4 years
bug with fcast
by Riccardo (Jack) Lucchetti
Hi all (and happy new year),
I just found that we have a bug when forecasting from a VECM with
exogeneity restrictions (only with certain options for the deterministic
part). Example:
<hansl>
open sw_ch14.gdt
infl = 100 * sdiff(log(PUNEW))
vecm 2 1 infl LHUR --crt --quiet
restrict --full
b[1,1] = 1
a[1,1] = 0
end restrict
fcast infl
</hansl>
If you remove the line "a[1,1] = 0", everything is ok. Otherwise, you get
this message:
<output>
VAR coefficient matrix B is of wrong size!
Error executing script: halting
</output>
and on stderr:
<stderr>
B should have 1 or 4 rows, but has 3
var->B (3 x 2)
-0.00081327 0.14284
0.43167 0.053219
-0.58767 0.58294
</stderr>
This is with current git.
I'm just back, so I have quite a lot of stuff to look at before I have
time to debug this, but it'd be nice if you guys could try to have a look
at it too.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
4 years