Dear Allin and Jack,
I think there is a little mistake in chapter 33 of the Gretl's User Guide.
It states that x_t is a (k x 1) matrix on page 273 (the definition is
located in the texte under the equation 33.2) and that x_t is a (T x k)
matrix on page 274.
There's a function I wanted in the context of svm() -- to get all the
keys from a bundle in the form of an array of strings -- and I thought
it might be useful to have it exposed in hansl under the name getkeys.
Could be helpful for function writers, if you're taking in a bunch of
arguments in the form of bundle elements, some of them optional.
The idea is that you can check for mistyping of parameter names, and
hence maybe save a user some puzzlement ("I set X but it didn't have
Trivial illustration follows.
function scalar in_strings_array (const strings S, const string s)
scalar ok = 0
loop i=1..nelem(S) -q
if s == S[i]
ok = 1
function void do_something (const bundle parms)
strings ok_keys = defarray("foo", "bar", "baz")
strings pnames = getkeys(parms)
loop i=1..nelem(pnames) -q
if !in_strings_array(ok_keys, pnames[i])
errstr = sprintf("Unrecognized parameter '%s'", pnames[i])
bundle b = defbundle("foo", 3, "bar", "some text", "bax", I(2))
Here, do_something() accepts a bundled parameter "baz" (implicitly
optional) which has been mistyped as "bax". Instead of "bax" being
silently ignored the result is:
Error message from do_something():
Unrecognized parameter 'bax'
I guess the example invites the idea that inarray() could be a
built-in function for arrays of strings (at least). Any thoughts on
whether that would be worthwhile?
Not so long ago I tightened up on potential trampling of reserved
words in hansl, one effect being that you can no longer define a
variable with the same name as a built-in function.
I now notice that this provokes an error in the gig printout function,
which defines a scalar named "nobs". At first I thought this must be
an error in the reserved-words apparatus (isn't it just "$nobs", with
a dollar, that's reserved?). But on closer inspection I see we also
have a function nobs(), which gives the number of non-missing
observations for its series argument in the current sample range.
Not a terribly useful function, but it's used in a few packages.
So I've (locally) committed a little change in gig, "nobs" -> "T".
This is basically just a heads-up that I/we need to check all packages
carefully for such collisions before the next release. If necessary, I
guess we could create an exception or two on a temporary basis (that
is, for now permit masking of a few little-used function identifiers).
when trying to package a gfn I got the following error message:
Value "stringref" for attribute type of param is not among the
Indeed I have four helper functions that work on an arg like: string *s
The functions work fine, though. Has this simply never been tried in a
package and needs to be added?
This is the latest snapshot I could grab (Feb 24th).
am I right in assuming that the following is supposed to work after a
while ago arbitrary "element-of-nesting" was enabled?
bundle b = null
strings b.ss = defarray("a", "b")
scalar b.a = 2
eval b.ss # works, "a"
eval b["a"] # works, 2
string s = "a"
eval b[s] # works, 2
eval b[b.ss] # fails, complains about wrong [
Oh BTW, I'm expecting to get out the same as for b["a"] (== 2).