the doc says that $sysinfo.os gives "linux", "osx", "windows" or other
as a piece of introspection. An older accessor is $windows, which
returns 0 or 1.
So the $windows accessor appears redundant and doesn't cover the Mac -
should it perhaps be discouraged for new hansl scripts? (I guess
$sysinfo.os has been around long enough such that there are no real
compatibility issues.) At least I guess the doc for $windows should also
point to $sysinfo.os.
As a further minor point, AFAIK MacOS is not named "OS X" anymore. But
obviously, changing the return string to "macos" or something like that
would raise backwards compatibility problems. Again, maybe the easiest
thing is simply to add a note to the doc?
the following happened with 2021d: I open denmark.gdt and estimate a toy
model in the GUI. Then I go to Analysis/Forecasts in the model window.
Gretl complains about unavailable out-of-sample obs. I dismiss this
message window and I switch to the main window and add 5 obs. Switching
back to the still open model window I attempt forecasting again. -> But
I get the same complaint, which now is no longer true.
after the Ubuntu question on the users list it occurred to me that a new
long-term support version of Ubuntu is coming up in April 2022.
The feature freeze seems to be in February. Not sure if there is another
relevant deadline for packages like gretl before that, but I think we
should keep that in mind, for example in terms of potential new hansl
language features that might be needed for function packages later.
it occurred to me that the new entry in the help menu says "Linear
programming", whereas the document is called "gretl + lpsolve". This is
in contrast to "gretl + MPI". Of course this isn't very important, but
some harmonization would still be good. No strong preference about which
way to go, though.
Related to that, maybe it could help to explain the abbreviations in the
menus, like "gretl + MPI (parallelization)" or "gretl + SVM (support
Allin, not sure if you're already finished with the business of
improving the handling of time and dates in the panel context, but on
current git I'm seeing the following:
- create new panel dataset with daily time frequency: when I enter a
5-digit pseudo-year, gretl silently ignores the input. I would expect
some kind of error message.
- Again panel dataset with daily time: Trying out the new sample
selection dialog, the time periods are apparently shown in epoch
I just had to debug a script which failed with a generic "data error".
Gretl correctly indicated the failing line "k++", but it took me a while
to find out that k was undefined at that point. If the error message had
been "unknown object 'k'", it would have been much easier.
Hi, some random-but-inspired-by-real-work thoughts about gretl's lists:
-- The fact that you can use index ranges with lists doesn't seem to be
documented, or is it? For example, a little bit to my amazement, this works:
list L = LRM LRY IBO
ols L const L[2 : nelem(L)]
(And in the future I guess even with "end" in place of "nelem(L)".)
Maybe it should be mentioned in the list chapter.
-- What isn't possible yet is to operate on all list elements at once,
without using an explicit loop. What I mean is, wouldn't it be nice if
one could do something like:
list L2 = L .- x # not possible
to do the equivalent of the following loop code:
list L2 = null
loop foreach i L
L2 += $i - x
(I guess there's an overlap with the feature request to have a new
apply() function for generic elementwise operation. But I think using
the dot-operators would feel very natural.)
Just some ideas - thanks
Hi Artur (and everybody who's interested),
I'm trying to leverage your calendar-related package and have some
questions, especially about the function date_to_iso8601. First of all,
it would be useful if the doc explained a little bit more what's
actually supported. Internally the function uses the built-in strptime
and so on, so maybe it would be enough to refer to gretl's function
reference for that.
Then, I'm observing that the result for date_to_iso8601("1984", "%Y")
is: 19831231. Is this a bug? I would have expected 19840101.
Next, my feature request would be to support other date specifications
used by gretl as well, such as for quarterly data things like "1974:3".
(It does work with such monthly specifications, apart from an apparent
bug similar to the one above.) I'm aware that quarterly data isn't
covered by ISO8601.
At the end of this message is a code proposal on how to deal with such
quarterly labels. Your date_to_iso8601 function could perhaps allow a
"Q" code in the date_format argument and do something like this:
if instring(toupper(date_format), "Q")
scalar iso8601 = gretlquarter_to_iso8601(date)
... < existing part of your function>
What do you think?
function scalar gretlquarter_to_iso8601(string date)
# This function only supports quarterly date strings
# as used and accepted by gretl itself;
# basically only patterns like "1999:3" or "1999.3".
errorif(!instring(date, ":") && !instring(date, "."), \
"not a recognized quarterly date string")
# harmonize and check
date = strstrip(strsub(date, ".", ":"))
strings parts = strsplit(date, ":")
errorif(nelem(parts) != 2, "invalid date string input")
# convert (and check)
year = atof(parts)
quarter = atof(parts)
errorif(year < 1000 || year > 9999, "year out of range")
errorif(quarter < 1 || quarter > 4, "quarter out of range")
# construct the ISO output
out = year * 10000 # year
out += ((quarter-1) * 3 + 1) * 100 # first month in quarter
out += 1 # first day in month
# some tests
eval gretlquarter_to_iso8601("20000:1") # wrong
eval gretlquarter_to_iso8601("2000-3") # also wrong
eval gretlquarter_to_iso8601("1901:12") # wrong
I just tested the bash script in our git workspace area
to install 2021d on a few linux boxes, and it worked just fine.
I'd suggest to prepare a tarball containing (a) the script itself (already
marked as executable to save people time) and (b) the readme file and make
it downloadable from the main gretl webpage. I suppose the "Download"
section could be the appropriate place.
What do you think?
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
[actually, it's only one mystery, the rest is missing features...]
I have a panel dataset with 9 groups (countries) and 44 time periods.
The data structure has been set (or refined) with:
setobs 4 1995:1 --panel-time
setobs country --panel-groups
where "country" is a string-valued series with the two-letter ISO codes
for the 9 countries.
Now I'm observing some glitches or a little mysterious outcomes when
calling up various plot options in gretl. (There are no missing data in
the panel, and if it matters, currently I have the comma as decimal
1) Context menu (right click) and then choose "panel plot"; then choose
"joint/groups overlapping": The legend is fine, using the country code
labels. But the x-axis --which should be time-- shows a range from 1 to
2, which I don't understand. Simply a bug? (The same problem occurs for
2) Again context menu, "panel plot", but then choose "joint/groups
sequentially": Now the x-axis has tick marks indicating the groups, but
instead of the string-valued country labels I only get numbers 1 through
9, which is a not wrong, but a bit of a pity.
3) ... then choose "multiple plots in grid": Again group numbers instead
of labels, and on the time axes there is always 1 through 44 (actually,
0-45, but well) instead of the corresponding date labels from the panel
4) ... then choose "boxplots per group" (that's also what I get on
double-clicking the series directly): Like in case (2), group numbers
1-9 on the x-axis instead of the group (country) labels.