I'm wondering what the value added of 'inbundle' over 'exists' is. In
principle both check for the existence of an object and return a type
code if yes.
I know that currently where inbundle(b, "m") returns 0 because m isn't
there, exists(b.m) instead yields an error. But I guess that could be
changed if wanted.
And vice versa: inbundle(a, "x") yields an error if there is no bundle
a, whereas exists(a.x) just returns 0. But are those differences really
by design or just by historical coincidence?
I've detected a weird gretl behaviour when trying to apply the "foreach"
loop type over vector entries. Loop index "i" is printed very round but
the printf-command in the loop-block is only shown at the very last
iteration for the very first iteration.
This is using latest git on Ubuntu 19.10 -- but I think I've observed
this already before but initially thought I am doing something wrong.
set verbose off
open grunfeld -p -q
matrix id = seq(1,3)'
loop foreach i id -q
eval $i # shown every iteration
smpl firm == i --restrict
# shown up only at the very last iteration for the very first iteration
printf "\n%.0f -- %d", i, min(firm)
here are some thoughts about a next round of updating 'extra'. Reminder:
"The extra package (a collection of various convenience functions for
hansl programming)". It comes as an add-on which means it is
automatically shipped with each gretl installation. All items including
their names and so on are open for discussion.
1) drawnormwis(): This function does a random draw from
Normal-inverse-Wishart distributions for Bayesian stuff and currently
exists hidden in the SVAR addon (see
It could go in "as is", unless somebody has suggestions or ideas.
2) multiplot(): I'm attaching an unfinished but working prototype. Many
many things could be added here, this is a bit like Pandora's box (or
the work of Sisyphus?). But maybe having _something_ is better than
nothing? Feedback please!
3) fill() or fill3D() or whatever: Would be the inverse of drill(), i.e.
“shoves” a 1-dim vector with N elements
into an N-element matrices array (in each i,j position), so in the hole
left by drill(), so to speak. Would be easy to arrange, but is there
really a need?
prompted by the question on the users list it occurred to me that it
should be possible to save the cointegration results from the VECM
window, which currently doesn't seem to be enabled.
I found a small bug today. The series meta-information "graph-name" is
not considered in a factorized boxplot. This is with latest git version
using Ubuntu 19.10.
set verbose off
open grunfeld.gdt -q -p
function void foo (const series y, const series factor)
string graph_name_y = sprintf("%s", argname(y))
setinfo y --graph-name=@graph_name_y
boxplot y factor --factorized --output=display # 'y' instead of
boxplot y --output=display # 'foo' mentioned
series foo = normal()
in a recent exercise I needed to store gzipped-compressed csv files.
Unfortunately the "--gzipped" option of the "store" command is only
supported for the native format. Ok, I wrote a function executing some
shell command compressing the files. However, I am wondering whether we
could have also the compression supported for csv files.
Some more background: I had to store _many_ csv files, and to upload
these to a HDFS (hadoop) file system. Querying data is done by means of
Apache's HIVE or Impala tools. These work either with csv or gzipped-csv
(among other binary data formats such as Apache's Parquet file).
Unfortunately, files stored in the native binary format are not supported.
I think the string in the following line must still be marked for
gui/menustate.c: sprintf(tmp + 1, "Imported %s", basename);
Do I understand correctly -to do it myself in the future- that it would
have to be replaced with:
perhaps we discussed this before: While it is possible in the GUI
(menus) to define a dummy indicating the currently active sample, it
doesn't seem directly possible to set the sample based on such a dummy.
I had problems explaining to new users why that is.
I know you can go to Sample/restrict by condition and then type
something like mydum==1 in the text field. I also know how to do that in
a script. But wouldn't it be more natural if in Sample/choose range
there was a way to simply pick the dummy variable and use that
Following earlier discussion of this point, in current git and
snapshots I've made quiet operation the default for loops. So you no
longer need to append the --quiet or -q option. However, the option
is still accepted -- and probably will be accepted indefinitely
since it appears in so many existing scripts. If you want more
feedback on what's going on in a loop, use the --verbose (-v)
If anyone sees any bad effects from this change, please let us know!