function call within loop fails
by Artur T.
Hi folks,
using latest git under Ubuntu yields a weird error with a loop. The
following definitely used to work in the past but fails now with an
"Data error".
The function get_dynamical_features() simply constructs a list of lags
of some series. I call the function within a loop three times. At the
second iteration it fails (see error message below).
<hansl>
clear
set verbose off
function list get_dynamical_features (const list Dataset,
const bundle Config)
series dx = Dataset.dx
list L = dx(0 to -Config.LAG_LENGTH)
return L
end function
nulldata 10
loop i=1..3
print i
series dx = normal()
bundle B = _(LAG_LENGTH = 2)
list R = get_dynamical_features(dataset, B) # breaks at 2nd iteration
R
endloop
</hansl>
with the error:
<error>
gretl version 2023c-git
Current session: 2023-07-26 14:56
? clear
i = 1.0000000
dx dx_1 dx_2
i = 2.0000000
Data error
*** error in function get_dynamical_features, line 1
> series dx = Dataset.dx
>> list R = get_dynamical_features(dataset, B)
</error>
Any idea what's going on here?
Best
Artur
9 months
MPI (Re: [Gretl-users] Re: gretl 2023b released)
by Sven Schreiber
[moving this to gretl-devel]
Am 21.07.2023 um 20:49 schrieb Cottrell, Allin:
> Ah, no, you still have to install MS-MPI (the DLLs and executables).
> What I updated was the support files involved in the gretl build:
> headers and the "import library".
>
> While I haven't tested very rigorously (and don't really understand
> how this would work), it seems this has speeded up MPI performance on
> Windows quite substantially.
While trying to compare MPI speed on gretl 2023a vs. b, I encountered
something apparently more serious. Consider the attached variant of the
sample script from my johansensmall package. For me it runs fine on
gretl 2022c and 2023b, but fails on the version 2023a in-between. I've
seen the failure both on Win10 and Win11, both 64bit; on Win11 here the
MS-MPI version is 10.1.12498.52, don't know right now about my Win10 setup.
Of course it's good that there's no problem on the current version, but
still it would also be useful to know what caused the problem that only
affects 2023a. Perhaps the attached script should also become part of
the standard test rig. Notice that the original sample script from
johansensmall never fails (or else we would have noticed before
releasing 2023a, I guess).
Oh, does it fail on Linux with 2023a? It's always a bit more difficult
to install an older gretl version on Linux than on Windows...
(BTW, I don't see any speed difference between gretl 2022c and 2023b.)
thanks
sven
9 months
strange (buggy) if-result with NA
by Sven Schreiber
Hi,
this is with a July-3rd snapshot, and what strikes me as quite strange
behavior:
<hansl>
nulldata 20
series check = 0
check[1] = NA
check[10] = 1
loop tau = 1..$nobs
eval check[tau] # first with NA as expected
if check[tau] == 1
print tau # expect only 10, get 1 and 10
endif
endloop
</hansl>
Trying "if NA == 1" on the console (or also "if check[1] == 1") gives an
"indeterminate" error message, which seems correct. Only inside the loop
does it act weirdly.
thanks
sven
9 months, 1 week
gretl crash with omitted arg in hansl function
by Sven Schreiber
Hi,
I'm seeing the following reproducible crash on Windows 10 on a snapshot
from May. (Later I will test on a newer snapshot, but maybe someone can
reproduce this.)
Here's a pretty minimal example:
<hansl-crash>
function matrix f (string name[null])
print "hello"
return I(2)
end function
f()
f("aha")
</hansl-crash>
Note that it does _not_ crash if the call "f()" is written as "f(null)".
thanks
sven
9 months, 1 week
search anomalies in a script window on Windows
by Sven Schreiber
Hi,
I have a concrete example about how repeated searching in a script
window shows strange behavior at least on Windows (perhaps because of
GTK2?).
Let's consider the code view of the ParMA package in the GUI program.
This has 2095 lines, and let me search for the word "gnuplot". This
occurs three times, on lines 1367, 1373, and 1379. Let's refer to them
as 1,2,3.
I'm observing different behavior depending on whether I hit the Enter
key repeatedly in the search field or whether I click on the looking
glass symbol with the mouse several times. With the keyboard I get the
expected result, namely highlighting of the found terms in the right
order (123123123123...).
With the mouse, I'm sometimes seeing orderings like 1,2,1, (3 missing),
or 1,3 (2 missing). Not every time, probably not even most of the time,
but often enough.
So is this a GTK bug, and if so, GTK2 only? Or some subtlety in the way
that gretl does the respective call?
thanks
sven
9 months, 2 weeks
panel restriction trouble
by Sven Schreiber
Hello panel devotees,
I believe I'm seeing a bug in cumulated sample restrictions in the panel
context. Before I can set up a minimal example, let me describe
hopefully in enough detail what I'm doing, what's failing, which
workaround exists, and so on. I can't supply the dataset (yet) because
it's big.
The full data is structured and recognized by gretl as follows (I
believe the translated German terms are self-explanatory in this context):
Voller Datenbereich: 1:001 - 5860:900 (n = 5274000)
This is monthly, in general heavily unbalanced, the index variables
stemming from $unit and $obsdate are "stationindex" and "iso" (for ISO
date format).
For certain data cleaning reasons I'm first applying the following
restriction:
(1) smpl STATIONS_ID==291 --restrict --replace
which gives me:
Voller Datensatz: 5274000 Beobachtungen
Aktuelle Stichprobe: 1288 Beobachtungen
So far, so good. Then I want to keep only those obs where a certain
variable "temp" is non-missing, so I do:
(2) smpl ok(temp) --restrict
which then yields:
Voller Datensatz: 5274000 Beobachtungen
Aktuelle Stichprobe: 1:001 - 2:156 (n = 312)
Notice that gretl by itself figured out that this subsample has a valid
and feasible panel structure, I didn't tell it that. Does this side
effect matter? I don't know.
At this point let me demonstrate that there are no missings in this
subsample; in the console, asking for "=sum(missing(dataset))" yields 0.
Finally I want to retain only the most recent time period, and since
"iso" is my time variable, I try to apply this restriction:
(3) smpl iso==max(iso) --restrict
In theory there should be at least one observation where any given
variable takes on its own max (and in fact in this case there are two
such obs) -- however, now I'm getting an error message:
"No obs would be left!" (retranslated)
This can't be true, can it? So I tried the following workaround before
getting to step (3), i.e. starting from scratch and applying
restrictions (1) and (2), then I create a helper series:
series checkiso = iso==max(iso)
And indeed, "=sum(checkiso)" gives me the correct answer 2. Now I try
the equivalent workaround restriction:
(3b) smpl checkiso --restrict
... and it works nicely, as expected, leaving only two obs in the active
sample!
So why does step (3) not work? I believe it's a bug, but maybe I'm
missing something.
Ah, one more remark: For other values in the step-(1) restriction I'm
seeing that there won't be a recognized panel dataset after step (2),
and apparently in those case there is no problem! That's why I mentioned
it above, maybe it's relevant.
Sorry for a long message, I hope I was clear enough.
thanks
sven
9 months, 2 weeks
problem with large gdtb panel datafile and index variables
by Sven Schreiber
Hello once more,
I'm seeing a problem handling a fairly large panel dataset in the GUI.
It started with a ~200MB binary gdtb file that was a recognized panel,
with index variables "iso" (time, iso dates) and "STATIONS_ID".
This had lots of unneeded obs with mostly missings, so I saved a reduced
version of the dataset (after "smpl --no-all-missing <somelist>"),
yielding a file with about 100MB. As expected (?), the official panel
structure was lost there, so I wanted to re-instate it, using the nice
GUI dataset structure tool. Basically, this ended up in a non-responsive
gretl which had to be killed by the OS. (I waited several minutes before
doing that.)
In contrast, doing "setobs STATIONS_ID iso --panel-vars" in the console
worked quickly. (I only had to manually re-add the panel time
information, which was suboptimal, but not a real problem.)
Maybe worth mentioning, the dataset is hugely unbalanced, which also
affects the STATIONS_ID index variable, I believe. But if that were
important, it's not clear why it works in the console...
thanks
sven
9 months, 2 weeks
strange error window after Enter on the console
by Sven Schreiber
Hi,
I'm attaching an error window screenshot I'm getting with the July 3rd
snapshot on Win11. This happens when hitting Enter (Return) on the
(swallowed) console without any other input character.
When I re-start gretl and immediately hit Return in the empty console,
I'm getting a similar window, but without the non-printable character
before the colon (:), there's just nothing there instead before the colon.
Then I de-activate the swallowed console, with the result:
"p4oju<non-printable>: Invalid argument"
The "invalid arg" is of course not wrong, but wouldn't it make more
sense to simply do nothing and move to the next prompt, like in a bash
shell?
Apart from that, judging from current git I'm not sure why the message
is in English and not translated; has something happened there since
July 3rd? Or I'm overlooking something.
cheers
sven
9 months, 2 weeks
coint2 leftover?
by Sven Schreiber
Hi,
I've noticed in gui/gretlmain.xml that in some "action" field for the
menus it still says "coint2". I know coint2 is still an accepted alias
for the "johansen" command name introduced two years ago, but perhaps
this should be changed to "johansen" as well? Not sure about the internals.
thanks
sven
9 months, 2 weeks