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
6 years, 1 month
"join" + MIDAS, continued
by Allin Cottrell
(I should first say, if "MIDAS" doesn't mean anything to you and
you'd like to know, please see http://gretl.sourceforge.net/midas/ )
Three cases are relevant when you're using the new --aggr=spread
option to pull high-frequency data into a lower-frequency workspace,
namely:
1) The data to be added take the form of a native gretl data file,
with suitable time-series properties.
2) The data are are CSV, but with a suitable time-series structure
that is recognized as such by gretl. (Test: you can use "open" on
the CSV file and gretl gets the time-series information right.)
3) The data are CSV but are not organized such that gretl can "open"
it as time series correctly.
In cases 1) and 2) there shouldn't be any problem: just use
--aggr=spread, as in
# join monthly to quarterly
open AWM.gdt
join hamilton.gdt PC6IT --aggr=spread
# join daily to monthly
open hamilton.gdt
join djclose.gdt djclose --aggr=spread
(and similarly for compatible CSV files).
In case 3), however, you'll need to use two options to "join" in
addition to --aggr=spread.
First, use the --tkey option to tell gretl where (and/or how) to
determine the dates of the observations in the file from which
you're adding data (see the chapter on "Joining data sources" in the
Gretl User's Guide for details).
Second, use the (new) --pd option to "join" to tell gretl what the
frequency of the imported data is supposed to be. This option is not
yet in the documentation but that should be fixed before long. A
parameter is required, as in
--pd=12 # monthly
--pd=5 # daily, 5 days per week
(or 6 or 7 for daily data at 6 or 7 days per week). Gretl could
attempt to guess this via (fallible) heuristics, but you as user
should know what you're trying to do; please tell us and then we'll
be sure to get it right.
There follows an example of the syntax in case 3), supposing you
have a monthly data workspace and you wish to import 5-day daily
data from a CSV file in which there's a column headed "obs" holding
dates in the format month/day/4-digit-year:
join mydaily.csv --aggr=spread --tkey="obs,%m/%d/%Y" --pd=5
Allin
6 years, 9 months
Little things please little minds :)
by Riccardo (Jack) Lucchetti
I wasn't aware of how good modern browsers are at displaying XML. Try
this, just for fun.
1) from within gretl, save a dataset with 0 compression (in the GUI
interface, choose "Save File As" and set the compression to 0; or
alternatively, use the "store" command with the --gzipped=0 option.)
2) Rename the file you just created by changing its extension from "gdt"
to "xml"
3) Open it in Chrome or Firefox and marvel at how wonderful XML is :)
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
6 years, 10 months
boxplot accuracy
by Allin Cottrell
Responding to Frederik's posting at
http://lists.wfu.edu/pipermail/gretl-users/2017-December/012814.html
"Sometimes the candlebars pretend values which do not exist. I.e.,
if the IQR *1.5 data does not exist (which can happen - it happens
to me), the boxplot gives a false impression."
Please try a current gretl snapshot. This was a known issue but we
believe it's now fixed. In the current Changelog we have:
Boxplots: fix for incorrect extent of "whiskers" in some cases
Allin
6 years, 10 months
GNU Plot: "set termoption dashed" replacement?
by Logan Kelly
Hello all,
Quick GNU Plot question.
Gretl Build: 2017e-git (2018-01-16)
OS: Win 10
I am updating some old code, and the following used to provide a graph with dashed lines
gnuplot hrz$j_lst --with-lines --single-yaxis --time-series --output="US_Results_2018\hrz$j_FCAST_US((a)xlist)_20180119.plt" \
{ \
set term pngcairo font "Arial,10" size 500,400; \
set termoption dashed; \
set style line 1 lc rgb "#000000"; \
set style line 2 lc rgb "#005C8A"; \
set style line 3 lc rgb "#B20000"; \
set style line 4 lc rgb "#008F00"; \
}
Is there a quick way to replace
set termoption dashed; \
with something compatible with the newer GNU plot?
Thanks,
Logan
6 years, 10 months
"join" and MIDAS data
by Allin Cottrell
I sent a version of the following to the gretl-devel list, but with
a typo in the subject line: "jon" for "join". Reposting here for
wider dissemination.
Thanks to Sven for getting me going on this. The "join" command now
supports the "spreading" of high-frequency series (as wanted by our
MIDAS apparatus) in a single operation. This requires use of the
--aggr option with parameter "spread". There are two acceptable
forms of usage, illustrated below. (AWM is a quarterly dataset, and
hamilton monthly.)
open AWM.gdt -q
join hamilton.gdt PC6IT --aggr=spread
open AWM.gdt -q
join hamilton.gdt PCI --data=PC6IT --aggr=spread
In the first case MIDAS series PC6IT_m3, PC6IT_m2 and PC6IT_m1 are
added. In the second case "PCI" is used as the base name for the
imported series, giving PCI_m3, PCI_m2 and PCI_m1.
Only one high-frequency series can be imported in a given "join"
invocation with --aggr=spread (this already implies the writing of
multiple series in the lower frequency dataset).
An important point to note: this "--aggr=spread" thing (where we map
from one higher-frequency series to a set of lower-frequency ones)
relies on finding a known, reliable time-series structure in the
"outer" data file. Native gretl data files (gdt, gdtb) will be OK,
and also well-formed gretl-friendly CSV files, but not arbitrary CSV
files.
One of the pertinent features of "join" is that in general it
assumes almost nothing about the structure of the outer data file.
It just crawls across the rows of the file looking for matches, so
it can extract time-series data from a file that looks nothing like
"proper" time series. Here's a case in point:
$ cat thing.csv
thing1,thing2,Z
-1,0,1
999,999,2
1981,1,3
1980,1,4
1982,1,5
3556,14,6
$cat join-thing.inp
open data9-7 # quarterly data
series yr = $obsmajor
series qtr = $obsminor
join thing.csv Z --ikey=yr,qtr --okey=thing1,thing2
print QNC Z -o
Running join-thing.inp works fine: join plods through the nonsense
in thing.csv, finds three matches (in random order) and puts the "Z"
data in the right places in the working dataset.
If you have difficulty importing data MIDAS-style from a given CSV
file using --aggr=spread you might want to drop back to a more
agnostic, piece-wise approach (agnostic in the sense of assuming
less about gretl's ability to detect any time-series sructure that
might be present). Here's an example of what I mean:
<hansl>
open hamilton.gdt
# create month-of-quarter series for filtering
series mofq = ($obsminor - 1) % 3 + 1
# write example CSV file: the first column holds, e.g. "1973M01"
store test.csv PC6IT mofq
open AWM.gdt -q
# import monthly components one at a time, using a filter
join test.csv PCI_m3 --data=PC6IT --tkey=",%YM%m" --filter="mofq==3"
join test.csv PCI_m2 --data=PC6IT --tkey=",%YM%m" --filter="mofq==2"
join test.csv PCI_m1 --data=PC6IT --tkey=",%YM%m" --filter="mofq==1"
list PCI = PCI_*
setinfo PCI --midas
print PCI_m* -o
</hansl>
The example is artificial in that a time-series CSV file written by
gretl itself should work OK without special treatment. In fact this
will work fine:
<hansl>
open hamilton.gdt
store hamilton.csv
open AWM.gdt -q
join hamilton.csv PC6IT --aggr=spread
</hansl>
But you may have to add "helper" columns to a third-party CSV file
to enable a piece-wise MIDAS join via filtering.
Allin Cottrell
6 years, 10 months
small code reorganization
by Allin Cottrell
Hello all,
This message is really only relevant for folks who are compiling
gretl themselves, so maybe more appropriate to the "devel" list. But
since there may be some people in that category on the users list
but not the devel list, I'll post here.
So, if you're building gretl from source: after a "git pull" with
today's updates, please be sure to do "make clean" followed by a
"configure" run before doing "make" again. That's because I have
renamed/moved a bunch of files lately -- something that was very
awkward to do under CVS (our old version control system) but quite
easy under git, and which was overdue.
Specifics:
1) I've renamed the "gui2" directory as "gui". The "gui2" name
derived from ancient days when I ported gretl's GUI from gtk 1.2 to
gtk 2.
2) The Ramanathan textbook datafiles were at one time the only data
packaged with gretl. As of now they don't have a special status, so
I've moved them into their own subdirectory. (Though I'm still very
grateful to Ramu Ramanathan for helping gretl to get started.)
The repositioning of data files means that some files that were
installed previously should now be deleted. Here's a listing (where
$prefix is the installation prefix you selected for gretl, by
default /usr/local):
$prefix/share/gretl/data/*.gdt
$prefix/share/gretl/data/descriptions
$prefix/share/gretl/data/greene/wg_descriptions
If anyone comes across build or runtime errors associated with this
rename/move please let me know and we'll fix them asap.
Allin Cottrell
6 years, 10 months
matrix rowname (without "s") similar to colname; obs and functions
by Schaff, Frederik
Sorry for so many questions ;) I still find new ones.
a) Is there a way to access rownames similar to 'colname(matrix M, scalar column)'? If yes, do rownames default to the index, if not explicitly provided? How das print matrix access the rownames?
b) I am trying to find a solution to get the observation number of a specific entry of a series in a subsampling (i.e., the integer with which I could access this entry in the full sample), in order to synchronise it with a matrix OBSDATE I have in a bundle that is passed to this function and holds string labels for each element in the full sample.
I can check via $nobs == nrows(OBSDATE) if there is a subsampling (which will not always work..), but I do not know, how I can then treat with it (in both cases, time-series data and cross-section data). If I use "obs" to generate a new series, than it does not relate to the global identifiers but creates a new, small series of consecutive integers (as is stated within the help). At the same time, the series within the bundle is not synchronised with the global series'. Is there a way to deal with this? Or is the only option to print an error message and demand that the bundle is reinitialised accordingly with a series "obsdate=obs" from outside any function definition? Isn't there a (hidden) accessor for a series entries' real (i.e. in full sample) obsnumber/date?
perhaps $sample is an option? (Although I do not know how... ) and basically $t1 and $t2 work for the first and last element in the current (sub)sample, but the values in between are not provided?
c) Misc. feedback :
a. obs and obsnum are not highlighted in the editor (but the question mark works nonetheless)
b. Instead of "varname()" one needs to use "argname()" to get the name of a series (even when passed by pointer). This could be noted in the gretl help (q-mark in script editor)
c. neither argname nor varname work on elements contained within a bundle. It does also not help to make an new series from the series within the bundle (btw., pointer arithmetic is not allowed at all in this case). It would be nice if this would work. My Workaround is to have a special function that "adds" series to the bundle and, at the same time, adds a key-entry for the series name.
d. A recursive "exists" for bundles would be nice. I.e. if I ask "exists(a.b.x)" it is checked if x exists, but if "b" already is missing, an error is produced. Perhaps a exists(a.b.x) --recursive option? Alternatively, if conditions would be checked one at a time, this would also help. For example 'if exists(a.b) && exists(a.b.x)' does not work if a.b does not exist (https://en.wikipedia.org/wiki/Short-circuit_evaluation)
d) Misc. questions:
a. When I attach, within a function, a genr element (like series) that was passed by pointer to the function, to a bundle, it is in fact copied (hansl-primer p.20). Is there a way to instead add pointers to the bundle? Perhaps by means of using the array type?
Thanks
Frederik
6 years, 11 months
yahoo finance download
by matteo foglia
Dear All,
where I can find the package for "yahoo finance download". I can't find it
in new version on Gretl (2017c)
Thank in advantages,
best
Matteo Foglia
6 years, 11 months
Contributed function packages in 2017
by Sven Schreiber
Hello everybody,
since the New Year is just one week old, maybe this piece of news is
still appropriate. (Artur, maybe also for Twitter, if you don't know
what to tweet...)
After a quick recount it looks like 64 packages have been updated or
added in the public package repository over the year 2017.
(Admittedly, a number of updates were just about minor syntax fixes, but
still.)
So I encourage everybody to look for econometric functionality not only
directly in the gretl menus, but also look under "file - function
packages - on server" and to check whether some local package copies
need updating. (Look at the right column in the list.)
If you want to look at the package list on the web, go here, which shows
a current total of 116 packages:
http://ricardo.ecn.wfu.edu/gretl/cgi-bin/gretldata.cgi?opt=SHOW_FUNCS
(And @Allin, I think the given menu path at the top of that page needs
updating, too.)
Thanks to all contributors, and we always welcome new contributions --
under the help menu you have access to a function packaging guide for
script authors!
happy 2018,
Sven
6 years, 11 months
