Nix package manager a deployment option?
by Sven Schreiber
Hi,
some time ago there were some discussions on whether a Flatpak-style
release of gretl versions might make sense and/or be worth the effort.
Now I've read about another tool: Nix, https://nixos.org/
I don't have any experience with that, but they support Linux and MacOS,
the latter is perhaps interesting for us (gretl). AFAIK Flatpak is
Linux-only (right?).
My --perhaps a little naive-- vision would be that more or less the same
single gretl package release for Nix could run on any (?) Linux distro,
on MacOS, and on Windows' Subsystem for Linux (also graphically since
version 2).
Has anybody already worked with that? Is it doable in practice?
thanks
sven
12 months
was: Re: [Gretl-users] Re: Fwd: Norm of gradient in mle command
by Sven Schreiber
Am 27.10.2023 um 16:08 schrieb Cottrell, Allin:
> On Fri, Oct 27, 2023 at 2:48 AM Riccardo (Jack) Lucchetti
> <p002264(a)staff.univpm.it> wrote:
>> Call b the parameter vector and g the gradient vector, both with n
>> elements. Then the norm is computed as
>>
>> gradnorm = sqrt(abs(b'g)/n)
>>
>> I don't remember where this formula came from, Allin and I worked on
>> this piece of code long ago.
> The gradient norm code was added to gretl_bfgs.c on 2010-01-26. I
> presume there must have been some email discussion at the time but I'm
> afraid I can't find it.
[moving my reply to the devel list, without implying that other replies
need to do the same]
I'll exploit this trigger to say that this is an example why I've
repeatedly said that the gretl source could always use more comments.
At the same time, I'm happy to admit that I think the situation has
gotten better since 2010.
As for the formula --and without having looked at the code or anything
else-- isn't it a bit surprising that the parameter and its gradient are
multiplied? I mean, wouldn't you expect a kind of normalized or scaled
gradient, perhaps something like abs(g'(1./b)) or so? But again, maybe
I'm totally missing the context and this is a stupid remark.
cheers
sven
12 months
regls internal error
by Sven Schreiber
Hi,
this is what I got when I tried to run a totally non-serious arbitrary
specification with regls, where (as it turned out) many (all?) variables
had lots of missings or even only a single valid value:
unbestimmte 'if'-Bedingung
> if sy == 0
*** Fehler in Funktion s_standardize, Zeile 3
> if sy == 0
von Funktion regls aufgerufen
*** Fehler in Funktion regls, Zeile 51
> matrix Y = s_standardize({depvar}, &my, &sy)
Not a big deal, but I guess nevertheless some more internal validity or
soundness checks are needed.
(This is with the latest snapshot.)
thanks
sven
1 year
command log and regls
by Sven Schreiber
Hi all, it seems that a regls (Lasso & co.) estimate that is performed
through the GUI does not show up in the command log. I can understand
the internal technical reasons for that, but I wonder if that's the
unavoidable state of affairs, or whether it's wanted that way.
thanks
sven
1 year
Package GUI strings / translation
by Sven Schreiber
Hi,
for quite a long time we've had the "mish-mash" situation that the GUI
strings of contributed function packages are partially translated; that
is, if the original English string matches something in core gretl, then
it's translated - at least that's how I understand it. The problem is
that almost always you then have a mix of two languages, English and the
currently active one, in the packages' windows.
I think this must be fixed eventually, and here's an idea: What if we
collect somehow automatically the argument label strings of the public
functions of basically all existing packages, and add them to the gretl
source tree to have them systematically translated by gretl's respective
translators. Whether they go into the main .po files or somewhere else,
I don't know, and that's secondary I'd say.
I'm sure there are some complications to be solved, but currently we
don't even try to have a coherent interface there.
thanks
sven
1 year