On Wed, 15 Dec 2010, Henrique Andrade wrote:
> I think we have an untranslated string in the heteroskedasticity tests
> (inside the OLS estimated model window). The "Chi-Square" should be shown as
Thanks, that should now be fixed in CVS.
I think we have an untranslated string in the heteroskedasticity tests
(inside the OLS estimated model window). The "Chi-Square" should be shown as
Teste de White para a heteroscedasticidade -
Hipótese nula: sem heteroscedasticidade
Estatística de teste: LM = 16,8589
com p-valor = P(*Chi-Square*(5) > 16,8589) = 0,00477541
Henrique C. de Andrade
Doutorando em Economia Aplicada
Universidade Federal do Rio Grande do Sul
I am wondering wether it is possible to estimate forcast error in Gretl in simple terms. Let's fx. say I have a time series on monthy basis and the forecast model is simply some version of lagged values of this same time series (ARIMA,AR etc.). now I want to estimate historical forecast error for one, two, ..., n months in the future or get some data table where one, two, ..., n months forecasts can be compared to real historical values. Is this possible?
Kveðja / With regards
Sérfræðingur / Analyst
Áhættustýring / Risk Management
Sími / Tel.: (+354) 410 6993
Farsími / Mobile: (+354) 820 2646
Fax: (+354) 410 3010
Landsbankinn (NBI hf.), kt. 471008-0280, Austurstræti 11, 155 Reykjavík, er skráð hlutafélag og starfar samkvæmt heimild og undir eftirliti Fjármálaeftirlitsins.
Landsbankinn (NBI hf.), Austurstræti 11, 155 Reykjavík. is incorporated in Iceland with limited liability (Reg. No: 471008-0280) and is authorised and regulated by the Financial Supervisory Authority in Iceland (Fjármálaeftirlitið).
I've recently been working on a gretl function to implement the
panel unit-root test of Breuer, McNown and Wallace (Oxford
Bulletin of Economics and Statistics, 2002), which takes into
account cross-equation correlations while allowing for
the testing of the unit-root null on a per-group basis.
In that context I realized that -- unless I'm missing something --
we didn't have a means of constructing a "system" spec on the fly
(when the number and make-up of the equations is not known until
run-time). Possibly one could do domething cunning but ugly with
strings, but I couldn't see any other way.
So in CVS I've implemented a generalization of the system spec.
I'm not sure that my approach is the best one: it has the virtue
of causing the least disruption to existing gretl types and
command structures, but has some limitations. So I'd like to
Here's the deal: Up till now the only thing accepted by way of
specification of the equations in a "system" block has been a set
of "equation" statements, but now you can say
Note the plural in "equations". The parameter should be the name
of a pre-defined matrix, each row of which represents a list
(left-hand side variable, regressors). If some lists are longer
than others, the matrix should have g columns where g is the
length of the longest list, and shorter lists should be padded
with trailing zeros.
It works, but has a couple of limitations:
(1) Since trailing zeros are ignored, you can't place the constant
at the end of an equation list. This shouldn't be a real problem,
since you are better placing the constant first; it will be
shuffled into first place by gretl anyway.
(2) You can't insert the equivalent of ";" into a matrix, and so
you cannot specify an equation's list "tsls-style". This is a
problem only (a) if you are using instruments and (b) you want to
use specific instruments in specific equations rather than using a
common set of instruments for all equations.
Here's a simple example (it's not complete, and presumes some
"stage-setting", but might convey the idea):
scalar g = <whatever>
scalar listmax = <whatever>
matrix surmat = zeros(g, listmax)
# build g lists and insert into matrix surmat
p = laglengths[i]
list eqlist = xd$i const x$i(-1) xd$i(-1 to p)
matrix surrow = eqlist
k = nelem(eqlist)
if (k < listmax)
# this equation is "short"
surrow ~= zeros(listmax - k)
surmat[i,] = surrow
since October (I think) I noticed that messages aren't properly being
sorted within the threads. Something like: The first reply in a newly
started thread is not recognized as belonging to that thread.
I don't really have a clue what's going on. It seems probable that it
has something to do with the Ubuntu upgrade and new Thunderbird version
(3.1.x from Ubuntu 10.10).
anybody else seeing this?