What do you think about implentation of some (basic at first) Bayesian econometric methods in Gretl (for example estimation of linear regression models with natural conjugate priors, Gibbs sampling, ect.)?
Dear gretl developers,
Here is a short (well, maybe not that short) wish list of improvements for
gretl that I hope can be implemented:
1. For the genr command, add a function for computing the factorial, i.e.
2. For Tools > Statistical tables: Add tabs for
(a) Poisson distribution
(b) binomial distribution
3. In Tools > Test statistic calculator: Add
(a) the possibility for using continuity correction for the one sample
proportion test by checking a check box
(b) a new tab for calculating a Z-test for comparing two counts (assuming
that the counts are large enough for the normal approximation to the
Poisson to apply)
(c) a new tab for calculating ANOVA for comparison of K means
4. In Tools > Nonparametric tests: Add new tabs for calculating
(a) Friedman’s test (the K sample extension of the sign test)
(b) Kruskal-Wallis test (the K sample extension of the Wilcoxon rank sum
5. For Tools > Probability distributions: Add
(a) a tab for the gamma distribution
(b) the possibility to choose the mean and standard deviation of the normal
6. In View > Correlation matrix add a check box for also calculating a
7. For View > Principal components: Add the possibility to plot scree plots
by checking a check box
8. For View > Cross tabulation, please
(a) add that Fisher's exact test is given as default for 2x2 contingency
(b) add to the GUI radio buttons for the options --row (display row
percentages) or --column (display column percentages), and a check box for
the option --zeros (display zero entries)
(c) add an option to save the contingency table (without the marginal
totals) as a matrix
9. For Add > Random variables
(a) Change the GUI to look like the one in Tools > P-value finder, i.e.
with tabs for the different distributions and text entry boxes for mean,
standard deviation, degrees of freedom, etc
(b) add the gamma distribution
10. In File > Export data, add options to export in
(a) Gnumeric file format
(b) LaTeX format
11. Add an option to save a matrix in LaTeX format
12. In the data window, there are currently three columns: “ID #”,
“Variable name” and “Descriptive label”. A new column showing if the
variable is to be treated as discrete or not would be useful.
I hope you will consider implementing these features
I know it's improper to skip observations (and likely mucks about the
result) but I'm dealing with hourly data so the effect isn't that great. I'm
missing about 21 observations in a data set of nearly 3000 and none of them
are together. Is there any way to get the arch command to just skip the
observations and continue on with the regression?
I have a script that I want to run and put the output in the same directory
as the script but the directory that the script is in can change. Is there a
way to tell gretl to put the output in the same dir as the script?
As a newcomer, I apologise if this e-mail raises an issue that has
been settled in the past. My query or suggestion concerns the
possibility of providing a statically linked version of gretl for
Linux. [The Windows & Mac versions are necessarily statically linked
because it cannot be assumed that users have the necessary
dlls.] The query is prompted by two considerations.
A. Over a period of several months I have been experimenting with
different Linux desktop distributions in an attempt to find a
satisfactory way of avoiding Windows Vista. Whenever I attempt to
install gretl on a new distribution, it is necessary to look around
for rpm or deb files that resolve gretl's dependencies - particularly
versions of BLAS, LAPACK, GNU C & Fortran libraries. In some cases
(eg Xandros & Centos) that is only possible by going back to quite
outdated versions of gretl (1.5 or earlier) because the OS packagers
are deliberately using "oldstable" or "stable" versions of master
distributions (especially Debian). Even popular distributions such
as Ubuntu and SimplyMEPIS have libraries that are not compatible with
the most recent versions of gretl - at least not without going to
considerable effort. For a rapidly evolving program it is somewhat
unsatisfactory to have to rely upon a version that is quite old.
B. Just yesterday, I encountered a different version of the same
problem. I have decided to use Suse Linux for my main systems - in
particular Novell's Suse Linux Enterprise Desktop (SLED) which is
generally compatible with OpenSuse 10.1 & 10.2. I tried to install
gretl 1.6.5 and failed because it could not resolve the dependency
for libpng12.so.0 (a PNG graphics library). So I tried version 1.6.2
instead and there were no problems. Given the recent history of
gretl releases I assume that the change was made in version 1.6.3 but
it illustrates the problem of resolving an ever changing set of
dependencies as the program is extended.
I notice that most providers of commercial or quasi-commercial
software - eg Stata, spreadsheets - provide statically linked
versions of their packages or a choice. The main reason for avoiding
static linking is that it increases the size of the package, perhaps
a lot. But the difference between the sizes of the gretl executables
for Windows and Linux is not that large and few users have
significantly concerns about storage capacity. In principle, a
statically linked version should execute more quickly, but I
understand that the difference is rarely noticeable. Still, on
grounds of convenience and extending the reach of gretl I think that
it would be desirable to offer a statically linked version if the
burden of doing so is not too large.
I have no knowledge of whether the main user community for gretl
relies upon Windows. There is also a matter of philosophy - most
desktop versions of Linux give high priority to stability and
security rather than having the most recent versions of software. On
the other hand, I think that desktop Linux is a genuine competitor to
Windows Vista (because most versions run on much lower specification
hardware), especially in universities, government organisations and
developing countries. Offering gretl for Linux in a version that
causes the minimum of hassle of installation would play to the
advantage of low cost and minimum hardware requirements.
The problems that I have encountered with blas/lapack are due to
unresolved symbols as you describe. They are not consistent across
versions: version 3.0-039 of lapack generates this error but not
version 3.0-020. I can't install more recent versions of blas/lapack
- eg version 3.1-xxx - because this requires more recent versions of
the C and Fortran libraries which are not compatible with current
versions of OpenSuse, SLED, Mepis, Xandros and older versions of
Ubuntu (I haven't tried this yet in 7.04). Relying upon an old
version of lapack is a nuisance because my systems keep on trying to
update it (I can't get the "keep" command to work properly).
I have only tried gretl fully on Ubuntu 6.06, which caused the
problems that I described. But note that 6.06 is an LTS (long term
support) version so that cautious users would be inclined to stick
with it for reasons of stability.
With respect to libpng I was trying to install gretl 1.6.5 from the
website rpm in different Suse systems. I don't like recompiling
programs unless it is absolutely necessary. The repositories were
unable to resolve the dependencies for libpng and I could not do it
manually because the trail became too difficult.
Distributing a version of gretl including troublesome libraries
(along the lines of the Windows and Mac versions) would be fine for
most people provided that the order in which libraries are searched
can be controlled - I am not sufficiently familiar with the way in
which Linux does this to be sure since my programming was all done on
much older systems.
Note that when saving a matrix to .txt with gretl, it seems the only
"problematic" part of the file is the header line like "mymatrix (2x2)".
Otherwise it's an almost perfect csv file. So as a workaround you could
comment out or delete the header.
I deleted the .txt file header file but nothing good happened ! On the other hand, I transformed the .txt file into a .csv file and it worked fine.
But what do you really want to do? If your matrices really represent
data series / variables, I think you can convert them to series via a
console command (check the user guide) and then normally save them as
series to a .gdt file.
The problem is with matrix whose rows' number exceeds the number of observation in the data file. You can't save the rows as series.
I have a 10-observation file and a 150-step loop for bootstrapping. Of course, I can use the "--progressive" flag for saving results in a .gdt file but what if one wants to store the coefficients in a 150-row matrix intoo a .gdt file? :-)
Stockage illimité de vos mails avec Yahoo! Mail. Changez aujourd'hui de mail !
I encountered two small issues (in a relatively recent win snapshot):
I can't plot a time trend, got an error "no suitable data found". (I
wanted to show students that it's linear...)
And apparently deleting variables currently does not affect any named
lists to which the variables belonged, leading to errors later on that
are hard to diagnose. I'm not sure what's the correct thing to do here;
maybe issue a warning at deletion-time if the variable is a list member
("deleting variable foo will invalidate lists bar, baz")? In any case I
think it really should be possible to get a list of all existing lists
and remove a list from the session. (Or is it already possible and like
always I should read the manual first?)
andreas.karlsson(a)ltv.se @ INTERNET skrev 2007-05-28 12:34:14 :
> my_gretl(a)yahoo.fr @ INTERNET skrev 2007-05-28 11:46:18 :
> > Bulent Miran a écrit : Would it be possible to
> > get p values in logit/probit outputs?
> > I'm afraid not. As long as I'm aware, Gretl has not an internal
> > variable grasping the p-value of estimators. But you can always
> > compute it yourself.
> > For example, after executing "logit" or "probit" command you can
> > add the following code :
> > genr p_val = pvalue(t, $df, $coeff(X)/$stderr(X))
> > and you'll get what you need
> > Artur
> I the p-values can be included as default in logit/probit outputs.
I _hope that it can be implemented that_ the p-values are included as
default in logit/probit outputs.
cottrell(a)wfu.edu @ INTERNET skrev 2007-05-28 15:24:45 :
> On Mon, 28 May 2007, andreas.karlsson(a)ltv.se wrote:
> > I _hope that it can be implemented that_ the p-values are included as
> > default in logit/probit outputs.
> They are not included by default because the slopes at the mean
> (which are currently shown in place of p-values) are not so trivial
> to compute while p-values can easily be generated by the user (and
> there is not enough space to show both).
> However, I've now added an option, --p-values or -p, for logit and
> probit. If you include this option, p-values are shown instead of the
Thanks a lot.