Re: [Gretl-users] Question on compacting data from daily to monthly
by Allin Cottrell
On Sun, 24 Oct 2010, Allin Cottrell wrote:
> On Sun, 24 Oct 2010, Sergei B wrote:
>
> > I'm a new user to GRETL and maybe the question I'm going to ask
> > is somehow obvious, but I was unable to find the answer so far
> > (searched also through the archive of this mailing list).
>
> No, your question is not that obvious, and in fact you seem to
> have exposed a bug.
The bug is now fixed in CVS and the snapshots for Windows and OS
X. (When compacting data using the average or sum of the high
frequency values, the compacted value was given as 0 instead of NA
in the case where all the high frequency values in the relevant
range were NA: now the compacted value is NA.)
Allin Cottrell
14 years, 2 months
Re: [Gretl-users] Question on compacting data from daily to monthly
by Allin Cottrell
On Sun, 24 Oct 2010, Sergei B wrote:
> I'm a new user to GRETL and maybe the question I'm going to ask
> is somehow obvious, but I was unable to find the answer so far
> (searched also through the archive of this mailing list).
No, your question is not that obvious, and in fact you seem to
have exposed a bug.
> I have a set of daily stock prices for a certain period
> (1970-2007). Some daily data is missing and the missing
> observations are marked as NA. What I would like to do is to
> compact the data from daily to monthly by summing the log
> returns of daily data. When I try to do that, months, for which
> daily data wasn't available, get 0 instead of NA. Is there a way
> to avoid this from happening?
If all the daily values for a given month are NA, then clearly the
monthly summation should also be NA. This bug will be fixed
shortly. In the meantime there are various work-arounds.
One possibility is to use gretl's zeromiss() function, which turns
zeros into missing values, on the compacted series:
x = zeromiss(x)
But obviously you'd want to do that only if you're confident that
a monthly value of 0 is never a valid value. An alternative is to
convert the NAs in the original daily data into some clearly
out-of-bounds value, on the basis of which you can then correct
the monthly series. Here is a complete script that illustrates
what I'm talking about:
# construct an artificial 3-month daily series
nulldata 91
setobs 7 2010/09/01 # 7-day daily data
series x = normal()
# simulate your situation by making all the
# October values into NAs
series oct = (t > 30 && t < 62)
x = oct ? NA : x
# now make the NAs into (for example) -9999
x = ok(x)? x : -9999
# compact the data to monthly by summation
dataset compact 12 sum
# finally, convert "big negative numbers" to NA
x = (x < -9000)? NA : x
# and inspect the results
print -o
If some months contain just a few NAs at the daily level while
others contain nothing but NAs, then you'd have to modify the
above approach slightly, but hopefully you get the general idea.
Allin Cottrell
14 years, 2 months
Question on compacting data from daily to monthly
by Sergei B
Dear all,
I'm a new user to GRETL and maybe the question I'm going to ask is somehow
obvious, but
I was unable to find the answer so far (searched also through the archive of
this mailing list).
I have a set of daily stock prices for a certain period (1970-2007). Some
daily data is missing and the missing observations are marked as NA. What I
would like to do is to compact the data from daily to monthly by summing the
log returns of daily data. When I try to do that, months, for which daily
data wasn't available, get 0 instead of NA. Is there a way to avoid this
from happening?
Thanks in advance.
--
---------------------------------------
Sergey
14 years, 2 months
Re: [Gretl-users] minor bug
by Allin Cottrell
On Thu, 21 Oct 2010, Allin Cottrell wrote:
> On Thu, 21 Oct 2010, Summers, Peter wrote:
>
> > I've just re-ordered some data series using "edit attributes."
> > Things work as expected using the arrows next to the "ID number"
> > box, but not the green "move up/move down" arrows.
>
> The green up/down arrows are not supposed to change a series' ID
> number, they move you through the list of series. Using the green
> check mark button and up/down arrows is supposed to be an
> alternative to using the OK button, then opening the dialog again
> for the next series you want to work on.
I've tried to make this intent a little clearer in current CVS, by
moving the green arrows so they're not right next to the series ID
selector and changing their "tooltip" text.
Allin
14 years, 2 months
randgen
by mayuda＠unizar.es
Hi, I have tried to use in the gretl console the function RANDGEN
UNIFORM or NORMAL and the Gretl turn off always in different
computers with different versions os Windows. Some help will be good.
14 years, 2 months
VAR lag selection
by Talha Yalta
I am not sure if this question makes sense but is it normal that AIC,
BIC and HQC values change when a different "maximum lag" selected in
VAR lag selection. I mean, if these statistics change based on the
initial choice of the maximum lags to be tested, then we also need a
test for the maximum number of lags to be tested, no?
Here is an example of the potential inconsistency:
VAR system, maximum lag order 4
The asterisks below indicate the best (that is, minimized) values
of the respective information criteria, AIC = Akaike criterion,
BIC = Schwarz Bayesian criterion and HQC = Hannan-Quinn criterion.
lags loglik p(LR) AIC BIC HQC
1 145.63131 -10.924461 -9.937075 -10.676137
2 159.38080 0.03626 -10.728765 -8.951470 -10.281780
3 182.94995 0.00006 -11.386952 -8.819748 -10.741307
4 224.97540 0.00000 -13.650034* -10.292921* -12.805730*
VAR system, maximum lag order 3
The asterisks below indicate the best (that is, minimized) values
of the respective information criteria, AIC = Akaike criterion,
BIC = Schwarz Bayesian criterion and HQC = Hannan-Quinn criterion.
lags loglik p(LR) AIC BIC HQC
1 149.21357 -10.767797 -9.786086* -10.507349*
2 163.67384 0.02448 -10.639487 -8.872406 -10.170680
3 184.17688 0.00055 -11.014740* -8.462290 -10.337574
Cheers
Talha
--
“An expert is a person who has made all the mistakes that can be made
in a very narrow field.” - Niels Bohr (1885-1962)
--
14 years, 2 months
Re: [Gretl-users] minor bug
by Allin Cottrell
On Thu, 21 Oct 2010, Summers, Peter wrote:
> I've just re-ordered some data series using "edit attributes."
> Things work as expected using the arrows next to the "ID number"
> box, but not the green "move up/move down" arrows.
The green up/down arrows are not supposed to change a series' ID
number, they move you through the list of series. Using the green
check mark button and up/down arrows is supposed to be an
alternative to using the OK button, then opening the dialog again
for the next series you want to work on.
Allin Cottrell
14 years, 2 months
minor bug
by Summers, Peter
Hi everyone,
I've just re-ordered some data series using "edit attributes." Things work as expected using the arrows next to the "ID number" box, but not the green "move up/move down" arrows. If I use those to change the position of a series, then click OK, nothing happens. The "apply" check mark isn't enabled either (it is if I use the "scroll wheel").
PS
===============================
Dr. Peter Summers
Assistant Professor
Department of Economics
Texas Tech University
===============================
14 years, 2 months
Re: [Gretl-users] Out-of-sample forecasting with cross section data
by Allin Cottrell
On Mon, 18 Oct 2010, Mikael Postila wrote:
> Sorry to ask a "simple and stupid" question on the list, but couldn't find
> an answer from any Manual or Command reference (nor Gretl-wiki search).
>
> Is there a simple way to perform out-of-sample forecast for a cross section
> data?
Set the sample to some subset of the available data (using the
"smpl" command or the GUI) and estimate the model you want. Then
reset the sample to a bigger range and use the "fcast" command or
the GUI to generate a forecast.
Example script:
open data4-1
smpl 1 10
ols 1 0 2
smpl full
fcast
Allin Cottrell
14 years, 2 months
Re: [Gretl-users] VAR Forecast
by Allin Cottrell
On Mon, 18 Oct 2010, Henrique Andrade wrote:
> Let me see if I understood correctly:
>
> (1) With no flags Gretl gives me "static" forecasts inside the sample and
> dynamic ones outside the sample.
> fcast 1972:1 1991:4
>
> (2) With the option "--dynamic" Gretl uses the *estimated* values to make
> the forecast of the period t+1.
> fcast 1972:1 1991:4 --dynamic
>
> (3) With the option "--static" Gretl uses the *observed* values to make
> forecast of the period t+1.
> fcast 1972:1 1991:1 --static
>
> (4) With the option "--out-of-sample" Gretl gives me dynamic forecasts (i.e.
> using estimated values) outside my sample.
>
> Is this the correct interpretation?
Yes, that's right.
Allin Cottrell
14 years, 2 months
