11:54 a.m.
Hi,
a quite simple question actually: is there a one-liner that adds
seasonal dummies to the workfile in a script, similiar to the one-click
option in the GUI?
What I have is a loop like this (untested BTW):
loop i=1..$pd
series dum$i = ($obsminor==$i)
endloop
But there must be a shorter way I guess.
thanks,
sven
12:01 p.m.
Dear Sven,
I think "genr dummy" can do what you need.
Best,
Henrique
Enviado via iPhone
Em 15/02/2013, às 09:54, Sven Schreiber <svetosch(a)gmx.net> escreveu:
Hi,
a quite simple question actually: is there a one-liner that adds
seasonal dummies to the workfile in a script, similiar to the one-click
option in the GUI?
What I have is a loop like this (untested BTW):
loop i=1..$pd
series dum$i = ($obsminor==$i)
endloop
But there must be a shorter way I guess.
thanks,
sven
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
12:10 p.m.
Am 15.02.2013 13:01, schrieb Henrique Andrade:
Dear Sven,
I think "genr dummy" can do what you need.
Yes indeed! And it even shows up in the command log which I should have
checked before.
I'm only noting that in this case 'series dummy' is not equivalent to
'genr dummy' (the former produces an empty series named "dummy"), and
secondly that this doesn't seem to appear in the user guide. (It's in
the built-in help under genr, however.)
thanks,
sven
3:18 p.m.
On Fri, 15 Feb 2013, Sven Schreiber wrote:
Am 15.02.2013 13:01, schrieb Henrique Andrade:
> Dear Sven,
>
> I think "genr dummy" can do what you need.
Yes indeed! And it even shows up in the command log which I should have
checked before.
I'm only noting that in this case 'series dummy' is not equivalent to
'genr dummy' (the former produces an empty series named "dummy"), and
secondly that this doesn't seem to appear in the user guide. (It's in
the built-in help under genr, however.)
The doc could do with an update on this sort of thing. In
general "genr x" and "series x" are not equivalent: the former
provokes the error "No formula supplied in genr" while the
latter creates an NA series. As you know, "genr" is (sort of)
deprecated for general use; it's considered better style to
use a specific type-name instead. But... there are a few
specials that are still accomplished via "genr", namely
genr time # linear trend
genr dummy # seasonals
genr unitdum # panel unit dummies
genr timedum # panel period dummies
Allin Cottrell
3:58 p.m.
Am 16.02.2013 16:18, schrieb Allin Cottrell:
latter creates an NA series. As you know, "genr" is (sort
of)
deprecated for general use; it's considered better style to
use a specific type-name instead.
That's why I checked the use of 'series'.
genr time # linear trend
genr dummy # seasonals
genr unitdum # panel unit dummies
genr timedum # panel period dummies
So what about introducing aliases for those with 'series'? At least
'series time' would be quite natural it seems. I admit that 'series
unitdum' is less clear, however...
-sven
12:16 p.m.
On 15/02/13 13:01, Henrique Andrade wrote:
Dear Sven,
I think "genr dummy" can do what you need.
Best,
Henrique
Yes, it is as simply as that.
BTW, when you ask gretl to add "periodic dummies" in such a way the
names of the dummy variables depend on the seasonal periodicity, i.e. if
the data are quarterly the dummies are dq1,..., dq4, if the data are
monthly they are dm1,..., dm12 if the seasonal periodicity is greather
than 12 the dummies are dummy_1,..., dummy_99 and then dummy100,
dummy101, etc
At the risk of introducing another backward incompatible change, I would
suggest our dear developers that a unique name should be used for the
seasonal dummies independently on the periodicity. And I propose to use
d1, d2, ....
--
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:21 p.m.
On Fri, 15 Feb 2013, Ignacio Diaz-Emparanza wrote:
BTW, when you ask gretl to add "periodic dummies" in such a
way the names of
the dummy variables depend on the seasonal periodicity, i.e. if the data are
quarterly the dummies are dq1,..., dq4, if the data are monthly they are
dm1,..., dm12 if the seasonal periodicity is greather than 12 the dummies are
dummy_1,..., dummy_99 and then dummy100, dummy101, etc
At the risk of introducing another backward incompatible change, I would
suggest our dear developers that a unique name should be used for the
seasonal dummies independently on the periodicity. And I propose to use d1,
d2, ....
I don't have any objection to that, other than the backward
incompatibility. Any others have thoughts on the matter?
Allin Cottrell
4:01 p.m.
Am 16.02.2013 16:21, schrieb Allin Cottrell:
On Fri, 15 Feb 2013, Ignacio Diaz-Emparanza wrote:
> BTW, when you ask gretl to add "periodic dummies" in such a way the names
of
> the dummy variables depend on the seasonal periodicity, i.e. if the data are
> quarterly the dummies are dq1,..., dq4, if the data are monthly they are
> dm1,..., dm12 if the seasonal periodicity is greather than 12 the dummies are
> dummy_1,..., dummy_99 and then dummy100, dummy101, etc
>
> At the risk of introducing another backward incompatible change, I would
> suggest our dear developers that a unique name should be used for the
> seasonal dummies independently on the periodicity. And I propose to use d1,
> d2, ....
I don't have any objection to that, other than the backward
incompatibility. Any others have thoughts on the matter?
Ignacio, could you explain the advantages? Or the other way around, the
disadvantages of having different names for different periodicities?
Actually, if the seasonal dummies business were touched, I would propose
to think also about covering centered seasonal dummies, as gretl already
does in the VECM case.
thanks,
sven
11:20 a.m.
On 16/02/13 17:01, Sven Schreiber wrote:
Am 16.02.2013 16:21, schrieb Allin Cottrell:
> On Fri, 15 Feb 2013, Ignacio Diaz-Emparanza wrote:
>
>> BTW, when you ask gretl to add "periodic dummies" in such a way the
names of
>> the dummy variables depend on the seasonal periodicity, i.e. if the data are
>> quarterly the dummies are dq1,..., dq4, if the data are monthly they are
>> dm1,..., dm12 if the seasonal periodicity is greather than 12 the dummies are
>> dummy_1,..., dummy_99 and then dummy100, dummy101, etc
>>
>> At the risk of introducing another backward incompatible change, I would
>> suggest our dear developers that a unique name should be used for the
>> seasonal dummies independently on the periodicity. And I propose to use d1,
>> d2, ....
> I don't have any objection to that, other than the backward
> incompatibility. Any others have thoughts on the matter?
>
Ignacio, could you explain the advantages? Or the other way around, the
disadvantages of having different names for different periodicities?
1) It is
easier for the user to have a unique name.
2) For a user who wants to use the seasonal dummies inside a function it
is really uncomfortable not knowing beforehand what are their names, so
having to use always an ugly intermediate function like this below while
changing to a unique name may avoid it:
<hansl>
function list seasdum (void)
list deterministic = null
genr dummy
if ($pd=4)
list deterministic += dq1 dq2 dq3
elif ($pd=12)
list deterministic += dm1 dm2 dm3 dm4 dm5 dm6 dm7 dm8 dm9 dm10 dm11
else
scalar spd1=$pd-1
loop i=1..spd1 --quiet
if (i<100)
list deterministic += dummy_$i
else
list deterministic += dummy$i
endif
endloop
endif
return deterministic
end function
nulldata 100
#Quarterly data
setobs 4 1:1 --time-series
list sdum=seasdum()
list sdum --print
nulldata 100
#Monthly data
setobs 12 1:1 --time-series
list sdum=seasdum()
list sdum --print
nulldata 1000
#Hourly data
setobs 24 1:1 --time-series
list sdum=seasdum()
list sdum --print
nulldata 1000
#A rather extreme case:
#Weekly periodicity with hourly data
setobs 168 1:1 --time-series
list sdum=seasdum()
list sdum --print
</hansl>
I see now from Jack's response that the function might be made now much
simpler using
q=$obsminor
list D=dummify(q)
and if $obsminor is allowed as a parameter of 'dummify' in only one line:
list D=dummify($osbminor)
(But Jacks's example does not work for $pd=168)
Actually, if the seasonal dummies business were touched, I would
propose
to think also about covering centered seasonal dummies, as gretl already
does in the VECM case.
I also support this.
--
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.
12:14 p.m.
On Mon, 18 Feb 2013, Ignacio Diaz-Emparanza wrote:
I see now from Jack's response that the function might be made
now much
simpler using
q=$obsminor
list D=dummify(q)
and if $obsminor is allowed as a parameter of 'dummify' in only one line:
list D=dummify($osbminor)
(But Jacks's example does not work for $pd=168)
This one does:
<hansl>
nulldata 8400
setobs 168 1:1 --special-time-series
series hr = (time-1)%$pd + 1
discrete hr
list D = dummify(hr)
</hansl>
> Actually, if the seasonal dummies business were touched, I would
propose
> to think also about covering centered seasonal dummies, as gretl already
> does in the VECM case.
I also support this.
I agree it would be nice to have, but this is not difficult to achieve in
a script. To expand on the script above:
<hansl>
nulldata 8400
setobs 168 1:1 --special-time-series
series hr = (time-1)%$pd + 1
discrete hr
list D = dummify(hr)
loop foreach i D --quiet
$i -= 1/$pd
endloop
</hansl>
That said, one may conceivably add an optional parameter to the dummify()
function to have centred dummies (although we already have one, but...).
-------------------------------------------------------
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:10 p.m.
On Sat, 16 Feb 2013, Allin Cottrell wrote:
The doc could do with an update on this sort of thing. In
general "genr x" and "series x" are not equivalent: the former
provokes the error "No formula supplied in genr" while the
latter creates an NA series. As you know, "genr" is (sort of)
deprecated for general use; it's considered better style to
use a specific type-name instead. But... there are a few
specials that are still accomplished via "genr", namely
genr time # linear trend
genr dummy # seasonals
genr unitdum # panel unit dummies
genr timedum # panel period dummies
On Sat, 16 Feb 2013, Allin Cottrell wrote:
I don't have any objection to that, other than the backward
incompatibility. Any others have thoughts on the matter?
We could actually push the idea a little bit further: the following
already works in CVS:
<hansl>
nulldata 24
setobs 4 1:1
q = $obsminor
list D = dummify(q)
setobs 6 1:1 --stacked-time-series
u = $unit
t = time
list U = dummify(u)
list T = dummify(t)
</hansl>
we could deprecate the "genr" special cases Allin cited above in favour of
* the substitution of the "time" special thing with a dollar accessor
called (well, doh) $time;
* allowing dummify to take $obsminor, $unit and $time as arguments.
Now this would be a rather drastic backward-incompatibility, but would
make things more elegant (in the C source 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
-------------------------------------------------------
4347
days inactive
4350
days old
10 comments
5 participants
participants (5)
-
Allin Cottrell -
Henrique Andrade -
Ignacio Diaz-Emparanza -
Riccardo (Jack) Lucchetti -
Sven Schreiber