Re: [Gretl-users] VECM estimation
by Riccardo Jack Lucchetti
Sven, I'm cc-ing this to the developer list because I think it's the best
place for this discussion
On Wed, August 30, 2006 21:31, Sven Schreiber wrote:
>> the matrices S00 & co. are quite easy to build by combining lists, loop, genr
>> and matrix functions; all in all, you need moment matrices of residuals. On
>
> Sure, but dealing with sample lengths, lagged differences, exogenous
variables etc. is not fun and it's already implemented in a nice dialog, so
why not use it?
Well, because IMO it doesn't "feel" like a good idea to have too many
fetchable variables post-estimation. It's a balancing act here: a few things
would be simple to do in a script, but you're likely to use them a lot (think
$uhat), some other things would be more cumbersome (example: $jbeta) so we
might as well make them fetchable once estimation is over for the user's
convenience, even if you're unlikely to use them except in few special
situations. In my mind S00 & co. belong to neither group, but I'm open to be
convinced of the contrary.
>> Note that we can already do this via a LR test.
>
> Where is that documented?
Well, it seems it isn't. :-(
But basically, this is what "restrict" does after "vecm"; the corresponding
GUI element is "Test/Linear restriction" from the VECM output window.
It looks like the manual needs to be beefed up a little. Actually, a chapter
on hypothesis testing wouldn't hurt.
>
>> While I tested this, I realised that I couldn't reproduce Johansen's
results
>> with JMulTi; either I'm missing something, or JMulTi's VECM estimation goes
through a different algorithm from ours. We do VECMs as per Johansen's
book;
>> so does PcGive, and I believe there should be no differences between our
results and what PcGive yields.
>
> I have all those programs, do you want me to test/confirm something?
Please try to reproduce the Denmark example you find in Johansen's book. The
data are available as denmark.gdt among gretl example datasets. JMulTi seems
to do strange things with VECMs. I exported the denmark dataset to JMulTi
format via the new ad-hoc facility: then, I could reproduce the same results
we have in gretl for almost everything (descriptives, VARs, etc.) but VECMs
proved impossible. I understand you know the main developer of JMulTi
personally: it may be a good idea to ask his opinion if/when we're certain
that results are indeed different.
If you could do the same with MicroFit too, that'd be great.
Riccardo "Jack" Lucchetti
Dipartimento di Economia
Facoltà di Economia "G. Fuà"
Ancona
16 years, 11 months
omit command
by Riccardo Jack Lucchetti
While playing with large datasets, I found that the "omit" command wouldn't
work for a particular model: I got a "Data error" message. Some investigation
led me to discover (I didn't know before) that, in order for the omit command
to work, you need to have the same number of observations for both the
unrestricted and the restricted model. Same goes for "add".
The reason for this is that the test that gets computed by these commands
involves comparing the two models, which is ok. However, for large datasets,
this is a very serious limit: when you have many variables and thousands of
observations the likelihood of having missing values in some of the
added/omitted variables is very high.
Now, this can be bypassed via "restrict", which does a Wald-style test, but if
you want to exclude dozens of variables at the same time (think of industry
dummies, for instance), it's not the handiest of tools.
Therefore, my proposal (which probably involves some work, but not much): how
about appending a --wald option to "omit", by which we carry out the test by
the "restrict" machine instead of the default?
Riccardo "Jack" Lucchetti
Dipartimento di Economia
Facoltà di Economia "G. Fuà"
Ancona
17 years
Re: [Gretl-devel] 'seed'
by Riccardo Jack Lucchetti
On Tue, August 29, 2006 23:53, Allin Cottrell wrote:
>
> With the new setup, you can go to /Tools/Seed for random numbers
> and set, say, "3", then generate a normal series. If you
> generate another normal series without revisiting the seed
> dialog, it will differ from the first. But if you revisit the
> seed dialog, leave the value at "3" and click "OK", then
> generate another normal series, it will be identical to the
> first.
>
> Does this seem like the right behaviour?
It does to me. Ignacio?
ps. I'm sorry I didn't inform you list guys about this, but I wrote a message
to Allin yesterday on some serious performance issue with subsampling in panel
datasets. Allin, any news on this?
Riccardo "Jack" Lucchetti
Dipartimento di Economia
Facoltà di Economia "G. Fuà"
Ancona
17 years
Re: [Gretl-devel] 'seed'
by Ignacio Diaz-Emparanza
>
> set seed 3
> genr norm=normal()
> set seed 3
> genr norm2=normal()
> print norm norm2 --byobs
>
> and you get
>
> Obs norm norm2
>
> 1:01 1.232701 1.232701
> 1:02 -1.862191 -1.862191
> 1:03 1.277692 1.277692
> 1:04 0.033582 0.033582
>
Well, this was the result I expected also from the GUI dialog box, as in
the second generation, in the box for "seed" remained the "3" from the
previous one, so I thought I was setting also the seed to "3".
17 years
array indexing
by Allin Cottrell
I recently made some changes so that array indexing in the
context of the "restrict" command starts at 1 in all cases
(previously there was a mixture of 0-base and 1-base).
Working again with matrices lately, I recall that gretl matrices
also use 1-based indexation. So we're consistent.
But is this "right"? Would we be better to standardize on
0-based indexing in all cases? My initial thought was that
1-base is more intuitive for the "punters", but I have to say it
seems odd for matrices. Ox uses 0-base; does R do that too?
Allin.
17 years, 1 month
work in progress
by Allin Cottrell
I haven't done much in the way of CVS commits lately. In case
anyone's interested, here's what I've been working on (besides
classes, which started yesterday here!).
While in Scotland in mid-August, I had some conversations with a
friend who is experienced in writing compilers, and with some
pointers from him, I think I can do a substantially better job
with gretl's "genr" functionality. I believe we can make genr
more efficient, more robust, and more readily extensible, by
using employing a more systematic approach to the parsing of
user input. So at present I'm working on that genr replacement.
It won't be in 1.6.0 -- which I'd like to release as soon as all
outstanding bug reports are handled -- but I hope it will be in
1.6.1.
Allin.
17 years, 1 month
Re: Contents of file `gretl-1.6.0.pre2.it.po.gz'
by Cristian Rigamonti
On Thu, Aug 24, 2006 at 11:59:19AM -0400, Translation Project Robot wrote:
> The Translation Project robot, in the
> name of your translation coordinator.
> mailto:translation@iro.umontreal.ca
Hi, this request from the TP robot seems a bit late (the gretl.pot version it's
based upon dates back to August 2, the current gretl.pot and it.po in CVS are
newer!). Should we ignore this? Or do you need po files for this particular
release(*) ?
Cri
(*) A note for fellow translators: if your current version of xx.po does not
match the one provided by the TP robot (which can even be older, as in this
case!) you can merge your work into the TP robot file using the "msgmerge"
utility from the "gettext" package in this way:
msgmerge your_file.po the_tprobot_file.po > output.po
And then fix any possible fuzzy strings in output.po
--
GPG/PGP Key-Id 0x943A5F0E - http://www.linux.it/~cri/cri.asc
Free software, free society - http://www.fsfeurope.org
17 years, 1 month
Micro fix
by Riccardo Jack Lucchetti
This is necessary to build current CVS:
Index: lib/src/dbread.c
===================================================================
RCS file: /cvsroot/gretl/gretl/lib/src/dbread.c,v
retrieving revision 1.65
diff -u -w -r1.65 dbread.c
--- lib/src/dbread.c 22 Aug 2006 16:49:30 -0000 1.65
+++ lib/src/dbread.c 22 Aug 2006 18:12:59 -0000
@@ -20,7 +20,7 @@
/* dbread.c for gretl */
#include "libgretl.h"
-#include "../plugin/swap_bytes.h"
+#include "../../plugin/swap_bytes.h"
#define DB_DEBUG 0
By the way, is it normal that a file in the lib/src directory needs a header
from the plugin subdir? Shouldn't lib/src/ be self-sufficient (apart from
obvious cases such as cephes)?
Riccardo "Jack" Lucchetti
Dipartimento di Economia
Facoltà di Economia "G. Fuà"
Ancona
17 years, 1 month
I'm back!
by Riccardo Jack Lucchetti
Folks,
although I've been in sleep/suspend mode for a few weeks now, I managed to get
some low-intensity work done. The beginning of the story is that I've decided
to adopt as textbook for next year Marno Verbeek's outstanding book (in the
excellent Italian translation by Sergio Pastorello). See
http://www.wiley.co.uk/verbeek2ed/ for details. Following the "Data Sets" link
lets you download the data in stata and eviews format.
As a consequence, I converted all the example datasets into gretl and
reproduced nearly all the tables in the text. Attached you'll find a gzipped
tarball with all the necessary ingredients. This was also a nice way of
telling how well gretl covers the needs of the average applied economist. As
you will see by the comments interspersed in the scripts, there is little
gretl can't presently do natively, and in most cases even that can be done via
the mle command. In one case, I had to resurrect my old heckit function[1].
The one thing that gretl cannot be coerced into doing at the moment is GMM,
which is necessary for reproducing Table 5.4. However, I've written an Ox
prototype, which I'm also attaching. It's very scant on comments, but it
should be mostly self-explanatory.
IMHO it should take Allin very little to incorporate the GMM algorithm into
gretl, the only spot potentially tricky to implement being the calculation of
the Jacobian, for which Ox has a dedicated function. Obviously, it's way too
late to consider the inclusion of this into 1.6.0, but this and Arellano-Bond
(already under way, at least in the planning) could take relatively little
time to implement, and would well warrant bumping the version number to 1.6.1.
I'd say it's not unreasonable to have these two extra features in by the end
2006.
Please give the whole thing a good go. If you don't find any gross mistakes,
I'll contact Verbeek to see if he's interested in adding gretl datasets to the
Wiley website.
Have a nice day, everyone.
[1] Which could even go into the new-style function repository, no?
Riccardo "Jack" Lucchetti
Dipartimento di Economia
Facoltà di Economia "G. Fuà"
Ancona
17 years, 1 month
Some TODO items re documentation and user interface
by Cristian Rigamonti
Hi devel-list, here you are a list of TODOs I compiled while debugging the
current CVS version.
- Documenting command line options: some options defined in /lib/src/interact.c
are not documented in the "usage" function in /cli/gretlcli.c: these are the
-d, -w and -c options. What's their meaning?
- Man page: I think this needs some updating, and perhaps adding a man page for
the "gretlcli" command, documenting its own options.
- User guide:
- starting.tex: fix the section "The main window menus", accordingly with the
new menu structure
- functions.tex: fix the section about function packages, accordingly with the
new menu structure
- Documenting the "Alt-X" functionality
I think I can give a try to fix these (except maybe the last one, and with some
hints from you for what concerns the first one), if nobody is already working on
it.
Cri
--
GPG/PGP Key-Id 0x943A5F0E - http://www.linux.it/~cri/cri.asc
Free software, free society - http://www.fsfeurope.org
17 years, 1 month
