clean-up of the "Cheat sheet" guide chapter
by Sven Schreiber
Hello everybody,
I'm currently looking at ch. 21 of the guide, "Cheat sheet". I'd propose
the following cleanups (which I could apply if people agree):
section 21.1:
- Time averaging of panel datasets: I think it would be nice to use a
real-world dataset such as grunfeld.gdt instead of having the slightly
distracting code for creation of artificial data.
section 21.2:
- Generating a dummy variable for a specific observation: Instead of
t=="Italy" one can also write obs=="Italy", which may be more intuitive
for cross-sectional data.
- Generating a “subset of values” dummy: Nowadays one could use the
contains() function I think, which would be more readable.
section 21.3:
- Interaction dummies (p. 194 of the A4 guide version from October):
remove the old string-substitution-based code that pre-dates the
interaction operator (^; which is also already mentioned there).
- Realized volatility: Is this example even consistent? It starts by
talking about minutes and hours, but then switches over to seconds and
minutes. Maybe that's part of the clever trick, I don't know... Apart
from that, it seems that another trick in the cheat sheet could be
re-used here, namely "Moving functions for time series".
- Looping over two paired lists: Can't this one be generalized, by using
Lx[i] and Ly[i] instead of y$i and x$i ?
- Cross-validation: Could it be that using some feature of the regls
apparatus or a contributed package (by Artur?) would be more practical
nowadays?
- Is my matrix result broken? - One could now use sum() instead of
sumc(sumr()).
cheers
sven
10 months
levels forecast of log model
by Sven Schreiber
Hi all,
this is the announced follow-up post about the message on the users list
regarding transforming log predictions to levels. Perhaps it might be an
idea to have a little function package that offers this in the context
of an estimated single-equation model.
As an example, take the following estimate and the calculations that
only depend on the $model bundle that should be available for a function
package inside the model window:
<hansl>
open banks91.gdt # not only for time series
series lout = log(Q1)
list lprices = log(deflist(P1,P2,P3))
ols lout const lprices
# post-model calculations
scalar s = $model.sigma
series lyhat = $model.yhat
string lyname = varname($model.ylist)
modtest --normality --quiet
if $pvalue < 0.10
print "Warning: normality assumption is dubious"
endif
series exp_@lyname = exp(lyhat) + exp(s^2) # would have to be the return
value
</hansl>
cheers
sven
10 months
remaining auto-translated argument labels in contributed packages
by Sven Schreiber
Hi,
this concerns the language "mish-mash" in the GUI dialog windows of
contributed function packages, when running in a local language
(non-English). Since contributed packages are not / cannot be translated
like native gretl, last year we decided to try to avoid this in the
sense that gretl should stop applying auto-translations in that context.
What I'm seeing with gretl 2024d is that labels like "dependent
variable" and "exogenous regressors" are still auto-translated. See for
example the StrucTiSM package, or Canova_Hansen. I think there are also
other examples.
Am I missing something, or has the policy change not yet been implemented?
thanks
sven
10 months
foreign block and string-valued series
by Sven Schreiber
Hi,
in applied work with a 'foreign' block where data is sent to R, I had
the case of a string-valued series which was transferred as strings and
then caused hiccups on the R side. I solved the problem by copying on
the gretl side the series to another one, which then --as described in
the guide-- only contains numbers.
However, I'm wondering whether it is an intended feature that the
"gretldata" object in the R context can contain non-number items?
Loosely related observation from working with 'foreign' and getting
errors: after an error occurred inside the block, re-starting the
containing hansl script sometimes then seems to stumble over leftovers
of the previous error. The cleanup of the transfer-to-R temp files is
not sufficient after an error, it seems. Having a "clear" statement at
the top of the script isn't enough, apparently. Doing a separate "clear"
in the console sometimes helps, and sometimes a gretl re-start is
necessary, too.
thanks
sven
10 months, 3 weeks
on the max. iteration settings
by Sven Schreiber
Hi,
this is the companion message to the iteration settings question raised
by Artur. I thought the following questions don't make too much sense on
the users list.
We have "set gmm_maxiter <whatever>" for GMM, we're talking of something
equivalent for 3SLS in the system context, and in section 26.1 of the
gretl user guide it says that for standard MLE the "set bfgs_maxiter
<n>" choice applies. Fine - but...
1) what about the choice of L-BFGS-B through the --lbfgs option to the
mle command block? Is bfgs_maxiter still relevant there?
2) And what if the optimizer is set to Newton-Raphson instead? I can't
see any user-level switch for that.
3)a) Actually, looking at the mle_calculate function in lib/src/nls.c
around line 2683 (--why does MLE live hidden in an "nls" file... ??--),
it looks as if for NL_NEWTON the parameter maxit is hardwired to 100,
and crittol and gradtol are also hardwired. Similarly, for BFGS there's
a maxit setting of 500. So is this stuff hardwired there, or what's the
right way to look at it?
3)b) Note that I'm acknowledging the function BFGS_defaults in
lib/src/gretl_bfgs.c, where the user setting BFGS_MAXITER plays a role.
However, it only seems to be called from specialized routines (arma,
poisson, etc...). Is it also relevant for a generic MLE block
specification at the hansl level? If so, where does this become apparent
in the code?
thanks
sven
11 months
data artefact for added obs
by Sven Schreiber
Hi all,
I just observed the following unwanted behavior; this is with gretl
2024d, but probably not brand new:
- I have a short yearly dataset spanning 2013-2023. (Confidential,
cannot share it here.)
- There are 14 time series in it, and somewhere in the middle is a
binary dummy, although its "discrete" flag in the attributes is _not_
set. Don't know whether that matters.
- Via the menu I add another obs to the dataset, for the year 2024.
- All variables have missings for the new obs, as expected, _except_ the
dummy: it has a (spurious) value 1 for the new obs. This is wrong.
thanks
sven
12 months
