Named lists in nested functions
by Marcin Błażejowski
Hi,
suppose we have two functions: Foo and foo.
We pass a named list to function Foo, which body contains line with call
of function foo and foo takes as an argument series not list, for which
computes simple ols (example code below). Where is the problem? Function
foo doesn't even run ols, so no accesors are available and we get error.
So the question is: can we do such crazy nests?
Marcin
<script>
function foo (series *X)
ols X const time
series X_uh = $uhat
return series X_uh
end function
#
function Foo (list Y_list)
loop foreach i Y_list
foo(&Y_list.$i)
end loop
end function
#########################################
set echo on
nulldata 100
setobs 1 1 --time-series
genr X = normal()
list test = X
Foo(test)
</script>
--
Marcin Błażejowski
http://www.wrzosy.nsb.pl/~marcin/
GG# 203127
15 years
Replay on case-sensivity
by Allin Cottrell
Here's a more extended reply to Berend Hasselman's posts on
case-sensitivity with regard to variable names in gretl.
First, I've now modified the Find dialog for the gretl main window
so that it gives the option of a case-sensitive search on variable
names only. (I suppose a common use of this dialog is to find
strings anywhere in the window, including in the descriptions of
variables, in which case a case-insensitive search is
appropriate.)
Now to Berend's request that gretl should ignore case when
handling variable names. One point to be made here is that this
would be a backward-incompatible change, and a rather devastating
one: I know that it would break a _lot_ of the gretl scripts on my
system. That's not a killer argument for staying with the status
quo, but it means there has to be a rather compelling reason for
change.
I don't see a compelling reason; in fact, I think that on balance
the argument for case sensitivity outweighs the arguments against
(disregarding the compatibility issue).
As I see it there are three possible arguments for ignoring case:
(1) Case sensitivity can make it inconvenient to deal with
third-party datasets that use mixed case for variable names. It
would be more convenient if one could assume that when "foobar" is
typed in gretl this will automatically map onto a variable named
"FooBar" in imported data.
Comment: Granted, this can be a (minor) inconvenience. But any
decent text editor has an option to adjust the case of selected
text, so for plain text data files this shouldn't really be an
issue. It _might_ be worth adding an option in gretl to convert
all variable names to lower case.
(2) The possibility of having variables whose names differ only in
respect of case creates potential for confusion: how to keep
"cpi", "CPI" and "Cpi" straight?
Comment: Use a sane policy in naming variables (but see below).
(3) Users of MS Windows are unused to case sensitivity and may
find the effects surprising.
Comment: Yes, but it doesn't take long to learn.
Now here's the positive argument in favour of case sensitivity.
The issue of "sensitive or not" mostly arises in the context of
scripts, where variable names have to be typed rather than
"clicked on". That is, it mostly arises when gretl is being used
as a programming language. OK, programming languages differ with
regard to case sensitivity, but many of the best and most
widespread ones respect case (C and Java, for instance). And in
an econometric context it seems to me very natural to expect case
sensitivity, as one finds it in mathematical notation. Here are
just a few examples:
t = time index; T = maximum value of t
i = index variable; I = identity matrix
Y = output; y = log of output
m = scalar; M = matrix
People's expectations may differ, but I would very definitely not
want to see these uses of case broken.
--
Allin Cottrell
Department of Economics
Wake Forest University
15 years
formula of Gini-coefficient
by Paar David
Hello!
I would like to inform, which formula of Gini-coefficient is used by Gretl.
Thank you!
David Paar
15 years
Re: Round the circle with Gretl on Linux
by Gordon Hughes
Sorry: my error for point C, though there may a lesson in it. Also
my apologies for my loose language in referring to applications as
.exe files - too much switching between Windows, OS-X and Linux.
The source of the problem was that the GTK2 development libraries
were not fully installed. So, the configuration program decided that
gretl should be compiled without GTK2. That works, but only to
generate a command line version of the program - hence gretlcli but
not gretl_x11. This is flagged in the configuration summary, but I
had not understood the significance. The full configuration log
reports the absence of GTK2 libraries, which pointed me to the
mistake. Everything was ok once I re-installed all of the GTK2
development libraries.
A suggestion: would it be possible (desirable) for the configuration
program to end with a warning that only the command line version will
be generated if the "Build with GTK version" flag is "No" - in the
same way that it gives an error message if, say, FFTW3 is missing?
I will test the rpm with the --nodeps option to see what
happens. One of my pet grouses is that every Linux distribution sets
up a different default path. It shouldn't miss lapack when
installing as root, but I have had previous errors generated by the
omission of some usual directories from the default path.
A follow-up question: in scrutinising the configuration log I noted
that MPFR support was absent, so I installed the relevant development
libraries to correct this. I understand that this is ancillary to
GMP but how much difference does it make to the performance of gretl?
Gordon
15 years
Round the circle with Gretl on Linux
by Gordon Hughes
I had a disk failure on my main desktop which meant starting again
with a new installation of Linux under a new hardware
configuration. Neither Ubuntu nor OpenSUSE handle my hardware
properly, so I am using Mandriva 2009 and have been trying to install
gretl with the following results:
A. The version of 1.7.5 in the Mandriva repository installs properly
using the Install/Remove Software program.
B. After un-installing this version (and deleting associated .gretl*
files) I tried the rpm for version 1.8.0. The installation fails,
complaining that it cannot find libblas.so.0 - though there is a
symbolic link with this name in /usr/lib.
C. Then, I tried compiling gretl-1.8.0 from source. This appears to
complete without errors. However, the command "gretl" does not work
and I cannot find the X11 version of the program, to which gretl
should provide a symbolic link. The programs gretlcli.exe and
gretl-config.exe exist and can be run from the terminal.
Any suggestions? I can revert to version 1.7.5 but I need to use
facilities introduced later versions in some of my functions.
Gordon Hughes
15 years
Markov-Switching Models
by Henrique
Dear gretl users,
Is it possible to estimate Markov-Switching models using gretl?
Cheers,
Henrique C. de Andrade
Doutorando em Economia Aplicada
Universidade Federal do Rio Grande do Sul
www.ufrgs.br/ppge
15 years
R: Re: R: Re: [Gretl-users] Gretl and X-12-ARIMA and TRAMO/SEATS
by deriv＠libero.it
Thank you very much, Ignacio, it works...
I had the two programms in a different path with respect to the default
ones.
Thank you again.
Have a nice weekend.
Pier
----Messaggio originale----
Da: ignacio.diaz-emparanza(a)ehu.es
Data: 06/04/2009 12.18
A: "Gretl list"<gretl-users(a)lists.wfu.edu>
Ogg: Re: R: Re: [Gretl-users] Gretl and X-12-ARIMA and TRAMO/SEATS
El Monday 06 April 2009 08:55:50 deriv(a)libero.it escribió:
> I tried to do your suggestion but it does not work, in the variable menu
in
> Gretl the mentioned 2 programms are visible in light grey but they are not
> openable when you click on them.
>
I assume that you downloaded the programs from the gretl web page
(gretl.sourceforge.net). If so, may be that the paths to the executable
programs are wrong. You can correct them in the
menu /Tools/Preferences/general/Programs
--
Ignacio Diaz-Emparanza
DEPARTAMENTO DE ECONOMÍA APLICADA III (ECONOMETRÍA Y ESTADÍSTICA)
UPV/EHU
Avda. Lehendakari Aguirre, 83 | 48015 BILBAO
T.: +34 946013732 | F.: +34 946013754
www.et.bs.ehu.es
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
15 years
Correcting for inflation (revisited)
by Allin Cottrell
On Sat, 11 Apr 2009, Raz Lev wrote, in regard to adding a
time-series variable to an existing panel dataset:
> the problem I have was 'matching' the CPI data to the records -
> I have 400,000 records and was not sure how to match the right
> CPI to each one...
And I responded with an illustrative script that would take the
straight time-series CPI input and, via an intermediary matrix,
"panelize" the data.
That script was OK but I seriously missed a trick. Gretl is
cleverer than you think! In fact all you have to do is use the
"append" command. If the time-series length of the data you are
appending matches the number of time periods in the panel, gretl
automatically does the right thing -- no need to mess with
matrices. I'd forgotten about that facility.
Allin Cottrell
15 years
Case (in)sensitivity
by Berend Hasselman
I have noticed that Finding variables does a case insensitive find.
However in genr variable names appear to be case sensitive.
I feel that it is not good practice to use case for distinguishing
between variables.
I prefer mY and MY to refer to the same entity and to use case for
purely textual purposes.
When importing data, one may not always have control over the case of
variable names.
So I would like to request
- an option to change the case of all variable names (lower and upper)
- (and/or) for variable names to be treated case insensitively.
Berend
15 years
Repeated Measurements Analysis
by June-Chiew Han
Hello,
I would like to have an idea on how to analyse (with the 2-Stages Least
Squared Method) repeated measurement data.
For example, data have subject j and in each subject, have observations
k, i.e. the data may look like [X_jk Y_jk], and a least-square line is
to be fitted to Y-X.
Thanks.
Regards,
JC
15 years
