Function to get the powerset
by Henrique Andrade
Dear Gretl Community,
I really stuck trying to define a function that gives a power set of a
set. Suppose I have a set S:
S = {"A", "B", "C"}
The associated power set, P(S), is:
P(S) = {{ }, {"A"}, {"B"}, {"C"}, {"A", "B"}, {"A", "C"}, {"B", "C"},
{"A", "B", "C"}}
All that I can think by now (shame on me!) is this:
strings S = defarray("A", "B", "C")
scalar P_S_len = 2^nelem(S) # the size of the power set
strings P_S = array(P_S_len) # an array with 8 spaces.
Does anyone have any ideas?
Best,
Henrique Andrade
2 years, 4 months
warning: gdt-reading bug
by Allin Cottrell
We've just noticed that a bug was introduced into our code for reading
native gretl .gdt data files in August of this year. The bug should be
triggered only rarely, but we thought it wise to issue a warning.
Description of bug: If a gdt file contains "subnormal" values (that
is, floating point values that are too close to zero to be represented
with the usual precision), then when such a file is read on Linux, the
first subnormal value to be found on a given row (observation) will be
incorrectly copied into the remaining columns (series) on that row.
Example: A gdt file containing 10 series has a subnormal for series
number 5 on row 25. Then when the file is read on Linux, that
subnormal will replace the correct values for series 6 to 10 for
observation 25.
Comment: This won't affect the reading of "primary" data (actual
micro- or macroeconomic measurements), which will never contain
subnormal values (we're talking about absolute values less than 10 to
the minus 307). And the bug is not triggered on MS Windows. However,
subnormal values may be produced by some data transformations (such as
squaring very small numbers, or computing the normal CDF of very big
negative values).
Fix: This is now fixed in the git source for gretl and also the
current snapshots. And we will put out a new release soon, gretl
2015d.
Diagnostic: If you think a dataset may suffer from this problem,
you can run the script checkdata.inp, from
http://ricardo.ecn.wfu.edu/pub/gretl/checkdata.inp
First load the dataset in question. Then open checkdata.inp and run
it. An affected dataset may produce something like this:
<script-output>
Total number of values examined: 164122
Check for subnormal floating-point values
-----------------------------------------
Total number found: 138
Longest (row) sequence: 138
(occurs at obs 210, starting series ID 461)
Number of sequences (of length >= 2): 1
</script-output>
The symptom of a problem is that we find a consecutive sequence of
subnormal values on one or more rows of the dataset. This could occur
for "natural" reasons but it may indicate corruption. Isolated
subnormals don't indicate the bug. And again, most datasets should
contain no subnormal values.
Allin Cottrell
4 years, 4 months
new Kalman interface
by Allin Cottrell
For anyone interested in working with state space modela via gretl:
please note that we have now replaced the documentation in chapter 30
of the Gretl User's Guide with an account of the new (bundle-style)
interface. We think the new code is now ready to roll, but if anyone
is able to do some testing before the next release -- which should be
in a week or so -- we'd be grateful.
The old Kalman interface is still available for now (but will likely
be removed in the release following the next one). And you can find
the old doc at
http://gretl.sourceforge.net/papers/kalman_old.pdf
Allin Cottrell
4 years, 7 months
strange behavior
by Andreas Zervas
Hi all,
I am attaching two scripts that produce a behavior that puzzles me. test.inp makes some series and calls test_fcn.inp; the latter has 2 functions that produce lags for a list of variables and for matrices. Under Windows 7 & 8 (and Gretl 2015d in both machines) the code runs - it is an old code since 2011 and Gretl 1.9.5 I think. However, the function for lists is not working in Linux (Ubuntu 15.10 + Gretl 1.10.1) and I can not understand why.
The problem seems more general, as other functions that I have work with matrix arguments but not with list arguments in Linux.
Any suggestions?
Thank you for your time and effort.
Andreas
4 years, 8 months
plot with --band option, revisited
by Allin Cottrell
Last month I announced the existence of a --band option for the
"gnuplot" and "plot" commands -- see
http://lists.wfu.edu/pipermail/gretl-users/2016-May/011846.html
Since then, Jack and I have considered this more carefully, and the
next gretl release (due out within a week) will incorporate a
modified version of this option. The new version is more functional
than the previous one, and moreover it is designed to allow future
extensions in case we decide it's worth supporting more complex
variants.
So here's the current situation: the "band" information is spread
across two options, --band and --band-style. The syntax is as
follows:
(1) --band wants either 2 or 3 comma-separated arguments: the
"center" of the band (which may or may not be plotted in its own
right), the "width" of the band (e.g. a series holding standard
errors) and, optionally, a multiplier (e.g., number of standard
errors). If the third argument is omitted it defaults to 1.0.
So suppose you have series yhat and se_yhat and you'd like to plot
yhat along with a band at yhat plus-and-minus 1.96 se_yhat; then the
option would be
--band=yhat,se_yhat,1.96
However, if your second series is already expressed as suitable
multiples of standard errors (call it "maxerr") you could do:
--band=yhat,maxerr
(2) --band-style wants either 1 or 2 arguments (comma-separated if
you give two). The first may be either "line", "dash" or "fill", to
represent the band by enclosing lines or dashes, or by a shaded
area. The default, if this argument is omitted, is "line". The
second is a hexadecimal RGB color specification: for example
0xff0000 means red. Examples:
--band-style=fill # shaded area using default color
--band-style=dash,0x0000ff # blue dashes
--band-style=0xdddddd # grey lines
If you want the center of the band to be plotted in its own right
you should give that as an argument to the "gnuplot" command. Here's
a simple example:
gnuplot yhat --band=yhat,se_yhat,2 --with-lines
This mechanism also works with the "plot" command-block:
list P = yhat # add more series if you like
plot P
options band=yhat,se_yhat,2 band-style=0xdddddd
option with-lines
end plot --output=display
It also works when plotting columns of a matrix. However, in this
case the columns to be plotted in their own right are given in one
named matrix and the (center,width) of the band are given in a
second named matrix with two columns. Example:
matrix MP = {yhat} # plot more columns if you wish
matrix B = {yhat,se_yhat}
plot MP
options band=B,1.96 band-style=0xdddddd
option with-lines
end plot --output=display
Allin Cottrell
4 years, 8 months
Drop-down menu issues
by Clive Nicholas
Linux Mint 17.3 MATE, -gretl- 2016c-git
I've noticed over the last several versions of -gretl- that I can no longer
activate the drop-down menus in the results output window. I can fix it by
clicking on the 'Windows' menu and then selecting 'Arrange', which sends
all the windows to the north-west of my screen, but this is a bug, isn't it?
Once this is fixed, I want to film a new tutorial soon to post onto YT, but
none of the screencasting tools I've experimented with (including
Vokoscreen) works satisfactorily. Suggestions, please?
--
Clive Nicholas
"My colleagues in the social sciences talk a great deal about methodology.
I prefer to call it style." -- Freeman J. Dyson
4 years, 8 months
accents, line breaks
by Allin Cottrell
This is in response to Henrique Andrade's postings,
http://lists.wfu.edu/pipermail/gretl-users/2016-June/011883.html
http://lists.wfu.edu/pipermail/gretl-users/2016-June/011884.html
It turns out that these issues could be fixed without great difficulty
-- see git and the current snapshots. We now intercept and modify "%s"
string conversion specifiers for printf and sprintf so that numerical
values indicating width and "precision" are taken to be in UTF-8
characters rather than bytes.
Since email is liable to mangle this sort of thing, I'm attaching a
little PDF file which illustrates "before" and "after".
As for extra line-breaks appearing in some contexts on Windows, this
is to do with the Windows-specific business of opening files in text
versus binary mode; I think it should be fixed now too.
Allin
4 years, 8 months
plots with "bands"
by Allin Cottrell
This is somewhat relevant to
http://lists.wfu.edu/pipermail/gretl-users/2016-May/011845.html
but may be of interest in its own right.
In git and snapshots there's a new option, --band, for the commands
"gnuplot" and "plot". Right now it's very basic (and not yet
documented); it could be fancied up in future by adding a parameter to
inflect the option's effects.
Anyway, here's how it works now. If you have a plot with 3 or more
"lines", the --band option tells gretl to interpret lines 2 and 3 as
upper and lower limits (or vice versa) of a band of some sort (e.g. a
confidence interval). This means that
1) The two band limits will be shown in the same color.
2) The "key" or legend will be suppressed.
3) Gretl will not add a second y-axis, regardless of the scale of the
data (i.e. the option --single-yaxis is implicit).
To see what this does in practice you can compare these two plots:
<hansl>
nulldata 50
set seed 12345
setobs 1 1 --special-time
series y = normal()
series upper = y + 2
series lower = y - 2
list L = y upper lower
gnuplot L --time-series --with-lines --output=display
gnuplot L --time-series --with-lines --output=display --band
</hansl>
Yes, it would be nice if you could also set the style of the band
(e.g. make it a shaded area rather than two lines). That may come,
but it's a lot more complicated.
Allin
4 years, 8 months
odd behavior of "diff"
by Summers, Peter
Dear all,
I've run across something strange when using diff() in a loop. Given a series with missing values, Gretl seems to be "recycling" values from the previous loop iteration. The following script illustrates the problem: on the second loop iteration, the series "r" should be missing for the first half of the sample but instead the values from the first loop iteration are printed. Doing the same thing "by hand" after the loop produces what I'd expect. Is this intended?
<hansl>
nulldata 104
setobs 52 2006-01-03
series y1 = uniform()
series y2 = uniform()*(obs>obsnum(2006-07-04))
y2 = zeromiss(y2) # y2 is missing for first half
list ylist = y1 y2
loop foreach i ylist --quiet
r = 100*diff(log(ylist[i]))
print ylist[i] r --byobs
endloop
r1 = 100*diff(log(y1))
r2 = 100*diff(log(y2))
print r1 r2 --byobs
</hansl>
TIA,
PS
[cid:logoimg]
4 years, 8 months
How i can calculate the residual in a missing observation in tramo?
by Manuel Dario Hernandez Bejarano
Good morning.
My name is Dario Hernández, i am using the program TRAMO in gretl and i
don't understand how calculate the residual in a missing observation. Can
you help me?
Best regards,
Dario Hernández
Master in Statistic
National University of Colombia
4 years, 8 months
