different eigenvalue error handling for non-numeric input
by Sven Schreiber
Hi,
consider this with gretl 2025a:
<console>
? matrix hello = {1/0} # to get invalid input
? = eigensym(hello)
Not a Number geschah bei Berechnung
? = eigen(hello)
1.#INF
? = svd(hello)
nan
</console>
So we have everything: a hard-stopping error, some IEEE code (?), and a
gretl code. Plus, with a 6x6 matrix input I also saw that eigen() spat
out a "Data error".
I think it would be good if this could be a little harmonized, no?
thanks
sven
1 month, 2 weeks
dbnomics w/o open dataset
by Sven Schreiber
Hi all,
just a quick note: running an dbnomics query ("data ...") without an
active dataset doesn't result in an error (should it?), but it seems to
confuse gretl afterwards.
cheers
sven
2 months, 2 weeks
regls and missings in the middle
by Sven Schreiber
Hi all,
it looks as if regls (Lasso...) isn't checking for missings that happen
somewhere in the middle of the data. Implicitly this is acknowledged by
comments in the example code snippets in the regls help document
("without missing values..." etc.). I just saw some internal data errors
happening because of that. I guess it would be good if regls checked for
such missings and then fails more gracefully.
This is with gretl 2025a.
thanks
sven
5 months, 1 week
crash with a malformed gfn file
by Sven Schreiber
Hi,
when opening a potential new version of somebody's package as a gfn
file, gretl crashed on me (repeatedly) when trying to view the code.
Accessing the help text worked, though. Running the sample script
yielded a data error. I imagine the gfn is faulty (might not have been
created with gretl from scratch, but edited manually), but as always, it
shouldn't crash.
Actually, right now it crashed already when I right-clicked on the
corresponding entry in the package list window to call up the context
menu, after doing the two previous things above (help text, sample script).
cheers
sven
5 months, 2 weeks
weird list creation behavior in package GUI (model window context)
by Sven Schreiber
Hi all,
sorry, this is going to be long and a bit involved. While working on a
package, I encountered some weirdness when creating new gretl list
objects off of a $model coming from a GUI model window after doing OLS.
I do have a stripped-down package test.gfn which I'm attaching for
illustration.
* Technical aim here: Inside the GUI function (here: GUI_uniFCboot)
which is run from the Analysis menu of the OLS model window, I want to
look at the regressors $model.xlist and I want to focus only on those
terms that are exogenous (not lagged endogenous, and also not the constant).
* Example:
1) Install somewhere the test.gfn package, attach it to the menu, load
the denmark dataset, and in the GUI regress LRM on IBO, const, and two
own lags.
2) Go to the new menu entry Analysis/testtesttest, choose horizon=2 (but
that shouldn't matter) and hit OK.
3) I get my debug printout: "We shouldn't have any lags remaining in
here: IBO,LRM_1,LRM_2", which obviously *does* contain the LRM lags.
* Background: In the function, I'm trying to create a sub-list by doing
(where 'mod' is a copy of $model):
list Lexo = mod.xlist - lags(mod.maxlag, mod.ylist) - const # all but
endo-lags and const
and then I'm printing out varname(Lexo), with the result above. Now I
can theoretically imagine some reasons why my approach doesn't work,
related to the list ID numbers inside bundles and functions and so on.
* HOWEVER, the real weirdness comes when I add/uncomment the following
lines right before the Lexo creation, namely:
bundle br = rhslags($model) # especially this line seems to make a
difference # although it shouldn't!
print br.ylagnames
(The package version with these lines active is enclosed as test2.gfn.)
-- And then everything works, i.e., there aren't any lagged endogenous
terms left in the subsequent Lexo creation; result: "We shouldn't have
any lags remaining in here: IBO" !
The point here is that the call to the private function rhslags() should
be completely redundant and without any effect, shouldn't it? The return
bundle br isn't used here, and there are no pointers involved. Instead
it magically makes it so that everything falls into place, at least in
this example.
What's behind all this? Some gretl bug? Or just further mystery with
bundled series and lists? And concretely, how can I successfully remove
from $model.xlist the lag terms in this context without doing black magic?
This is with gretl 2025a on Windows 11.
thanks a lot for reading until the end
sven
6 months
a very basic test of gretl4py
by Sven Schreiber
Hi all, especially Marcin of course,
I just wanted to report how the setup of gretl4py worked for me in
practice, nothing special. This is an old computer (Sandybridge 4-core)
running Windows 10.
So first I did a fresh install of the latest Miniconda variant of the
Anaconda Python distribution. This has Python 3.12, I think. Right after
installation I updated conda inside Miniconda, and then I proceeded
following the instructions on
https://gretl.sourceforge.net/gretl4py.html - meaning I installed numpy
and tabulate within Miniconda in the standard way. (Using the "Anaconda
PowerShell Prompt"; numpy also pulled in the Intel MKL with >150MB, but
hey...) Earlier I had also installed gretl 2025a.
Then I downloaded gretl4py.zip and extracted it somewhere. In the
Anaconda prompt I navigated to where I had extracted it and ran
"python.exe install.py" successfully. Finally I did as described on the
web page and ran estimators.py inside the demo dir, also successfully.
So everything went fine so far - I wasn't entirely sure whether the
standard Python distro was needed, but Mini/Anaconda seems to work OK.
The only thing is that the demo output was so long that I couldn't
scroll back all the way in the console (prompt) window - I only got
until Model 2 and couldn't see Model 1. I'm sure the console settings
could be adjusted somewhere, but as I said, I wanted to test as a
standard user with default settings.
thanks
sven
6 months
new euro area AWM data
by Sven Schreiber
Hi everybody,
with a little delay I've become aware of some work that updates the good
old area-wide model dataset. In gretl we currently ship AWM, AWM17, and
AWM18, and then it wasn't updated anymore at the source. Now there's
˙Ipek and Kısacıko˘glu who offer new data, see
https://mahmuts.bilkent.edu.tr/ and
https://drive.google.com/file/d/1WRyq4iX3KIEFogV_xESpBtdrT7cQLk3c/view?us....
I wonder whether we should ask them if we can convert their Excel file
and ship it with gretl in the future. The "downside" is that they want
to update it regularly, so the question is whether it's too much of a
moving target; plus I just tested the import into gretl, and it works
flawlessy, you only need to tell gretl to use the second (out of three)
sheets in the workfile. So in that sense it could be argued that there
isn't much value added in providing it in gretl format. (Well, from
their dataset you don't get the series descriptions, so that might be
some value added.)
cheers
sven
6 months, 1 week