Re: Re: [Gretl-devel] backward incompatibilities
by andreas.rosenblad＠ltv.se
svetosch(a)gmx.net @ INTERNET skrev 2008-08-22 12:34:52 :
> Am 21.08.2008 16:46, Riccardo (Jack) Lucchetti schrieb:
>
> I just updated
> > the entry for "arch" so that it now reflects your thoughts and mine.
> > > On the wiki page you clarify what gretl's arch does exactly, which I
> didn't know. So if I understand correctly, the difference between 'arch'
> and 'garch' without the "generalized" (MA) terms is not just a slightly
> different numerical algorithm, but really a different estimator. And the
> arch estimator is not the "usual" ML. In that case I guess I would agree
> to remove arch. Or is the approach that is used for 'arch' widespread
> elsewhere?
>
> Re the Engle-Granger test and Allin's question: AFAIK and kind of
> trivially, the Johansen test is asymptotically optimal if all
> assumptions about the DGP are met. This should include Gaussian
> innovations. But the Johansen test is known to have severe small-sample
> distortions. For this and other reasons I think it is perfectly
> reasonable to have a variety of cointegration tests. Instead of ditching
> Engle-Granger I think the goal should actually be to have more tests
> available (but of course this should primarily be done through
> user-contributed function packages).
I agree that no test or function should be removed, and that the goal
should be to have more tests.
Best regards
Andreas
17 years, 2 months
backward incompatibilities
by Riccardo (Jack) Lucchetti
Hi all,
Lately, there's been some discussion on syntax changes that would lead to
backward incompatibility. I am sure we all agree with Sven's position
that, if compatibility has to be broken, it must be done once. Hence, in
my opinion we need to put out each idea anyone may have on modifications
to current commands and functions. In order to gather all the ideas in one
place, I created a page on our hitherto deserted wiki for collecting proposals:
http://gretlwiki.econ.univpm.it/wiki/index.php/Backward-incompatible_chan...
Everyone's invited to read, comment, modify, add (you need to register
first).
The plan is, roughly, to put out 1.7.7 shortly to close a few bugs that
have surfaced recently and then proceed to a backward-incompatible release
(2.0?).
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
17 years, 2 months
Regarding the gretl wiki
by andreas.rosenblad＠ltv.se
Regarding the hitherto deserted wiki: I think that a link to it should be
added at gretl's home page, at the left column on the fron page.
BTW, who has writing privilegies (can change) to gretl's home page?
Best regards
Andreas
r.lucchetti(a)univpm.it @ INTERNET skrev 2008-08-21 11:25:00 :
> Hi all,
>
> Lately, there's been some discussion on syntax changes that would lead to
> backward incompatibility. I am sure we all agree with Sven's position
> that, if compatibility has to be broken, it must be done once. Hence, in
> my opinion we need to put out each idea anyone may have on modifications
> to current commands and functions. In order to gather all the ideas in
one
> place, I created a page on our hitherto deserted wiki for
collectingproposals:
>
> http://gretlwiki.econ.univpm.it/wiki/index.php/Backward-
> incompatible_changes:_proposals
>
> Everyone's invited to read, comment, modify, add (you need to register
> first).
>
> The plan is, roughly, to put out 1.7.7 shortly to close a few bugs that
> have surfaced recently and then proceed to a backward-incompatible
release
> (2.0?).
>
> Riccardo (Jack) Lucchetti
> Dipartimento di Economia
> Università Politecnica delle Marche
>
> r.lucchetti(a)univpm.it
> http://www.econ.univpm.it/lucchetti
> _______________________________________________
> Gretl-devel mailing list
> Gretl-devel(a)lists.wfu.edu
> http://lists.wfu.edu/mailman/listinfo/gretl-devel
17 years, 2 months
Installing gretl on Mandriva
by Gordon Hughes
I have been experimenting with Mandriva and attempted to install
gretl. The version in the repository is 1.6.5, so I started from the
source. This turned out to be quite frustrating because the standard
Mandriva installation omits almost everything necessary for standard
development - it does not even include the make program! So, for
anyone wanting to do this, you will have to install a large number of
development libraries.
However, the reason for this message is that there appears to be a
bug in the linking of the lreadline library (required for the
readline cli). The bug is that lreadline is unable to locate
external references in the ncurses libraries (which must also be
installed). According to my investigations the problem is known; it
is said to have persisted through several releases of Mandriva and
may affect other Mandriva-derived distributions. It can be remedied
by explicit reference to the lcurses library in the configuration
script file. Since this appears to be harmless under other systems,
you might consider making the change in this file.
The following line appears once or twice:
LIBS="-lreadline $termcap_lib $LIBS"
where $termcap_lib takes the value "-lncurses" if ncurses is
installed. I edited the line as follows:
LIBS="-lreadline -lcurses $termcap_lib $LIBS"
and this appears to get round the bug in Mandriva's linking of
lreadline. I had ensured that lcurses is installed on my system, so
it may be best to test for lcurses and include the library via a
variable similar to $termcap_lib.
Gordon
17 years, 2 months
some small gretl bugs
by Sven Schreiber
Hello,
apart from what I reported during the last days I also discovered the
following new (?) gretl issues (1.7.6 on winxp):
1) gnuplot: clicking on the scatterplot window for the pop-up menu
doesn't work very often (I mean the clicking works :-) but the menu
doesn't appear). I haven't been able to make out a pattern when it works
and when it doesn't.
2) gnuplot: when changing legend location in the gretl edit window and
then clicking 'apply', datapoints are shuffled around "randomly"
3) keyboard shortcuts for menu entries (not menu titles) don't seem to
work; with alt+letter I can enter the menu, but then I can only use the
cursor keys to move around within the menu, not using another alt+letter
combination.
Thanks,
Sven
p.s.: and thanks a lot for the effort related to the 1.7.6 release!
17 years, 2 months
Re: Problem with dummify
by Gordon Hughes
>> Surely, you mean
>>
>> list dlist = dummify(x, max(c))
> max(x)? That wouldn't work for a list argument, would it?
> We could insist that dummify takes a series argument, not a list.
> That would be backward-incompatible but probably wouldn't disturb
> anyone.
Of course, you are correct. I have a blind spot about max(series),
etc because I automatically think of max(list), because that is the
way Stata and other programs work. It is somewhat confusing to
combine the two distinct usages in a single function, but I will get
used to it.
But, with respect to Allin's point, I think that insisting that
dummify should take a series argument isn't a bad idea, since it
seems to me that creating multiple sets of dummy variables at one go
can easily create confusion for the unwary user.
Gordon
17 years, 2 months
Re: Problem with dummify
by Gordon Hughes
>> Would it be possible to extend the specification of the function? The
>> syntax that I have in mind is:
>>
>> dummify(x,n) where (a) n=0 means no categories are dropped, (b) n=1 means
>> that the first category is dropped (default), and (c) n=2 means that the
>> last category is dropped.
>
> Better still: dummify(x,n) drops the n-th category. When n=NA, no
categories
> are dropped.
>
> I had started coding this, then I thought "Hold on a second, this is
> going to be another backward-incompatible change". Another one (arma) is
> in the planning stage, and obviously it'd be best to put them together
> (plus more that may arise). The question is when.
My suggestion that dummify(x) should be a synonym for dummify(x, 1)
was intended as a way of avoiding a backward-incompatible change. I
assume that under your scheme dummify(x) would translate to
dummify(x, n) with n=NA, which would be backward-incompatible.
I acknowledge that your syntax is more general and has
advantages. My proposal reflected a desire to use the dummify inside
functions when it is a little tedious, though not difficult, to work
out the maximum value that can be dropped. However, this can be got round by
matrix xvals=values(x)
scalar mxval=maxc(xvals)
list dlist=dummify(x, mxval)
so I would be happy with your suggestion.
Gordon
17 years, 2 months
More on smpl and setobs in functions
by Gordon Hughes
Sorry for the lengthy series of comments/questions, but writing and
testing moderately complicated functions really highlights the
interaction of various commands.
In this particular case, the issue is generated by the following script
function panel_foo(series y, list X)
series lunit=$unit
genr time
genr ltime=time
setobs 1 1 --cross-section
# Define sample to exclude missing values for either y or X
list vars = y X
smpl ok(vars) --restrict
...
smpl full
setobs lunit ltime --panel-vars
return matrix result
end function
This seemed to work fine, until I tried the following test
smpl id < 10 --restrict
matrix res=panel_foo(y, X)
at which point the function fell over at the final setobs, reporting
missing values for the panel variables.
Now I understand what has happened. The "smpl full" command in the
function has overridden the restricted sample that was given to the
function and reverted to the full sample of data that gretl has been
given. As a result, lunit and ltime, which were created within the
function, have missing values for observations that were not given to
the sample. I can get round this in part by defining lunit & ltime
as arguments of the function and changing the calling script, but the
sample restriction would still be overridden.
It seems to me that the operation of "smpl full" is contrary to the
principle that all operations within a function are - or should be -
local. In other words, issuing the "smpl full" command within a
function should do no more than revert to the data that was supplied
to the function.
Gordon
17 years, 2 months
Re: Problem with dummify
by Gordon Hughes
> OK, I accept that this may be a bit confusing, and should be
> clarified, but if you distinguish between (a) the dummify command
> and (b) the dummify function, I believe you'll find that each one
> does what the (respective) documentation says.
Point taken - I had simply assumed that "dummify x" and "dummify(x)"
did the same thing and that they were provided for use in different
circumstances. In particular, it is much easier to use dummify(x) in
a function because it creates a list automatically without needing to
know anything about the number of categories or variable name.
Would it be possible to extend the specification of the
function? The syntax that I have in mind is:
dummify(x,n) where (a) n=0 means no categories are dropped, (b) n=1
means that the first category is dropped (default), and (c) n=2 means
that the last category is dropped.
Then, dummify(x) would be a synonym for dummify(x,1).
Irrespective of whether the command "dummify x" or the function
"dummify(x)" is used, the operation still results in the creation of
dummies for all panel units rather than just those present in x.
Gordon
17 years, 2 months
Problem with dummify
by Gordon Hughes
I have been experimenting with the use of dummify in a function to
provide the equivalent of pmean for an unbalanced panel. The
documentation says that the command
list plist = dummify(punit)
should create dummy variables for all values of punit - in my test,
punit takes values 1 to 9. In fact, it creates dummies for values 2
to 9 only. Further, it fails to recognise the options --drop-first
or --drop-last.
Gordon
17 years, 3 months
