determining the members' types in a bundle
by Sven Schreiber
Hi,
I needed to check whether a bundle contains a certain gretl object type,
so I put together a fairly general but straightforward function that
counts all the various types.
Comments welcome; in particular whether this should go into the "extra"
addon. Also, do you like the return format or do you have a better idea?
thanks
sven
--
<hansl>
set verbose off
function matrix bundle_member_types (const bundle b)
# Checks the types of the members of b and counts their occurrences.
# Returns a vector with 12 rows, holding the contained number of
members
# of the possible types in the order corresponding to the inbundle()
# function:
#
# 1. scalar, 2. series, 3. matrix, 4. string, 5. bundle,
# 6. array, 7. list.
#
# Since an 'array' can be of various sub-types, the rows 8-12
# hold the numbers of those sub-types:
# 8. matrices, 9. bundles, 10. strings, 11. lists, 12. arrays.
#
# Therefore the sum of rows 8-12 equals the number in 6.
# init
matrix out = zeros(12)
rnameset(out, defarray("scalar","series","matrix","string","bundle", \
"array", \
"list", \
"matrices","bundles","strings","lists","arrays"))
# check all the members
if nelem(b)
keys = getkeys(b)
loop foreach i keys
type = inbundle(b, "$i") # should be non-zero by construction
out[type]++
if type == 6 # array
string arraytype = typename(b["$i"])
if arraytype == "matrices"
out[8]++
elif arraytype == "bundles"
out[9]++
elif arraytype == "strings"
out[10]++
elif arraytype == "lists"
out[11]++
elif arraytype == "arrays"
out[12]++
else
print arraytype
funcerr "shouldn't happen"
endif
endif
endloop
endif
# quick cross-check
errorif(out[6] != sum(out[8:12]), "array counts don't match")
return out
end function
# test case:
open denmark --quiet
var 2 LRM LRY IBO --silent
eval bundle_member_types($system)
eval $system
</hansl>
1 year, 2 months
bcheck() with empty optional input
by Sven Schreiber
Hi function writers,
there's a slight problem with the bcheck() function, see this example:
<hansl>
function void bcheckcheck (bundle b[null])
bundle targ = _()
eval bcheck(&targ, b) # error: 2nd arg is empty
end function
bcheckcheck()
</hansl>
The point is that the main purpose of bcheck is to handle a bundle with
options supplied by the user (here: "b"). So if the user is happy with
the defaults and doesn't supply such a bundle, I'd argue that bcheck
should simply accept that and do nothing.
I'm aware that the pass-through of a null value for the function
argument b is recent (gretl 2023b, AFAIK); so I guess that bcheck()
simply has to be adjusted to the new situation.
thanks
sven
1 year, 2 months
$jvbeta with restrictions
by Sven Schreiber
Hi,
this is about VECM details at the scripting level. Consider the example
at the bottom of this message. Typically $jvbeta (or equivalently
$system.vecm_info.Bvar) has as many rows/cols as the number of free
long-run parameters. However, this seems to change when additional
(over-identifying) restrictions are imposed. Is this a bug or a feature?
And BTW, as a side note or for future reference: $system.vecm_info.Bse
(having the same shape as Beta and showing the standard errors) works
fine with additional restrictions. Another remark: Some members of the
sub-bundle $system.vecm_info are only included when non-empty, such as
rlist, xlist, and also $jvbeta. I'm just stating this as a fact, so in
general one would have to check with exists() or inbundle() whether
they're there, instead of checking with nelem() or so.
thanks
sven
-------
<hansl>
open denmark
vecm 2 2 LRM LRY IBO ; null ; IDE # IDE is restricted exog.
eval $jvbeta # gives 4 x 4, corresponding to free params in beta
restrict
b[1,4] = 0 # non-normalization additional restriction
# so only 3 free params remaining
b[1,1] = 1
b[1,2] = 0
b[2,1] = 0
b[2,2] = 1
end restrict --full
eval $jvbeta # gives 8 x 8, with many zeros
# and 9 = 3 * 3 non-zero (symmetric) entries
eval $system.vecm_info.Bvar # the same, expected (kind of)
</hansl>
1 year, 2 months
corrgm, pergm, qlrtest, xcorrgm, and --outbuf
by Sven Schreiber
Hi everybody,
this is in the batch mode context, executing a hansl script.
A problem with 'corrgm' is that it only produces a real plot (not a
textplot) when the --plot=display option is given; but this is
incompatible with the --outbuf option. If you suppress --plot=display,
then you get a textplot and nothing in your output buffer. Same with
'xcorrgm'.
And similarly with 'pergm'. To get a plot at all, --plot=display is
needed, and again --outbuf is not compatible. ... and 'qlrtest' ...
So how can the --outbuf option actually be used? Presumably by allowing
it to coexist with --plot=display, or perhaps by introducing a new
variant --plot=buffer to be used together with --outbuf=mystring ?
Interestingly, there is _no_ such problem with 'leverage', although the
--plot option appears to work the same way.
thanks
sven
1 year, 2 months
panel sample restriction weirdness with dummy
by Sven Schreiber
Hi again,
I've stumbled over a certain behavior with panel data handling, which
could perhaps be a bug. However, it turned out that when I closed and
restarted gretl, the problem went away. It looks as if it could be
relevant that the panel datafile is a subset that was saved as a gdt
file as the result of earlier manipulation, and continuing to work with
the reduced dataset without starting a new gretl session. My suspicion
is that gretl wasn't able to fully and cleanly switch over to the
reduced dataset that was created and retained.
I know that the problem is therefore quite subtle and probably not
directly reproducible. Nevertheless, let me show below what happened in
the console. Maybe it's still useful for something.
thanks
sven
-----
The dataset is monthly in the time dimension and recognized as such by
gretl, n=1..435 and t=2023:01..2023:12. (N*T = 5220) Missings are
present somewhere in most of the included variables.
? smpl full
Voller Datenbereich: 1:01 - 435:12 (n = 5220) # correct and expected
? =isdummy(ichk)
5208 # 'ichk' has 5220-5208 = 12 zeros, namely
for all 12 months of unit 205, so correct
? smpl ichk --dummy
Voller Datensatz: 5220 Beobachtungen
Aktuelle Stichprobe: 1:01 - 372:12 (n = 4464) # ???? why are almost 800
obs discarded ???
? smpl full
Voller Datenbereich: 1:01 - 435:12 (n = 5220) # going back to full
sample to try again
? smpl ichk==1 --restrict # this formulation should be equivalent to
the --dummy option above
Voller Datensatz: 5220 Beobachtungen
Aktuelle Stichprobe: 1:01 - 434:12 (n = 5208) # expected sample
restriction, one unit with 12 months removed
? smpl full
Voller Datenbereich: 1:01 - 435:12 (n = 5220)
? =sum(missing(ichk)) # indeed, the dummy variable ichk has only 0 and
1, no missings
0
1 year, 3 months
Creation of a Pull Request (Merge Request)
by Hélio Guilherme
Dear Professors :)
a.k.a. Gretl development team.
At request from Artut Tarassow, I have prepared a GitHub Actions
configuration, that gets the tests from another repository at Sourceforge,
named *workspace*, starts a Ubuntu virtual machine, compiles, installs and
runs gretl-gui, and then runs those tests.
This works fine in GitHub, but since the *gretl-project*, managed by Artur,
is a mirror of the original project at Sourceforge, he thought it should
not be divergent from the original, so the Pull Request I made must be made
to the original project. This is the usual way on GitHub, but on
Sourceforge I did not manage to have a *Merge Request* done. I can push my
changes directly, but I want to explain what they are, or have one of you
do it.
I used the command:
git request-pull 2897d39e0bdf1b0560d7c30adb9b7aa94322e9d4
https://github.com/HelioGuilherme66/gretl master:test-actions
Which outputted:
The following changes since commit 2897d39e0bdf1b0560d7c30adb9b7aa94322e9d4:
Merge branch 'master' of ssh://git.code.sf.net/p/gretl/git (2024-01-22
21:52:15 +0000)
are available in the Git repository at:
https://github.com/HelioGuilherme66/gretl test-actions
for you to fetch changes up to 2897d39e0bdf1b0560d7c30adb9b7aa94322e9d4:
Merge branch 'master' of ssh://git.code.sf.net/p/gretl/git (2024-01-22
21:52:15 +0000)
----------------------------------------------------------------
About the changes:
- a new configuration for GitHub Actions is created, the workflow,
build_and_test.
- a submodule is created, the directory workspace at the root of the
project.
-- This is a "copy" of the other Sourceforge project, named workspace,
which contains the tests.
-- This directory can be updated with the command:
git submodule update
(but you don't need to, because it is updated in the workflow before
running the tests.)
- my changes also include a file for Mend - Whitesource vulnerability
scans.
You can see the results of GitHub Actions here:
https://github.com/HelioGuilherme66/gretl/actions/runs/7601929575/job/207...
1 year, 3 months
Variable naming bug
by Sven Schreiber
Hi,
here are my steps to reproduce the bug:
0. have a dataset open
1. choose Data / Edit values
2. Click on the "add" (= "+") button, choose "add variable"
3. You get a window to enter the new name; enter something with a single
underscore, e.g. "hey_ho"
4. Click on the accept button (= tick mark; you can also enter obs
values if you like)
5. In the main window with the variable list, the new variable appears
with a duplicated underscore, "hey__ho".
This is with the Jan 4th snapshot.
thanks
sven
1 year, 3 months
(recession) bars in plots broken with annual data?
by Sven Schreiber
Hello once more,
I was trying to get some shaded bars similar to recession bars with the
usual plotting GUI apparatus, but in the context of annual data. I
created pure text files with pairs of dates (years) as instructed; the
contents is like this:
2015 2016
2018 2019
2021 2022
Gretl did not accept this, however, saying the format specification
isn't met.
Then I thought the years could be mistaken for plain obs numbers, so I
tried the index numbers instead (the dataset has 11 obs):
3 4
6 7
9 10
Same error message.
Is the "bars" facility perhaps not really hooked up or supported for
annual data?
thanks
sven
1 year, 3 months
Right of mat2list() to overwrite series values
by Artur T.
Hi all,
I am not sure whether the following is actually intended or not. The
help does not mention any limits, though.
For a project, I stumbled over the following:
1. Create a matrix of residuals with NAs as initial values.
2. Name the columns of the matrix.
3. Store the columns of the matrix as series using the mat2list() function.
In my case, I did not pass any prefix as a 2nd optional argument to
mat2list(). The names of the matrix columns are the same as _already_
existing series. This implies that the application of mat2list()
over-writes existing series values. It took me a while to understand
what's going on and where the error in my code is.
Questions:
Is it intended (the help does not state anything explicitly) that
mat2list() is allowed to overwrite values of some existing series?
If so, I think it's useful to provide a warning for the user, stating
that values of some series are over-written. What do you think?
Here is an example:
<hansl>
set verbose off
clear
open denmark -q
list L = dataset
scalar popt = 4
var popt L --silent
# Store residuals
## take into account the NA values for the initial obs.
smpl +popt ;
matrix uhat = $uhat
## name the residuals equal to the original input series
cnameset(uhat, varnames(L))
## add the named residuals to the dataset
list Comps = mat2list(uhat)
smpl full
# as can be seen: the residuals and original series are mingled
print Comps -o --range=1:10
</hansl>
Thanks
Artur
1 year, 3 months
Since when (gretl version) is pass-through of null arguments supported?
by Sven Schreiber
Hi function writing experts,
in the context of writing (or moderating) function packages I'm
wondering when exactly has it become possible to pass through a null
argument to a called sub-function?
Here's what I mean (adapted from an example by Allin):
<hansl>
function scalar f2 (bundle b[null])
return 0
end function
function scalar f1 (bundle b[null])
eval exists(b)
return f2(b) # currently working even if !exists(b)
end function
# in main (or in some other function)
eval f1()
</hansl>
This is tested and working with a recent snapshot.
However, before the year 2023 (I think) the example above would yield an
error, because inside the f1 function the object b wouldn't be defined
and couldn't be directly passed on to f2.
I checked gretl's changelog and couldn't find a related entry, but I
know we had some discussions (partly off-list) in 2023 about it.
So assuming that this behavior is here to stay, the question is, which
gretl version is the minimal one to support it? I'm guessing 2023b or 2023c.
thanks
sven
1 year, 3 months