geno83(a)gmail.com @ wrote 2008-04-17 19:12:44 :
> I'm working on ANOVA. I want put one way Anova and two way Anova to
> I made first version of one way ANOVA. It is still test version, but
> it's working.
> You can download sources and test it.
> I will be glad if you put ANOVA to gretl official version.
Very good. ANOVA is one of the features I have missed in gretl. I hope that
you will continue to contribute code to gretl.
gretl crashes while trying to load a session file on which
yesterday. To be frank with you: it is not the
first time that gretl
I don not know what the problem is. I have this problem on
Ubuntu 8.04. At the moment I am using gretl 1.7.5
but I also had this
problem with former versions,
Unbegrenzter Speicher, Top-Spamschutz, 120 SMS und eigene
I will be out of the office starting 06/28/2008 and will not return until
I will be out of the office from June 28 until July 7, returning to work on
July 8, 2008. If you have any questions regarding Construction Economics
and/or Cost Model, please contact Bradley A Njus at 510 625 4595.
Another query about mle. As before, I have been experimenting with
stochastic frontier models and I have found that mle behaves entirely
differently with two formulations that seem to be equivalent.
scalar ss = sqrt(su^2 + sv^2)
params b su sv
end mle --hessian --verbose
scalar ss = sqrt(su^2 + sv^2)
params b su sv
end mle --hessian --verbose
Both report identical log-likelihoods & gradients at iteration 1, but
version 2 blows up at iteration 2 while version 1 continues
properly. Technically, the reason for the blow-up in version 2 is
that it uses a step length of 1, whereas version 1 uses a step length
of 1e-7. I cannot understand the reason for the different behaviour
but in this case it is critical.
I have been comparing the output of gretl and Stata for the
half-normal stochastic frontier model (Example 17.1) in the User's
Guide. They are extremely close, which is reassuring. Without
detailed timings my impression is that the execution times are not
substantially different - my sample is ~ 550 observations and the
model has 13 parameters.
This exercise prompts me to raise a question. The default mle setup
relies upon numerical rather than analytical derivatives. In the
days when I was programming maximum likelihood models, this would
have imposed a huge performance penalty. But writing out all of the
derivatives is rather tedious in mle if one wants to test a lot of
different specification - unless one does it properly via a function
that can parse the number of independent variables, etc. So, the
question is - has anyone assessed the performance penalty from using
numerical rather than analytical derivatives? For example, I note
that the ZIP model shown as Example 17.3 does not have any deriv
statements, so clearly it was not thought worthwhile including them.
One point is that in my experience the use of numerical derivatives
can problems when the starting values are poor. I found this with
the standard deviation parameters (su & sv) in SFA model when I got
the scale wrong - mle blew up very quickly reporting that something
was not a number. This should not happen with analytical derivatives.
I would appreciate any comments. Then I will set about defining
various SFA models as user functions and later as function packages
that others can use.
I should have been more precise. In fact, I discovered that I had
both g77 and gfortran installed, so that the first step was to uninstall g77.
With respect to file location:
(a) In config.h GRETL_PREFIX = /usr/local.
(b) The config_dump.txt file generated by "gretl --dump" includes
# Main gretl directory
gretldir = /usr/local/share/gretl/
(c) The effect of cleaning out ~/.gretl2rc appears to be different in
Ubuntu and OpenSUSE. Under Ubuntu, everything is ok when I recompile
gretl after doing this. Under OpenSUSE I need to edit ~/.gretl2rc to
ensure that gretldir is set correctly - alternatively that can be
done from the Tools/Preferences options.
At this point I don't think that the issue is worth any more
effort. Clearly, getting rid of old versions of ~/.gretl2rc is a
good idea. Incidentally that may mean looking in the /root directory
as well as /home/user if at some stage in the past one has run gretl
from the terminal as a superuser. Otherwise, the problems that I
have encountered seem to be unusual and must reflect the history of
several installations of gretl on my OpenSUSE system.
A. The problem with the undefined symbol.
I did have g77 installed, but removing it did not solve the
problem. I tried installing a different version of Atlas - following
the note on matrix arithmetic - but that just produced the same error
referring to a different library. In the end, I had to remove Atlas
altogether - together with other libraries that depend upon it. Now,
the NIST test script runs properly. I may trying adding Atlas back -
cautiously - but the extra speed isn't that important for me. So -
beware Atlas under Ubuntu.
B. Files in the wrong place
My path - on both Ubuntu & OpenSUSE - does include /usr/local/bin. I
don't know about ldconfig, but you are correct in identifying the
file ~/.gretl2rc as the source of the problem, though because it is
being wrongly created rather than because it is a stale version.
As a test I cleaned every vestige of gretl off my OpenSUSE system and
emptied the trash. Then I recompiled gretl from scratch with the
default options. Finally, I ran gretl - exactly the same problem as
before : the program looks for files in /usr/share/gretl/ rather than
/usr/local/share/gretl/. I checked the contents of .gret2rc and this
contains the following lines at the top
# gretl config file
# Main gretl directory
gretldir = /usr/share/gretl/
I assume that gretldir should be /usr/local/share/gretl/. If I
delete just .gretl2rc and try again, the re-created version is
identical. At this point I am stuck, though it is no inconvenience
to compile gretl with the prefix option to force everything to go in
the same place.
> Thank you for the advice on dealing with the undefined symbol in
> Ubuntu and the pointer to the discussion of Atlas, etc. I will
> experiment with alternative versions to the libraries to see
> what works best.
OK, we'd be interested to hear what you find.
> On the first point, I have identified that the following types
> of file can't be located with the default installation: (a) help
> files (this warning comes up when the program loads), (b) gretl
> logo in Help/About dialogue, (c) sample data files (File/Open
> data/Sample file) and database (File/Databases/Gretl native),
> and (d) sample script files (File/Script files/Practice file)...
Delete (or edit) ~/.gretl2rc and try again. I strongly suspect
you have a stale personal gretl config file in place that is
pointing to the wrong location for gretl's shared files.
I never used Gretl before. And when i first downloaded and installed
it, i dont have time series model and several other models. Btw, I use
windows. So are there any other packages that I need to download too?
Thanks a lot.
Thank you for the advice on dealing with the undefined symbol in
Ubuntu and the pointer to the discussion of Atlas, etc. I will
experiment with alternative versions to the libraries to see what works best.
On the first point, I have identified that the following types of
file can't be located with the default installation: (a) help files
(this warning comes up when the program loads), (b) gretl logo in
Help/About dialogue, (c) sample data files (File/Open data/Sample
file) and database (File/Databases/Gretl native), and (d) sample
script files (File/Script files/Practice file). I think that there
are others, but the key seems to be the location of ./data, ./db,
./demo (probably), ./doc, ./scripts. I haven't experimented with
plugins but those may go in the wrong place too.
You may be correct about the default setup for paths under Ubuntu &
OpenSUSE - again I will experiment with alternative setups.
Sven's option works - provided that you have a Tex processor
installed, which I didn't initially - but only with respect to help
files because it forces a rebuild of the documentation. The data &
script files are still put in /usr/share
On Mon, 23 Jun 2008, Gordon Hughes wrote:
> A follow-up to my previous e-mail, based on further
> experimentation on compiling gretl 1.7.5 under both OpenSUSE &
> Ubuntu 8.04. It seems that the only way to get a fully
> functioning version of gretl using the current configuration
> script is to include the option "--prefix=/usr" in the configure
> command. Without that, some files get put in places where gretl
> can't find them.
Which files get lost in this way?
> There is an additional problem under Ubuntu 8.04...
> /usr/lib/atlas/liblapack.so.3gf: undefined symbol:
Jack has responded to this one. I'll just add that it seems to me
to be a slight glitch in the Ubuntu packaging system. The package
containing liblapack.so.3gf should really have a dependency on
the gfortran package, but it doesn't.
You won't hit this issue if you use the "vanilla" lapack package,
but if you're using the "gf" atlas lapack, uninstall g77 and
You might also take a look at:
I have two time-series with different window observation. I have values for the first one in [0, T] and for the second one in [t1, T] where 0 < t1 < T. So, they match in a little window [t1, T]. I have an ARIMA model including two series and I would like to rebuild the second one to the no observed period, I mean to the period [0, t1]. How could I do that with Gretl?
Thank you in advance.
Tecnología, moda, motor, viajes,…suscríbete a nuestros boletines para estar siempre a la última
Guapos y guapas, clips musicales y estrenos de cine.