Command line & output
by Pietro Battiston
Hello everybody (I'm new to this list, though in the past I interacted
with the bug tracker),
my ideal workflow with gretl (1.9.5, Debian GNU/Linux) is
1) play with data and find out what should be done
2) finally build a nice .inp file which does everything needed
3) run it: it saves to files everything which must be included in the
final .tex
4) the .tex has "\input"s and "\includegraphics"s which include the
result of gretl running - so just compile it
I like this both because I'm sure I can reproduce everything I finally
write, and because I do not have to change numbers everywhere in the
report if my data or my way of processing them changes slightly.
Unfortunately, I have two problems at step 3):
1) what seems to me a bug:
? tabprint -f "/home/pietro/prova.tex"
Model printed to /home/pietro/model_1.tex
Notice the wrong filename. That is even more annoying because - correct
me if I'm wrong - the commandline/script interface is the only way to
save a LaTeX table _not_ as a complete document, but as something
embeddable in an existing one.
2) what is either a whishlist feature, or a proof of my blindness in
reading the manuals: if, as it seems to me, the only way of writing to a
file (apart from LaTeX output) is the command "output", then it doesn't
help me, because if I do
outfile /home/pietro/my_file --write
print result
outfile --close
then "my file" will contain:
? print result
result = 4317.0000
? outfile --close
while I would like just the number. Is there a way to just say "save
this number to this file [with this format]"? Or some script/best
practice in using placeholders and parsing gretl output to build the
final .tex file? Or should I look at py4gretl for that?
Thanks in advance for any clarification (and for the great app).
Pietro
12 years, 9 months
oxgauss
by Summers, Peter
Folks,
After reading the manual's section on gretl & Ox, it seems to me that it should be possible to take advantage of Ox's 'oxgauss' feature and run gauss programs in gretl via the Ox interface. I had a brief stab at this by putting "#include <oxgauss.h>" immediately after the "#include <oxstd.h>" line, but no go. Ox didn't recognize the gauss language.
Has anyone done this, or is it a lot more involved than my first impression?
PS
12 years, 9 months
A GUI comment
by Lee Adkins
Why is the tab for accessing the Robust options labelled HCCME? Only one of
the choices is HCCME (cross-section). Wouldn't it make more sense to label
it ROBUST since it determines the behaviour of the robust option for ts,
panel and GARCH?
Cheers,
Lee
--
Lee Adkins
Professor of Economics
lee.adkins(a)okstate.edu
learneconometrics.com
12 years, 9 months
Again make fails because of build.h
by Hélio Guilherme
Hi Allin,
I complained before, but you probably missed ;)
After a make clean and configure, make fails because build.h does not exist.
Looking to win32 make, this file only contains the date of the build. Before
I did created and edited by hand, but why is the automagic date failing
here? This is OpenSUSE 11.3 x64.
Can you please adapt Makefile, so it creates the file and adds the build
date?
Thanks,
Hélio
final lines of ouput:
libtool: compile: gcc -c -g -O2 -I.. -I../gui2 -DHAVE_CONFIG_H -I../lib/src
-pthread -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include
-I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12
-I/usr/include/libxml2 -I../plugin -I/usr/include/glib-2.0
-I/usr/lib64/glib-2.0/include -I../plugin/zipunzip -I/usr/include/glib-2.0
-I/usr/lib64/glib-2.0/include -I. excel_import.c -fPIC -DPIC -o
.libs/excel_import.o
excel_import.c:36:19: fatal error: build.h: No such file or directory
compilation terminated.
make[1]: *** [excel_import.lo] Error 1
make[1]: Leaving directory `/home/helio/gretl/plugin'
make: *** [plugin] Error 2
12 years, 9 months
info about public functions in packages
by Sven Schreiber
Hi,
currently in a function package there's no way of finding out which are
the public functions (short of executing the package). At least it seems
so to me. I think it may be helpful to show this information when
clicking on "package info".
thanks,
sven
12 years, 9 months
gretl CVS status (important!)
by Allin Cottrell
Hello all (and apologies for the cross-posting)
Most of the time gretl CVS (and snapshots) are basically "latest
stable", but every now and then CVS gets a little wild as new stuff
comes in. Well, now is one of those times. So:
* DO NOT update to CVS as of 11 July 2011 if you just want the
latest marginal fixes to a "production" version of gretl.
* DO update to the new CVS if you're willing to help test some major
internal changes. These will make the libgretl API much easier for
third parties to use, and will also facilitate various possible
future developments of gretl itself. (I don't want to expand on that
right now, because I'm not promising anything.)
The internal changes are not (at this point) designed to have any
user-visible effects. We're just looking for any regressions (in the
literal sense of going backwards) from the status quo ante.
If you decide to test, thanks! But please be aware that I'm
currently working through a large set of regression tests looking
for "predictable" breakage. So, for now, please do not file bug
reports via SourceForge, and -- for a few days -- please
hold back on bug-report messages to the gretl lists (unless you find
something really urgent).
Allin Cottrell
12 years, 9 months
two issues
by Sven Schreiber
Hi,
two questions/comments:
Why isn't it possible to specify seasonal dummies for the KPSS test?
And secondly, when applying omission restrictions to OLS the message
about the information criteria seems to be wrong -- this could be a
translation error, I will check that, but mentioning it here just in case.
thanks,
sven
12 years, 9 months
Re: [Gretl-devel] [Gretl-users] SVAR estimation
by Riccardo (Jack) Lucchetti
On Fri, 8 Jul 2011, Francisco López Herrera wrote:
> Maybe a SVAR gui design could be inspired on JMulti...Unfortunately I
> have not skills in C programming...With my best
> regards...flh(Parameswara das)
On Fri, 8 Jul 2011, Henrique Andrade wrote:
> Dear Jack, could you please take a look at the .jpg file attached? It's
> a simple proposal for the GUI implementation (more specifically a
> suggestion for the matrix of restrictions).
Thank you for your suggestion, but I'm afraid it's not as simple as that:
JMulTi is (was?) a very clever UI written in java on top of GAUSS code. As
a consequence, Markus Krätzig was able to rely on the full power of Swing
for constructing the constraint matrices, whereas gretl package writers
can only rely on a limited subset of the GTK toolbox. (And no, I DON'T
think that should change --- at least in the near future.)
As for Henrique's proposal, it's a good starting point; true, we don't
have, at present, a user-level widget for modifying a matrix, but I guess
Allin could see to it (I couldn't: I simply can't do any GTK-related
coding, I'm hopeless at it).
But then, the problem is: do we really want the user to input the
constraint matrices (in implicit or explicit form)? These could be HUGE;
in an n-variate C-model, a constraint matrix in implicit form has n^2+1
columns and at least n*(n-1)/2 rows. If you had a system with 7 variables
(not unusual), would you really want to fill up a matrix with 50 columns
and 21 rows by hand? Or you could have the option of filling up the
restricted elements (the 0s and 1s), but then, what do you put in place of
an UNrestricted element? We may agree on some conventional value, like for
instance -999, but I doubt that would be considered particularly
intuitive. Moreover, in the case of a C-model we'd need to separate
somehow long-run from short-run restrictions which, again, I wouldn't know
how to do in a simple and clean way.
Perhaps the best candidate is a text box à la Eviews, in which you write
the restrictions in a hansl-like syntax. That would complicate the code
quite a bit, but I like the challenge. The only missing bit would be tyhe
possibility of having a resizable text box in our GUI interface to user
functions. Allin?
PS: I'm cc-ing the developer list, since this is getting a bit technical
IMO.
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
12 years, 9 months
two slightly confusing things in the manual and one suggestion
by Sven Schreiber
Hi,
to prove that at least some (n>=1) people do read the manual here are
some things I noticed today:
1) I once was taught on this list that "loop for i=1..x" is just a
tolerated syntax error, not the correct form (which is "loop i=1..x").
However, I noticed today that this idiom is used in the manual, so I
suggest to correct that. (This is something I probably could even do
myself in cvs.)
2) similarly, the "secret" short form "-q" for "--quiet" is also used in
the manual and probably never explained
3) and a suggestion: in a foreach loop many variables which are
contiguous in the dataset can be referred to like this:
loop foreach i var1..var99
This is explained in the manual, otherwise I wouldn't know it. When I
was dealing with 51 weekly dummies today I thought that it would be very
useful to have this syntax also for definition of lists, or maybe even
directly in estimation commands.
Example:
# shortest form (suggestion)
ols myvar const dummy_1..dummy_51
# slightly longer, with new list definition
list weekdummies = dummy_1..dummy_51
ols myvar const weekdummies
# best possible thing today (AFAIK):
list weekdummies = null
loop foreach i dummy_1..dummy_51
list weekdummies += $i
endloop
ols myvar const weekdummies
Or is there some existing trick that I'm not aware of?
thanks,
sven
12 years, 9 months
