Hi listers, greetings from Paris !
I am in big trouble with matrix functions under GRETL 1.7.0 under XP.
The problem is the following:
I run system estimation (SUR) on microdata (10 305 households). Then i
use the results (coefficients and fitted values) to compute elasticities
for each household.
however, gretl does not compute them.
here is some code :
matrix vecun = ones(10305,1)
matrix erlog = vecun + (coeffaids[4,1]).*(1/what[,1])
matrix ercar = vecun + (coeffaids[4,2]).*(1/what[,2])
matrix erij = erlog~ercar
but gretl says :
? matrix erlog = vecun + (coeffaids[4,1]).*(1/what[,1])
Data type non conformant for the operation
normally vecun is a column vector of ones (10305,1) ; coeffaids[4,1] is
a scalar (so is promoted to matrix for this step) and 1/what[,1] is the
inverse of the fitted shares for good one, again a column vector
(10305,1). But gretl does not like it much !
This is puzzeling because, in another script, with *exactly the same
data and the same code*, the computations run ok .
Note that i checked the sizes of the other matrices :
I just redo the computation on the main script and it runs ok !
any advice ? I am a bit lost !
I'm trying to do some tests with the Unit Root
"Coefficients" (don't know the translation), but I don't know how to acces
them with code, does anyone here knows how to acces them with code, I mean
the Root, the Imaginary, modulus and frecuency?
Marcos Larios Santa Rosa
is it possible (in a script) to access the test results from Hausman and
Sargan tests after TSLS estimation? Since they are automatically
calculated and not after a special test command, it seems that the
normal gretl ways ($pvalue and such) don't apply.
If not, I would file a feature request, because the general gretl
principle seems to be that all tests should be accessible.
I have been using Gretl for some time now, and in a previous version I
was able to save a text file (and enclosed data) as a gdt file, and
later look at the file through something like Notepad and see how it
looked like an xml file.
I am currently using Gretl 1.6.5, and now any text data files I convert
to gdt looks like gobbledy gook.
What happened? Is this its normal behaviour, or does the fact that I am
using Windows 98 have something to to with this?
Regards Peter Robertson
I tried to create a new variable by ADD -> LAGS OF
SELECTED VARIABLES with the intention of doing a scatter
plot of the dependent variable with its t-1 lag. However,
the new variable is what appears to be a subcategory of
the dependent variable and I can't figure out how to plot
one against the other. Anyone have any suggestions?
not sure if this is new (probably not): with the latest windows snapshot
it seems that running the 'open' command in a script closes the current
datafile without asking the user even if the file has unsaved changes. I
find this problematic because it has just caused me some (minor) dataloss.
I'm confused by the various 'end' statements, for example:
I cannot remember when I need a blank and when I don't, so I keep
looking up the same things over and over. Is there a rationale, or could
both forms with and w/o blank be made valid?
A word of warning for anyone in the habit of building gretl from
CVS with gnome support enabled: If you have specific preferences
set via the GUI and want to keep them, please take note of them --
I'm afraid you have to re-enter them.
This is because I've removed gconf support from gretl. I haven't
been following gnome development that closely, and didn't realize
how outdated and unloved gconf is until it bit me today: if you
ask gconf_client for the value of an integer config variable, it
will happily return 0 even if it failed to read anything, without
any indication of error.
>From now till further notice, gretl linked against gnome will use
the same plain text ~/.gretl2rc configuration file that's used by
non-gnome builds (other than on MS Windows, where we use the
Maybe once dconf matures we'll think about using that.
Department of Economics
Wake Forest University, NC
The new version of gretl, downloaded from the Ricardo site this
morning (Jan 5th), works for me on Leopard - it starts X11 and then
gretl. As a warning, the start-up is a little slow but that may be
because I was using a Macbook on battery power.
Many thanks for dealing with this.
>There's a new dmg, based on current CVS, at
>It's possible this may work with X11 on Leopard (that is, to start
>gretl from a situation where X11 is not already running).
The official dmg version of 1.7.1 - downloaded this morning - behaves
in exactly the same way as I reported for the 1.7.0 Fink
version. It cannot initiate X11, but it seems to work properly if
one starts X11 first and then double clicks on Gretl. I have run a
varity of time series analyses using the sample datasets without any errors.
>Date: Sun, 30 Dec 2007 19:27:41 +0100
>From: Sven Schreiber <svetosch(a)gmx.net>
>Subject: Re: [Gretl-users] Re: 1.7.1 / mac
>To: Gretl list <gretl-users(a)lists.wfu.edu>
>Content-Type: text/plain; charset=ISO-8859-15; format=flowed
>Am 29.12.2007 20:46, Gordon Hughes schrieb:
> > Thank you for providing the dmg for Mac Leopard users.
> > I have just tested it (the 1.7.0 version). This version of Gretl does
> > not start X11 from scratch. However, if it is run after X11 is started,
> > then I find that everything seems to work fine.
> > Gordon Hughes
>thanks for testing; does the official 1.7.1 dmg also work for you (on
>Leopard) as it did for Peter Chen? Does it exhibit the same (flawed)