9:18 a.m.
Hi,
I have a csv file with daily data, where each calendar day is a row, but
it's actually 5-days-a-week data, i.e. weekend days do not contain data.
First I have a problem with the import, gretl only imports it as undated
because it says about the date labels:
"
erster Zeilenkopf "99-01-04", letzter Kopf "2014-05-19"
Behandlung als undatierte Daten
"
(=treating it as undated), but the reason given is not true, because the
first date string is actually:
"1999-01-04"
so there seems to be some problem with the date parsing.
Ok, I can work around that, defining it manually as 7-days-daily data
with the right starting date. Then I have the interface issue that at
the bottom it only says "daily" (in German), but I think it is important
here to show the distinction between 5- or 6- or 7-days-daily.
Next I would like to convert the workfile from 7-days-daily to
5-days-daily, i.e. remove the empty (=missings) weekends obs, but this
doesn't seem to be easy to do. (Note that removing all missing obs is
not equivalent, because that also eliminates other holidays, which is
another topic. Also I know I could use 'join' together with the source
csv file to do that, but I think it should be easier than that, no?)
When I try to work around that by removing all missing obs (including
the holidays) within the 7-days-daily workfile, I run into the old
problem that gretl then starts treating it as undated and the date
information is lost. Note that I cannot then manually set it to
5-days-daily because of the missing holidays which gretl doesn't know
about, i.e. the imposed dating produces errors, and this accumulates
over time.
The first thing mentioned is a bug, but any ideas about the other stuff?
Thanks,
sven
9:49 a.m.
On Wed, 21 May 2014, Sven Schreiber wrote:
Next I would like to convert the workfile from 7-days-daily to
5-days-daily, i.e. remove the empty (=missings) weekends obs, but this
doesn't seem to be easy to do. (Note that removing all missing obs is
not equivalent, because that also eliminates other holidays, which is
another topic. Also I know I could use 'join' together with the source
csv file to do that, but I think it should be easier than that, no?)
This should do what you want: not the most elegant approach, but IMO quite
clear and general. The only thing I don't like very much is the necessity
to go through a temporary file, which I find quite ugly. Allin, we talked
a bit about the possibility of having a "forever" option to the smpl
command, which would effectively eliminate certain rows from a dataset (so
that operations like "keep" and "drop" in Stata) become quite easy.
What
do you think?
<hansl>
nulldata 28
setobs 7 2014-04-01
x = normal()
print x -o
/*
trash weekends
*/
# first, construct a "weekend" dummy series
scalar y1 = $obsmajor[1]
scalar m1 = $obsminor[1]
scalar d1 = $obsmicro[1]
scalar wd1 = weekday(y1, m1, d1)
series wd = time + wd1 - 1
series we = (wd%7)==6 || (wd%7)==0
# clear periodicity
setobs 1 1
smpl we==0 --restrict
# use a tmpfile
store @dotdir/tmp.gdtb
clear
open @dotdir/tmp.gdtb --quiet
# ta-daaa!
setobs 5 2014-04-01
print x -o
</hansl>
-------------------------------------------------------
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
-------------------------------------------------------
1:34 p.m.
Am 21.05.2014 11:49, schrieb Riccardo (Jack) Lucchetti:
On Wed, 21 May 2014, Sven Schreiber wrote:
> Next I would like to convert the workfile from 7-days-daily to
> 5-days-daily, i.e. remove the empty (=missings) weekends obs, but this
> doesn't seem to be easy to do. (Note that removing all missing obs is
> not equivalent, because that also eliminates other holidays, which is
> another topic. Also I know I could use 'join' together with the source
> csv file to do that, but I think it should be easier than that, no?)
This should do what you want: not the most elegant approach, but IMO
quite clear and general. The only thing I don't like very much is the
necessity to go through a temporary file, which I find quite ugly.
Allin, we talked a bit about the possibility of having a "forever"
option to the smpl command, which would effectively eliminate certain
rows from a dataset (so that operations like "keep" and "drop" in
Stata)
become quite easy. What do you think?
I'm not Allin, but also related to the issue of the other holidays in
the data, this would be helpful I think. I would guess that people
working with daily data (which I rarely do) treat the time series as
being equally spaced over time (=as a standard time series) even though
it is not, strictly speaking, due to the weekends and holidays. I mean
that's what gretl also does with its 5-day-daily and 6-day-daily formats.
But currently in gretl I'm always losing the time-series property of my
workfile when I remove the missing holidays, and so I could not use the
built-in time series tools. My workaround has been to save this as a
special time series workfile with periodicity 1, so no date information
anymore. But this feels like a cludge (for example no daily dummies,
except if I created them beforehand).
/*
trash weekends
*/
# first, construct a "weekend" dummy series
scalar y1 = $obsmajor[1]
scalar m1 = $obsminor[1]
scalar d1 = $obsmicro[1]
scalar wd1 = weekday(y1, m1, d1)
series wd = time + wd1 - 1
series we = (wd%7)==6 || (wd%7)==0
Thanks Jack; I tried this more compactly with:
<hansl>
genr dummy # BTW, need a new syntax for this IMHO
series we = dummy_6 || dummy_7
</hansl>
but apparently the daily dummies are allocated "randomly", i.e. dummy_1
starts with whatever is the first obs in the workfile (or sample?), not
Monday or Sunday. Could this be changed perhaps?
thanks,
sven
1:47 p.m.
On Wed, 21 May 2014, Sven Schreiber wrote:
Thanks Jack; I tried this more compactly with:
<hansl>
genr dummy # BTW, need a new syntax for this IMHO
series we = dummy_6 || dummy_7
</hansl>
but apparently the daily dummies are allocated "randomly", i.e. dummy_1
starts with whatever is the first obs in the workfile (or sample?), not
Monday or Sunday. Could this be changed perhaps?
One of the things I would very much like to kill in 2.0 is "genr dummy";
actually, the "genr" keyword itself would go, if I had unlimited power ;)
-------------------------------------------------------
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
-------------------------------------------------------
1:49 p.m.
Am 21.05.2014 15:47, schrieb Riccardo (Jack) Lucchetti:
On Wed, 21 May 2014, Sven Schreiber wrote:
> Thanks Jack; I tried this more compactly with:
> <hansl>
> genr dummy # BTW, need a new syntax for this IMHO
> series we = dummy_6 || dummy_7
> </hansl>
> but apparently the daily dummies are allocated "randomly", i.e. dummy_1
> starts with whatever is the first obs in the workfile (or sample?), not
> Monday or Sunday. Could this be changed perhaps?
One of the things I would very much like to kill in 2.0 is "genr dummy";
actually, the "genr" keyword itself would go, if I had unlimited power ;)
Agreed (well, maybe deprecated and undocumented would be enough...); but
there should still be a script way of creating seasonal/periodic
dummies, and currently there is no alternative, or is there?
-s
2:15 p.m.
On Wed, 21 May 2014, Sven Schreiber wrote:
Am 21.05.2014 15:47, schrieb Riccardo (Jack) Lucchetti:
> On Wed, 21 May 2014, Sven Schreiber wrote:
>
>> Thanks Jack; I tried this more compactly with:
>> <hansl>
>> genr dummy # BTW, need a new syntax for this IMHO
>> series we = dummy_6 || dummy_7
>> </hansl>
>> but apparently the daily dummies are allocated "randomly", i.e.
dummy_1
>> starts with whatever is the first obs in the workfile (or sample?), not
>> Monday or Sunday. Could this be changed perhaps?
>
> One of the things I would very much like to kill in 2.0 is "genr dummy";
> actually, the "genr" keyword itself would go, if I had unlimited power ;)
>
Agreed (well, maybe deprecated and undocumented would be enough...); but
there should still be a script way of creating seasonal/periodic
dummies, and currently there is no alternative, or is there?
<hansl>
tmp = time % $pd
list DUMS = dummify(tmp)
</hansl>
-------------------------------------------------------
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
-------------------------------------------------------
2:35 p.m.
On 21/05/14 16:15, Riccardo (Jack) Lucchetti wrote:
On Wed, 21 May 2014, Sven Schreiber wrote:
> Am 21.05.2014 15:47, schrieb Riccardo (Jack) Lucchetti:
>> On Wed, 21 May 2014, Sven Schreiber wrote:
>>
>>> Thanks Jack; I tried this more compactly with:
>>> <hansl>
>>> genr dummy # BTW, need a new syntax for this IMHO
>>> series we = dummy_6 || dummy_7
>>> </hansl>
>>> but apparently the daily dummies are allocated "randomly", i.e.
>>> dummy_1
>>> starts with whatever is the first obs in the workfile (or sample?),
>>> not
>>> Monday or Sunday. Could this be changed perhaps?
>>
>> One of the things I would very much like to kill in 2.0 is "genr
>> dummy";
>> actually, the "genr" keyword itself would go, if I had unlimited
>> power ;)
>>
>
> Agreed (well, maybe deprecated and undocumented would be enough...); but
> there should still be a script way of creating seasonal/periodic
> dummies, and currently there is no alternative, or is there?
<hansl>
tmp = time % $pd
list DUMS = dummify(tmp)
</hansl>
I prefer that the number of each dummy corresponds with the observation:
tmp = (time-1)%$pd + 1
list DUMS = dummify(tmp)
--
Firma Arista
*Ignacio Díaz-Emparanza*
Zuzendaria/Director
ignacio.diaz-emparanza(a)ehu.es <mailto:ignacio.diaz.emparanza@ehu.es>
94 6013732
*EKONOMIA APLIKATUA III SAILA (EKONOMETRIA ETA ESTATISTIKA)/
DEPARTAMENTO DE ECONOMÍA APLICADA III (ECONOMETRÍA Y ESTADÍSTICA)
UPV/EHU*
Avda. Lehendakari Aguirre, 83 | 48015 BILBAO
*T.: +34 946013740* | *F.: +34 946013754*
*www.ea3.ehu.es* <http://www.ea3.ehu.es>
ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta
egotea. Mezuak badu bere hartzailea. Okerreko helbidera heldu bada
(helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari,
korreo honi erantzunda. Kontuz! Mezua ez bada zuretzat, ez erabili, ez
zabaldu beste inori, ez kopiatu eta ez baliatu.
¡ATENCIÓN! Este mensaje contiene información privilegiada o confidencial
a la que sólo tiene derecho a acceder el destinatario. Si usted lo
recibe por error le agradeceríamos que no hiciera uso de la información
y que se pusiese en contacto con el remitente.
E-mail hau inprimatu baino lehen egiaztatu inprimatzeko beharra.
Antes de imprimir este e-mail piense bien si es necesario hacerlo.
2:55 p.m.
Am 21.05.2014 16:35, schrieb Ignacio Diaz-Emparanza:
On 21/05/14 16:15, Riccardo (Jack) Lucchetti wrote:
> On Wed, 21 May 2014, Sven Schreiber wrote:
>
>>
>> Agreed (well, maybe deprecated and undocumented would be enough...); but
>> there should still be a script way of creating seasonal/periodic
>> dummies, and currently there is no alternative, or is there?
>
> <hansl>
> tmp = time % $pd
> list DUMS = dummify(tmp)
> </hansl>
I prefer that the number of each dummy corresponds with the observation:
tmp = (time-1)%$pd + 1
list DUMS = dummify(tmp)
Aren't you assuming that the workfile/sample actually starts with the
"right" obs here?
Anyway, thanks for all your suggestions, but what I really meant was a
function (or command) that mirrors the menu entry like 'genr dummy'
does, not some clever way to code it...
-sven
3:22 p.m.
On 21/05/14 16:55, Sven Schreiber wrote:
> I prefer that the number of each dummy corresponds with the
observation:
>
> tmp = (time-1)%$pd + 1
> list DUMS = dummify(tmp)
>
Aren't you assuming that the workfile/sample actually starts with the
"right" obs here?
No. Actually, no. This means assuming the first period as the reference
but it is only a convention.
I like this way of generating the seasonal dummies because when I make a
function valid for any seasonality it applies consistent names to the
dummies, and not different names depending on the value of $pd.
--
Firma Arista
*Ignacio Díaz-Emparanza*
Zuzendaria/Director
ignacio.diaz-emparanza(a)ehu.es <mailto:ignacio.diaz.emparanza@ehu.es>
94 6013732
*EKONOMIA APLIKATUA III SAILA (EKONOMETRIA ETA ESTATISTIKA)/
DEPARTAMENTO DE ECONOMÍA APLICADA III (ECONOMETRÍA Y ESTADÍSTICA)
UPV/EHU*
Avda. Lehendakari Aguirre, 83 | 48015 BILBAO
*T.: +34 946013740* | *F.: +34 946013754*
*www.ea3.ehu.es* <http://www.ea3.ehu.es>
ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta
egotea. Mezuak badu bere hartzailea. Okerreko helbidera heldu bada
(helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari,
korreo honi erantzunda. Kontuz! Mezua ez bada zuretzat, ez erabili, ez
zabaldu beste inori, ez kopiatu eta ez baliatu.
¡ATENCIÓN! Este mensaje contiene información privilegiada o confidencial
a la que sólo tiene derecho a acceder el destinatario. Si usted lo
recibe por error le agradeceríamos que no hiciera uso de la información
y que se pusiese en contacto con el remitente.
E-mail hau inprimatu baino lehen egiaztatu inprimatzeko beharra.
Antes de imprimir este e-mail piense bien si es necesario hacerlo.
3:25 p.m.
Am 21.05.2014 17:22, schrieb Ignacio Diaz-Emparanza:
On 21/05/14 16:55, Sven Schreiber wrote:
>> I prefer that the number of each dummy corresponds with the observation:
>>
>> tmp = (time-1)%$pd + 1
>> list DUMS = dummify(tmp)
>>
> Aren't you assuming that the workfile/sample actually starts with the
> "right" obs here?
>
>
No. Actually, no. This means assuming the first period as the reference
but it is only a convention.
I like this way of generating the seasonal dummies because when I make a
function valid for any seasonality it applies consistent names to the
dummies, and not different names depending on the value of $pd.
That's right, but I prefer that the dummy with "_1" in its name actually
refers to the first quarter/month, not some other convention.
-s
4:55 p.m.
On 21/05/14 17:25, Sven Schreiber wrote:
Am 21.05.2014 17:22, schrieb Ignacio Diaz-Emparanza:
> On 21/05/14 16:55, Sven Schreiber wrote:
>>> I prefer that the number of each dummy corresponds with the observation:
>>>
>>> tmp = (time-1)%$pd + 1
>>> list DUMS = dummify(tmp)
>>>
>> Aren't you assuming that the workfile/sample actually starts with the
>> "right" obs here?
>>
>>
> No. Actually, no. This means assuming the first period as the reference
> but it is only a convention.
> I like this way of generating the seasonal dummies because when I make a
> function valid for any seasonality it applies consistent names to the
> dummies, and not different names depending on the value of $pd.
>
That's right, but I prefer that the dummy with "_1" in its name actually
refers to the first quarter/month, not some other convention.
Yes, me too. This is what this two lines do (but not Jack's proposal).
"Dummify" (used in both alternatives) uses the convention that the
first dummy is omitted, so for example if you put the DUMS list and the
constant as regressors in a ols regression the constant represents the
first quarter/month.
--
Firma Arista
*Ignacio Díaz-Emparanza*
Zuzendaria/Director
ignacio.diaz-emparanza(a)ehu.es <mailto:ignacio.diaz.emparanza@ehu.es>
94 6013732
*EKONOMIA APLIKATUA III SAILA (EKONOMETRIA ETA ESTATISTIKA)/
DEPARTAMENTO DE ECONOMÍA APLICADA III (ECONOMETRÍA Y ESTADÍSTICA)
UPV/EHU*
Avda. Lehendakari Aguirre, 83 | 48015 BILBAO
*T.: +34 946013740* | *F.: +34 946013754*
*www.ea3.ehu.es* <http://www.ea3.ehu.es>
ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta
egotea. Mezuak badu bere hartzailea. Okerreko helbidera heldu bada
(helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari,
korreo honi erantzunda. Kontuz! Mezua ez bada zuretzat, ez erabili, ez
zabaldu beste inori, ez kopiatu eta ez baliatu.
¡ATENCIÓN! Este mensaje contiene información privilegiada o confidencial
a la que sólo tiene derecho a acceder el destinatario. Si usted lo
recibe por error le agradeceríamos que no hiciera uso de la información
y que se pusiese en contacto con el remitente.
E-mail hau inprimatu baino lehen egiaztatu inprimatzeko beharra.
Antes de imprimir este e-mail piense bien si es necesario hacerlo.
5:31 p.m.
Am 21.05.2014 18:55, schrieb Ignacio Diaz-Emparanza:
On 21/05/14 17:25, Sven Schreiber wrote:
> Am 21.05.2014 17:22, schrieb Ignacio Diaz-Emparanza:
>> On 21/05/14 16:55, Sven Schreiber wrote:
>>>> I prefer that the number of each dummy corresponds with the observation:
>>>>
>>>> tmp = (time-1)%$pd + 1
>>>> list DUMS = dummify(tmp)
>>>>
>>> Aren't you assuming that the workfile/sample actually starts with the
>>> "right" obs here?
>>>
>>>
>> No. Actually, no. This means assuming the first period as the reference
>> but it is only a convention.
>> I like this way of generating the seasonal dummies because when I make a
>> function valid for any seasonality it applies consistent names to the
>> dummies, and not different names depending on the value of $pd.
>>
> That's right, but I prefer that the dummy with "_1" in its name
actually
> refers to the first quarter/month, not some other convention.
Yes, me too. This is what this two lines do (but not Jack's proposal).
No I'm sorry, it doesn't do what I mean: I just tested it with a
workfile starting with 1950q2, and then your code gives a 'Dtmp_2' which
refers to *3rd* quarter, not the 2nd. That's because the 'time' variable
always starts with the same value, independent of the actual season of
the first obs.
-s
2:32 p.m.
On 21/05/14 19:31, Sven Schreiber wrote:
Am 21.05.2014 18:55, schrieb Ignacio Diaz-Emparanza:
>
> Yes, me too. This is what this two lines do (but not Jack's proposal).
No I'm sorry, it doesn't do what I mean: I just tested it with a
workfile starting with 1950q2, and then your code gives a 'Dtmp_2' which
refers to *3rd* quarter, not the 2nd. That's because the 'time' variable
always starts with the same value, independent of the actual season of
the first obs.
Ah, I'm sorry I was being confused by the "descriptive label" in the
main window.
A solution for monthly/quarterly data may be, with the use of $obsminor:
tmp=$obsminor
list DUMS = dummify(tmp)
but this is not valid for daily data.
--
Firma Arista
*Ignacio Díaz-Emparanza*
Zuzendaria/Director
ignacio.diaz-emparanza(a)ehu.es <mailto:ignacio.diaz.emparanza@ehu.es>
94 6013732
*EKONOMIA APLIKATUA III SAILA (EKONOMETRIA ETA ESTATISTIKA)/
DEPARTAMENTO DE ECONOMÍA APLICADA III (ECONOMETRÍA Y ESTADÍSTICA)
UPV/EHU*
Avda. Lehendakari Aguirre, 83 | 48015 BILBAO
*T.: +34 946013740* | *F.: +34 946013754*
*www.ea3.ehu.es* <http://www.ea3.ehu.es>
ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta
egotea. Mezuak badu bere hartzailea. Okerreko helbidera heldu bada
(helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari,
korreo honi erantzunda. Kontuz! Mezua ez bada zuretzat, ez erabili, ez
zabaldu beste inori, ez kopiatu eta ez baliatu.
¡ATENCIÓN! Este mensaje contiene información privilegiada o confidencial
a la que sólo tiene derecho a acceder el destinatario. Si usted lo
recibe por error le agradeceríamos que no hiciera uso de la información
y que se pusiese en contacto con el remitente.
E-mail hau inprimatu baino lehen egiaztatu inprimatzeko beharra.
Antes de imprimir este e-mail piense bien si es necesario hacerlo.
11:07 a.m.
New subject: For armax "diggers" Data sets for testing and a try to explain occasional armax aborting
For armax "diggers" Data sets for testing and a try to explain occasional armax
aborting
Data file attached # Script to select lag length in regression of d_u on lagged g #
u-unimployment (%) g-gdp rate (%)
## begin script # "Okun law" artifical data similar to POE-4, ch.9 open
mod2data.gdt include armax.gfn diff u1 # max lag length =4 lags 4; g1 # subsample for
equal data length whlile choosing smpl 1995:1 2013:4
list arg4 = 0 g1 g1_1 g1_2 g1_3 g1_4 list arg4a = g1 g1_1 g1_2 g1_3 g1_4
# uncomment for lag length selection # list arg3 = g1 g1_1 g1_2 g1_3 # list arg2 = g1 g1_1
g1_2 # list arg1 = g1 g1_1 # list arg0 = 0 g1
# works ok on my system, ARMA(0,1) by all ic armax(2, 2, d_u1, arg4, 1, 1, 1, 1, 0)
# gives "Failed to compute numerical Hessian" armax(2, 2, d_u1, arg4a, 1, 1, 1,
1, 0)
# armax(2, 2, d_u1, arg3, 1, 1, 0, 1, 0) # armax(2, 2, d_u1, arg2, 1, 1, 0, 1, 0) #
armax(2, 2, d_u1, arg1, 1, 1, 0, 1, 0) # armax(2, 2, d_u1, arg0, 1, 1, 0, 1, 0)
## end script
GUI's peculiar features: With arg4 and include constant chequed results are the
same as for script armax(2, 2, d_u1, arg4, 1, 1, 1, 1, 0) With arg4 and incl. const
unchequed ? armax(2, 2, d_u1, arg4, 0, 1, 0, 1, 0) Failed to compute numerical Hessian
With arg4a and include constant chequed ? armax(2, 2, d_u1, arg4a, 1, 1, 1, 1, 0) Failed
to compute numerical Hessian With arg4a and include constant unchequed ? armax(2, 2, d_u1,
arg4a, 1, 1, 0, 1, 0) Failed to compute numerical Hessian
Further diagnostics: armax(1, 2, d_u1, arg4a, 1, 1, 1, 1, 0) works ok arma 2 1 ; d_u1
arg4a Failed to compute numerical Hessian arma 2 1 ; d_u1 arg4a --opg works ok From
Command Reference(p.7) "Note that failure of the numerical Hessian computation is
generally an indicator of a misspecified model". From output: AR Root 1
1.0001 So, nothing enigmatic. Armax_auto would be more convenient if it scipped such
models instead of stopping the cycle.
11:17 a.m.
New subject: For armax "diggers" Data sets for testing and a try to explain occasional armax aborting
Yes. In my post in which I used the word "crash" inappropriately, I
suggested simply adding "catch" to the relevant function calls. Output
should then gracefully skip such instances, employing some form of text
(could be as simple as two dashes, with a footnote at the bottom) to
indicate this sort of failure rather than... permitting an error state
which cause armax to... cease its calculations in a surprising manner. TMN
On Wed, May 21, 2014 at 7:07 PM, <oleg_komashko(a)ukr.net> wrote:
For armax "diggers"
Data sets for testing and a try to explain occasional armax aborting
Data file attached
# Script to select lag length in regression of d_u on lagged g
# u-unimployment (%) g-gdp rate (%)
## begin script
# "Okun law" artifical data similar to POE-4, ch.9
open mod2data.gdt
include armax.gfn
diff u1
# max lag length =4
lags 4; g1
# subsample for equal data length whlile choosing
smpl 1995:1 2013:4
list arg4 = 0 g1 g1_1 g1_2 g1_3 g1_4
list arg4a = g1 g1_1 g1_2 g1_3 g1_4
# uncomment for lag length selection
# list arg3 = g1 g1_1 g1_2 g1_3
# list arg2 = g1 g1_1 g1_2
# list arg1 = g1 g1_1
# list arg0 = 0 g1
# works ok on my system, ARMA(0,1) by all ic
armax(2, 2, d_u1, arg4, 1, 1, 1, 1, 0)
# gives "Failed to compute numerical Hessian"
armax(2, 2, d_u1, arg4a, 1, 1, 1, 1, 0)
# armax(2, 2, d_u1, arg3, 1, 1, 0, 1, 0)
# armax(2, 2, d_u1, arg2, 1, 1, 0, 1, 0)
# armax(2, 2, d_u1, arg1, 1, 1, 0, 1, 0)
# armax(2, 2, d_u1, arg0, 1, 1, 0, 1, 0)
## end script
*GUI's peculiar features:*
With arg4 and include constant chequed results are
the same as for script armax(2, 2, d_u1, arg4, 1, 1, 1, 1, 0)
With arg4 and incl. const unchequed
? armax(2, 2, d_u1, arg4, 0, 1, 0, 1, 0)
Failed to compute numerical Hessian
With arg4a and include constant chequed
? armax(2, 2, d_u1, arg4a, 1, 1, 1, 1, 0)
Failed to compute numerical Hessian
With arg4a and include constant unchequed
? armax(2, 2, d_u1, arg4a, 1, 1, 0, 1, 0)
Failed to compute numerical Hessian
*Further diagnostics:*
armax(1, 2, d_u1, arg4a, 1, 1, 1, 1, 0) works ok
arma 2 1 ; d_u1 arg4a Failed to compute numerical Hessian
arma 2 1 ; d_u1 arg4a --opg works ok
From Command Reference(p.7) "Note that failure of the numerical
Hessian computation is generally an indicator of a misspecified model".
From output:
AR
Root 1 1.0001
So, nothing enigmatic.
Armax_auto would be more convenient if it scipped such models
instead of stopping the cycle.
!
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
--
Best regards,
Timothy M. Nall
Assistant Professor
National Quemoy University
Kinmen, Taiwan
2:46 p.m.
New subject: For armax "diggers" Data sets for testing and a try to explain occasional armax aborting
On Wed, 21 May 2014, oleg_komashko(a)ukr.net wrote:
For armax "diggers" Data sets for testing and a try to
explain
occasional armax aborting Data file attached [...]
You might try contacting the armax author, Yi-Nung Yang, and suggest a
patch if you have one. See http://gretlcycu.wordpress.com/about/ (foot of
the page) for contact info.
Allin Cottrell
3:12 p.m.
New subject: For armax "diggers" Data sets for testing and a try to explain occasional armax aborting
OKI Finish Ukr. version, write a patch and contact.
--- Оригінальне повідомлення ---
Від кого: "Allin Cottrell" < cottrell(a)wfu.edu >
Дата: 21 травня 2014, 17:49:02
On Wed, 21 May 2014, oleg_komashko(a)ukr.net wrote:
For armax "diggers" Data sets for testing and a try to
explain
occasional armax aborting Data file attached [...]
You might try contacting the armax author, Yi-Nung Yang, and suggest a
patch if you have one. See http://gretlcycu.wordpress.com/about/ (foot of
the page) for contact info.
Allin Cottrell
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
4:19 a.m.
New subject: For armax "diggers" Data sets for testing and a try to explain occasional armax aborting
Dear all,
Thanks for finding "armax" package useful. I eventually got time to solve
this beta release. I've just released a patch in which "occasional armax
aborting" should be fixed. Please give a trial.
Yi-Nung Yang (楊奕農)
Associate Professor
Department of IB, CYCU, Taiwan.
2014-05-21 19:07 GMT+08:00 <oleg_komashko(a)ukr.net>:
For armax "diggers"
Data sets for testing and a try to explain occasional armax aborting
Data file attached
# Script to select lag length in regression of d_u on lagged g
# u-unimployment (%) g-gdp rate (%)
## begin script
# "Okun law" artifical data similar to POE-4, ch.9
open mod2data.gdt
include armax.gfn
diff u1
# max lag length =4
lags 4; g1
# subsample for equal data length whlile choosing
smpl 1995:1 2013:4
list arg4 = 0 g1 g1_1 g1_2 g1_3 g1_4
list arg4a = g1 g1_1 g1_2 g1_3 g1_4
# uncomment for lag length selection
# list arg3 = g1 g1_1 g1_2 g1_3
# list arg2 = g1 g1_1 g1_2
# list arg1 = g1 g1_1
# list arg0 = 0 g1
# works ok on my system, ARMA(0,1) by all ic
armax(2, 2, d_u1, arg4, 1, 1, 1, 1, 0)
# gives "Failed to compute numerical Hessian"
armax(2, 2, d_u1, arg4a, 1, 1, 1, 1, 0)
# armax(2, 2, d_u1, arg3, 1, 1, 0, 1, 0)
# armax(2, 2, d_u1, arg2, 1, 1, 0, 1, 0)
# armax(2, 2, d_u1, arg1, 1, 1, 0, 1, 0)
# armax(2, 2, d_u1, arg0, 1, 1, 0, 1, 0)
## end script
*GUI's peculiar features:*
With arg4 and include constant chequed results are
the same as for script armax(2, 2, d_u1, arg4, 1, 1, 1, 1, 0)
With arg4 and incl. const unchequed
? armax(2, 2, d_u1, arg4, 0, 1, 0, 1, 0)
Failed to compute numerical Hessian
With arg4a and include constant chequed
? armax(2, 2, d_u1, arg4a, 1, 1, 1, 1, 0)
Failed to compute numerical Hessian
With arg4a and include constant unchequed
? armax(2, 2, d_u1, arg4a, 1, 1, 0, 1, 0)
Failed to compute numerical Hessian
*Further diagnostics:*
armax(1, 2, d_u1, arg4a, 1, 1, 1, 1, 0) works ok
arma 2 1 ; d_u1 arg4a Failed to compute numerical Hessian
arma 2 1 ; d_u1 arg4a --opg works ok
From Command Reference(p.7) "Note that failure of the numerical
Hessian computation is generally an indicator of a misspecified model".
From output:
AR
Root 1 1.0001
So, nothing enigmatic.
Armax_auto would be more convenient if it scipped such models
instead of stopping the cycle.
!
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
9:08 p.m.
New subject: testing : For armax "diggers" Data sets for testing and a try to explain occasional armax aborting
Script works OK. Perfectly what I wanted to see. It seems a minor problem still here.
With the same dataset 1) ? armax(2, 2, d_u1, arg4, 1, 1, 0, 1, 0)
=============================================== Information Criteria of ARMAX(p,q) for
d_u1 ----------------------------------------------- p, q AIC BIC
HQC ----------------------------------------------- 0, 0 -37.3129 -23.3285
-31.7241 0, 1 -42.3039* -23.6580* -34.8521* 0, 2 -40.3043
-19.3277 -31.9210 1, 0 -41.6550 -23.0091 -34.2032 1, 1
-40.3044 -19.3278 -31.9212 1, 2 -38.4888 -15.1814 -29.1740 2,
0 -39.9916 -19.0150 -31.6084 2, 1 -41.8505 -18.5432
-32.5358 2, 2 -40.0419 -14.4038 -29.7956
=============================================== * indicates best models.
'9999.9999' suggests failures to estimate the models. 2) ? armax(2, 2, d_u1,!
arg4, 0, 1, 0, 1, 0) Failed to compute numerical Hessian tarmax: Got error 35 (Not a
Number in calculation) while p=2,q=1 ===============================================
Information Criteria of ARMAX(p,q) for d_u1
----------------------------------------------- p, q AIC BIC
HQC ----------------------------------------------- 0, 0 20.9510 32.6047
25.6084 0, 1 -7.6589 8.6562 -1.1386 0, 2 -11.3398 7.3061
-3.8880 1, 0 -21.4701 -5.1549 -14.9498 1, 1 -29.2140
-10.5681 -21.7622 1, 2 -33.8166 -12.8400* -25.4334* 2, 0
-20.7024 -2.0566 -13.2506 2, 1 99999.9999 99999.9999 99999.9999 2,
2 -33.8851* -10.5778 -24.5704
=============================================== * indicates best models.
'9999.9999' suggest!
s failures to estimate the models. 3) ? armax(2, 2, d_u1, arg4a, 1, 1
, 0, 1, 0) the same as 2) 4) ? armax(2, 2, d_u1, arg4a, 0, 1, 0, 1, 0) the same as 2) List
arg4a is the same as arg4 only constant dropped. So it seems there is problem with the 5th
argument to armax With "0" it excludes constant even if it is in exogenous list.
But if exogenous list doesn't include constant, "1" do nothing and model
estimated without constant I think the simplest way to correct is as follows check if
there is a constant in the exogenous variables list, drop it with "1" add
"0" to arma (e.g. arma 2 2 ; d_u1 0 arg4a) or add constant to the list and
don't use "0" in arma The exact way of interaction should included in help
Another way: this argument can be dropped and help should tell that constant can be
included in ex.var. list
02 вересня 2014, 07:19:47, Автор yinung at Gmail < yinung.cycu(a)gmail.com >:
Dear all,
Thanks for finding "armax" package useful. I eventually got time to solve this
beta release. I've just released a patch in which " occasional armax
aborting" should be fixed. Please give a trial.
Yi-Nung Yang (楊奕農)
Associate Professor
Department of IB, CYCU, Taiwan.
2014-05-21 19:07 GMT+08:00 < oleg_komashko(a)ukr.net > :
For armax "diggers" Data sets for testing and a try to explain occasional armax
aborting
Data file attached # Script to select lag length in regression of d_u on lagged g #
u-unimployment (%) g-gdp rate (%)
## begin script # "Okun law" artifical data similar to POE-4, ch.9 open
mod2data.gdt include armax.gfn diff u1 # max lag length =4 lags 4; g1 # subsample for
equal data length whlile choosing smpl 1995:1 2013:4
list arg4 = 0 g1 g1_1 g1_2 g1_3 g1_4 list arg4a = g1 g1_1 g1_2 g1_3 g1_4
# uncomment for lag length selection # list arg3 = g1 g1_1 g1_2 g1_3 # list arg2 = g1 g1_1
g1_2 # list arg1 = g1 g1_1 # list arg0 = 0 g1
# works ok on my system, ARMA(0,1) by all ic armax(2, 2, d_u1, arg4, 1, 1, 1, 1, 0)
# gives "Failed to compute numerical Hessian" armax(2, 2, d_u1, arg4a, 1, 1, 1,
1, 0)
# armax(2, 2, d_u1, arg3, 1, 1, 0, 1, 0) # armax(2, 2, d_u1, arg2, 1, 1, 0, 1, 0) #
armax(2, 2, d_u1, arg1, 1, 1, 0, 1, 0) # armax(2, 2, d_u1, arg0, 1, 1, 0, 1, 0)
## end script
GUI's peculiar features: With arg4 and include constant chequed results are the
same as for script armax(2, 2, d_u1, arg4, 1, 1, 1, 1, 0) With arg4 and incl. const
unchequed ? armax(2, 2, d_u1, arg4, 0, 1, 0, 1, 0) Failed to compute numerical Hessian
With arg4a and include constant chequed ? armax(2, 2, d_u1, arg4a, 1, 1, 1, 1, 0) Failed
to compute numerical Hessian With arg4a and include constant unchequed ? armax(2, 2, d_u1,
arg4a, 1, 1, 0, 1, 0) Failed to compute numerical Hessian
Further diagnostics: armax(1, 2, d_u1, arg4a, 1, 1, 1, 1, 0) works ok arma 2 1 ; d_u1
arg4a Failed to compute numerical Hessian arma 2 1 ; d_u1 arg4a --opg works ok From
Command Reference(p.7) "Note that failure of the numerical Hessian computation is
generally an indicator of a misspecified model". From output: AR Root 1
1.0001 So, nothing enigmatic. Armax_auto would be more convenient if it scipped such
models instead of stopping the cycle. !
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
3:49 a.m.
New subject: testing : For armax "diggers" Data sets for testing and a try to explain occasional armax aborting
Dear all,
Thanks for quick testing and suggestions.
>>with the 5th argument to armax With "0" it excludes
constant even if it
is in exogenous list.
This was originally to mimic command "arima" with no constant,",--nc,
option.
>>But if exogenous list doesn't include constant,
"1" do nothing and
model estimated without constant
Now this problem should be solved. With the option "include a constant," no
matter exogenous list has a constant or not, a constant is always included.
Thanks for your comments and useful suggestions
Yi-Nung Yang
IB department, CYCU, Taiwan.
2014-09-04 5:08 GMT+08:00 <oleg_komashko(a)ukr.net>:
Script works OK. Perfectly what I wanted to see. It seems a minor
problem
still here.
With the same dataset
1)
? armax(2, 2, d_u1, arg4, 1, 1, 0, 1, 0)
===============================================
Information Criteria of ARMAX(p,q) for d_u1
-----------------------------------------------
p, q AIC BIC HQC
-----------------------------------------------
0, 0 -37.3129 -23.3285 -31.7241
0, 1 -42.3039* -23.6580* -34.8521*
0, 2 -40.3043 -19.3277 -31.9210
1, 0 -41.6550 -23.0091 -34.2032
1, 1 -40.3044 -19.3278 -31.9212
1, 2 -38.4888 -15.1814 -29.1740
2, 0 -39.9916 -19.0150 -31.6084
2, 1 -41.8505 -18.5432 -32.5358
2, 2 -40.0419 -14.4038 -29.7956
===============================================
* indicates best models.
'9999.9999' suggests failures to estimate the models.
2)
? armax(2, 2, d_u1, arg4, 0, 1, 0, 1, 0)
Failed to compute numerical Hessian
tarmax: Got error 35 (Not a Number in calculation) while p=2,q=1
===============================================
Information Criteria of ARMAX(p,q) for d_u1
-----------------------------------------------
p, q AIC BIC HQC
-----------------------------------------------
0, 0 20.9510 32.6047 25.6084
0, 1 -7.6589 8.6562 -1.1386
0, 2 -11.3398 7.3061 -3.8880
1, 0 -21.4701 -5.1549 -14.9498
1, 1 -29.2140 -10.5681 -21.7622
1, 2 -33.8166 -12.8400* -25.4334*
2, 0 -20.7024 -2.0566 -13.2506
2, 1 99999.9999 99999.9999 99999.9999
2, 2 -33.8851* -10.5778 -24.5704
===============================================
* indicates best models.
'9999.9999' suggests failures to estimate the models.
3) ? armax(2, 2, d_u1, arg4a, 1, 1, 0, 1, 0) the same as 2)
4) ? armax(2, 2, d_u1, arg4a, 0, 1, 0, 1, 0) the same as 2)
List arg4a is the same as arg4 only constant dropped. So it seems there is
problem
with the 5th argument to armax With "0" it excludes constant even if it is
in exogenous list.
But if exogenous list doesn't include constant, "1" do nothing and model
estimated without constant
I think the simplest way to correct is as follows
check if there is a constant in the exogenous variables list, drop it
with "1" add "0" to arma (e.g. arma 2 2 ; d_u1 0 arg4a)
or add constant to the list and don't use "0" in arma
The exact way of interaction should included in help
Another way: this argument can be dropped and help should tell
that constant can be included in ex.var. list
02 вересня 2014, 07:19:47, Автор yinung at Gmail <yinung.cycu(a)gmail.com>:
Dear all,
Thanks for finding "armax" package useful. I eventually got time to solve
this beta release. I've just released a patch in which "occasional armax
aborting" should be fixed. Please give a trial.
Yi-Nung Yang (楊奕農)
Associate Professor
Department of IB, CYCU, Taiwan.
2014-05-21 19:07 GMT+08:00 <oleg_komashko(a)ukr.net>:
For armax "diggers"
Data sets for testing and a try to explain occasional armax aborting
Data file attached
# Script to select lag length in regression of d_u on lagged g
# u-unimployment (%) g-gdp rate (%)
## begin script
# "Okun law" artifical data similar to POE-4, ch.9
open mod2data.gdt
include armax.gfn
diff u1
# max lag length =4
lags 4; g1
# subsample for equal data length whlile choosing
smpl 1995:1 2013:4
list arg4 = 0 g1 g1_1 g1_2 g1_3 g1_4
list arg4a = g1 g1_1 g1_2 g1_3 g1_4
# uncomment for lag length selection
# list arg3 = g1 g1_1 g1_2 g1_3
# list arg2 = g1 g1_1 g1_2
# list arg1 = g1 g1_1
# list arg0 = 0 g1
# works ok on my system, ARMA(0,1) by all ic
armax(2, 2, d_u1, arg4, 1, 1, 1, 1, 0)
# gives "Failed to compute numerical Hessian"
armax(2, 2, d_u1, arg4a, 1, 1, 1, 1, 0)
# armax(2, 2, d_u1, arg3, 1, 1, 0, 1, 0)
# armax(2, 2, d_u1, arg2, 1, 1, 0, 1, 0)
# armax(2, 2, d_u1, arg1, 1, 1, 0, 1, 0)
# armax(2, 2, d_u1, arg0, 1, 1, 0, 1, 0)
## end script
*GUI's peculiar features:*
With arg4 and include constant chequed results are
the same as for script armax(2, 2, d_u1, arg4, 1, 1, 1, 1, 0)
With arg4 and incl. const unchequed
? armax(2, 2, d_u1, arg4, 0, 1, 0, 1, 0)
Failed to compute numerical Hessian
With arg4a and include constant chequed
? armax(2, 2, d_u1, arg4a, 1, 1, 1, 1, 0)
Failed to compute numerical Hessian
With arg4a and include constant unchequed
? armax(2, 2, d_u1, arg4a, 1, 1, 0, 1, 0)
Failed to compute numerical Hessian
*Further diagnostics:*
armax(1, 2, d_u1, arg4a, 1, 1, 1, 1, 0) works ok
arma 2 1 ; d_u1 arg4a Failed to compute numerical Hessian
arma 2 1 ; d_u1 arg4a --opg works ok
From Command Reference(p.7) "Note that failure of the numerical
Hessian computation is generally an indicator of a misspecified model".
From output:
AR
Root 1 1.0001
So, nothing enigmatic.
Armax_auto would be more convenient if it scipped such models
instead of stopping the cycle.
!
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
_______________________________________________
Gretl-users mailing
listGretl-users@lists.wfu.eduhttp://lists.wfu.edu/mailman/listinfo/gretl-users
!
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
9:26 a.m.
New subject: Re [2]: testing 0.92 OK!
Dear Yi-Nung Yang, Now everything is perfect both with the GUI and the script. Are you
planning to generalize to seasonal ARMA? A possible way is to translate Hyndman's
approach in his autoarima{forecast} in R.
04 вересня 2014, 06:50:13, Автор yinung at Gmail < yinung.cycu(a)gmail.com >:
Dear all,
Thanks for quick testing and suggestions.
>>with the 5th argument to armax With "0" it excludes
constant even if it is in exogenous list.
This was originally to mimic command
"arima" with no constant,",--nc, option.
>>But if exogenous list doesn't include constant,
"1" do nothing and model estimated without constant Now this problem sho uld be
solved . With the option "include a constant ," no matter exogenous list has a
constant or not, a constant is always in cluded .
Thanks for your comments and useful suggestions
Yi-Nung Yang
IB department, CYCU, Taiwan.
2014-09-04 5:08 GMT+08:00 < oleg_komashko(a)ukr.net > :
Script works OK. Perfectly what I wanted to see. It seems a minor problem still here.
With the same dataset 1) ? armax(2, 2, d_u1, arg4, 1, 1, 0, 1, 0)
=============================================== Information Criteria of ARMAX(p,q) for
d_u1 ----------------------------------------------- p, q AIC BIC
HQC ----------------------------------------------- 0, 0 -37.3129 -23.3285
-31.7241 0, 1 -42.3039* -23.6580* -34.8521* 0, 2 -40.3043
-19.3277 -31.9210 1, 0 -41.6550 -23.0091 -34.2032 1, 1
-40.3044 -19.3278 -31.9212 1, 2 -38.4888 -15.1814 -29.1740 2,
0 -39.9916 -19.0150 -31.6084 2, 1 -41.8505 -18.5432
-32.5358 2, 2 -40.0419 -14.4038 -29.7956
=============================================== * indicates best models.
'9999.9999' suggests failures to estimate the models. 2) ? armax(2, 2, d_u1,!
arg4, 0, 1, 0, 1, 0) Failed to compute numerical Hessian tarmax: Got error 35 (Not a
Number in calculation) while p=2,q=1 ===============================================
Information Criteria of ARMAX(p,q) for d_u1
----------------------------------------------- p, q AIC BIC
HQC ----------------------------------------------- 0, 0 20.9510 32.6047
25.6084 0, 1 -7.6589 8.6562 -1.1386 0, 2 -11.3398 7.3061
-3.8880 1, 0 -21.4701 -5.1549 -14.9498 1, 1 -29.2140
-10.5681 -21.7622 1, 2 -33.8166 -12.8400* -25.4334* 2, 0
-20.7024 -2.0566 -13.2506 2, 1 99999.9999 99999.9999 99999.9999 2,
2 -33.8851* -10.5778 -24.5704
=============================================== * indicates best models.
'9999.9999' suggest!
s failures to estimate the models. 3) ? armax(2, 2, d_u1, arg4a, 1, 1
, 0, 1, 0) the same as 2) 4) ? armax(2, 2, d_u1, arg4a, 0, 1, 0, 1, 0) the same as 2) List
arg4a is the same as arg4 only constant dropped. So it seems there is problem with the 5th
argument to armax With "0" it excludes constant even if it is in exogenous list.
But if exogenous list doesn't include constant, "1" do nothing and model
estimated without constant I think the simplest way to correct is as follows check if
there is a constant in the exogenous variables list, drop it with "1" add
"0" to arma (e.g. arma 2 2 ; d_u1 0 arg4a) or add constant to the list and
don't use "0" in arma The exact way of interaction should included in help
Another way: this argument can be dropped and help should tell that constant can be
included in ex.var. list
02 вересня 2014, 07:19:47, Автор yinung at Gmail < yinung.cycu(a)gmail.com >:
Dear all,
Thanks for finding "armax" package useful. I eventually got time to solve this
beta release. I've just released a patch in which " occasional armax
aborting" should be fixed. Please give a trial.
Yi-Nung Yang (楊奕農)
Associate Professor
Department of IB, CYCU, Taiwan.
2014-05-21 19:07 GMT+08:00 < oleg_komashko(a)ukr.net > :
For armax "diggers" Data sets for testing and a try to explain occasional armax
aborting
Data file attached # Script to select lag length in regression of d_u on lagged g #
u-unimployment (%) g-gdp rate (%)
## begin script # "Okun law" artifical data similar to POE-4, ch.9 open
mod2data.gdt include armax.gfn diff u1 # max lag length =4 lags 4; g1 # subsample for
equal data length whlile choosing smpl 1995:1 2013:4
list arg4 = 0 g1 g1_1 g1_2 g1_3 g1_4 list arg4a = g1 g1_1 g1_2 g1_3 g1_4
# uncomment for lag length selection # list arg3 = g1 g1_1 g1_2 g1_3 # list arg2 = g1 g1_1
g1_2 # list arg1 = g1 g1_1 # list arg0 = 0 g1
# works ok on my system, ARMA(0,1) by all ic armax(2, 2, d_u1, arg4, 1, 1, 1, 1, 0)
# gives "Failed to compute numerical Hessian" armax(2, 2, d_u1, arg4a, 1, 1, 1,
1, 0)
# armax(2, 2, d_u1, arg3, 1, 1, 0, 1, 0) # armax(2, 2, d_u1, arg2, 1, 1, 0, 1, 0) #
armax(2, 2, d_u1, arg1, 1, 1, 0, 1, 0) # armax(2, 2, d_u1, arg0, 1, 1, 0, 1, 0)
## end script
GUI's peculiar features: With arg4 and include constant chequed results are the
same as for script armax(2, 2, d_u1, arg4, 1, 1, 1, 1, 0) With arg4 and incl. const
unchequed ? armax(2, 2, d_u1, arg4, 0, 1, 0, 1, 0) Failed to compute numerical Hessian
With arg4a and include constant chequed ? armax(2, 2, d_u1, arg4a, 1, 1, 1, 1, 0) Failed
to compute numerical Hessian With arg4a and include constant unchequed ? armax(2, 2, d_u1,
arg4a, 1, 1, 0, 1, 0) Failed to compute numerical Hessian
Further diagnostics: armax(1, 2, d_u1, arg4a, 1, 1, 1, 1, 0) works ok arma 2 1 ; d_u1
arg4a Failed to compute numerical Hessian arma 2 1 ; d_u1 arg4a --opg works ok From
Command Reference(p.7) "Note that failure of the numerical Hessian computation is
generally an indicator of a misspecified model". From output: AR Root 1
1.0001 So, nothing enigmatic. Armax_auto would be more convenient if it scipped such
models instead of stopping the cycle. !
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
!
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
6:42 p.m.
On Wed, 21 May 2014, Sven Schreiber wrote:
I have a csv file with daily data, where each calendar day is a row,
but
it's actually 5-days-a-week data, i.e. weekend days do not contain data.
First I have a problem with the import, gretl only imports it as undated
because it says about the date labels:
"
erster Zeilenkopf "99-01-04", letzter Kopf "2014-05-19"
Behandlung als undatierte Daten
"
(=treating it as undated), but the reason given is not true, because the
first date string is actually:
"1999-01-04"
so there seems to be some problem with the date parsing.
Just for the record, we determined off-list that this was an old problem,
fixed in the gretl 1.9.90 release.
Allin
3515
days inactive
3621
days old
21 comments
7 participants
participants (7)
-
Allin Cottrell -
Ignacio Diaz-Emparanza -
oleg_komashko＠ukr.net -
Riccardo (Jack) Lucchetti -
Sven Schreiber -
Tim Nall -
yinung＠Gmail