three questions regarding plots in Gretl
by maite cabeza
Hi,
Three questions regarding plots in Gretl:
1) Is it possible to do a *scatter plot* of two variables, *with*
attached *marginal
histograms* next to the corresponding axes, like the picture attached? It
would be great if it was possible!
2) How can we get a *density histogram* without having to have the normal
distribution included in the plot. By now, the only way we can get a
density histogram (not frequency) is to select to tested against the normal.
3) Observation markers can be easily added to a single, or to all,
observations in a X-Y scatter plot, but I do not see how to do the same
with X-Y with control.
Thanks,
Maria
6 years, 2 months
marginal histograms + kernel densities + observation markers in added variable plots
by maite cabeza
Hi,
Three questions regarding plots in Gretl:
1) Is it possible to do a *scatter plot* of two variables, *with*
attached *marginal
histograms* next to the corresponding axes, like the picture attached? It
would be great if it was possible!
2) How can we get a *density histogram* without having to have the normal
distribution included in the plot. By now, the only way we can get a
density histogram (not frequency) is to select to tested against the normal.
3) Observation markers can be easily added to a single, or to all,
observations in a X-Y scatter plot, but I do not see how to do the same
with X-Y with control.
Thanks,
Maria
6 years, 2 months
Older discussion at gretl-users & Bundles
by Schaff, Frederik
>... AW: [Gretl-users] matrix rowname (without "s") similar to colname; obs and functions
>
> This thread is becoming quite complex. Maybe you could enter a short ticket
> (bug or feature request, doesn't matter much) for this on the sourceforge
> tracker.
Hi there, I did now find the time to go through my many questions and your many answers again, to do as Sven suggested (quote) and opened a few tickets.
However, I have some more general remarks on my recent experiences with bundles (which are great!), which I guess are better posted here.
Consider a list C in bundle B which is again located in bundle A. At some point, when passing a bundle by reference to a function and then passing a part of that bundle by reference to another function, a list that was part of the bundle became undefined (the lest went away). I cannot reproduce this and perhaps I remember wrong. However, a bit of the story I can reproduce:
<hansl>
nulldata 100
series A = normal()
list L = A
bundle boo
bundle coo
boo.coo = coo
eval inbundle(boo,coo)
boo.coo.L = L
eval inbundle(boo.coo,L)
function void testA(bundle Bndl)
eval inbundle(Bndl,L)
#eval argname(Bndl.L[1]) #error
eval varname(Bndl.L[1]) #OK
end function
function void testB(bundle *Bndl)
eval inbundle(Bndl,L) #not OK
end function
testA(boo.coo) #OK
catch testB(&boo.coo) #not OK
</hansl>
Including lists within bundles allows to do operations like sampling and manipulating series located outside the bundle (which is great!), also varname(C[1]) would return the variable name of the first element in list C. So basically this is a way to pass a series by pointer, which is very useful. Perhaps this should be mentioned in the references?
Best
Frederik
6 years, 2 months
Midas bug when lagging hi-freq series by low-freq lag
by Sven Schreiber
Hi,
I observe the following problem (also with today's snapshot). Right now
I don't have the time to try to create a minimal-example script, but I
can follow up on that. And perhaps the verbal explanation already helps.
In a quarterly workfile I have a couple of monthly variables as Midas
lists, say x_m3/m2/m1 and y_m3/m2/m1.
I then create a single regular (quarterly) variable by calculating
something like:
series z = x_m3 - y_m3
Finally I apply a regular (quarterly) lag:
z = z(-1)
In the end --but only after the last step-- the resulting z series is a
constant (non-unit) term.
cheers,
sven
6 years, 2 months
"jon" and MIDAS data
by Allin Cottrell
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
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
6 years, 2 months
Midas and join (or append)
by Sven Schreiber
Hi,
I will be working with Midas in gretl again soon, and I've just reread
(or let's say, re-browsed) the midas_gretl.pdf guide.
Looking at the section "importation via join", it occurs to me that this
is quite involved. In contrast, "importation from a database" is very
simple.
Shouldn't it be possible to just do something like this:
<hansl-future>
open AWM.gdt # quarterly
join hamilton.gdt EXRITL --compact=spread # monthly to quarterly
</hansl-future>
or perhaps the 'append' command is better suited than join here? So
replace the last line above with (which however gets all series, but
that's OK):
append hamilton.gdt --spread
I guess this append thing would basically be a syntactic shortcut for
this block (more or less):
pd = $pd
store temp.gdt # the currently active dataset
open hamilton.gdt --preserve
dataset compact pd spread
store tempcompact.gdt
open temp.gdt
append tempcompact.gdt
I'm ready to consider working more with the database storage format
(which I almost never have done), but is the above suggestion unreasonable?
thanks,
sven
6 years, 2 months
doc: mean, median for matrix
by Sven Schreiber
Hi,
functions like mean(), median(), sd() etc. aren't for a matrix input.
Apart from my forgetful brain this isn't a deep problem, because one has
other functions, but explicit cross references in the doc may be useful.
In particular (probably incomplete):
- mean(): ref. to meanc() and meanr()
- median(): mention the possibility to use quantile(..., 0.5)
- sum(): This has a meaning for matrix, too. But in addition, make a ref
to sumc() and sumr()
- sd(): ref to sdc() (and noting that sdr() doesn't exist, don't know
why... of course can always work with transposes, but that would also
hold for the other functions which we have anyway)
- max() and min(): ref to maxc(), maxr(), minc(), minr()
Should I create a tracker ticket?
thanks,
sven
6 years, 2 months
MPI issue
by Marcin Błażejowski
Hi,
why this code:
<hansl>
set echo off
mpi
matrix FOO
if $mpirank == 0
FOO = ones(3,1)
endif
mpibcast(&FOO)
eval $mpirank * FOO
end mpi
</hansl>
in most cases produces an error? (MPI_ABORT was invoked on rank...)
I use current git version + OpenMPI 2.1.1-7 on Debian 64.
--
Marcin Błażejowski
6 years, 3 months
script editor: name of gretl instance & external change detection
by Schaff, Frederik
Some suggestions,
it would be nice if the script editor would provide in its header the name of the gretl instance it belongs to. I sometimes have multiple instances open... The same accounts for other gretl windows, I guess.
Also, because I often work on scripts within gretls editor (auto completion, highlighting, help, etc.) but also and at the same time with another editor (PSPad) in order to use macros and better search&exchange abilities, it would be nice if the script editor would check for external changes and report this (something like "external change detected, do you want to update the script to the external version?"). An optional "auto update" option would also be nice to have.
Best
Frederik
6 years, 3 months
xtab and accessors
by A. T.
Dear all,
for an update and simplification of the FEP package I would to replace a
user-own function by xtab. However, xtab lacks currently a few features
for using it within a function:
1) accessor for p-values and test-statistics; in my case, for instance,
I just need information about Pearson's chi^2-test.
2) --silent option
Is there a way to access these statistics somehow?
Here is an illustration:
<hansl>
set verbose off
open denmark.gdt -q
series mup = (diff(LRM)>0)
series yup = (diff(LRY)>0)
list L = mup yup
xtab L
eval $pvalue
eval $test
</hansl>
Thanks,
Artur
6 years, 3 months
