perhaps this could be interesting at some point: I've noticed that the
'dynr' package for R covers a bunch of Markov switching setups and says
about itself that "All estimation and computations are performed in C".
Perhaps that C code base could be adopted at some point. I couldn't find
any license information in the files, but the package page above says
Certainly not in the short term...
@henrique.coelho <henrique.coelho(a)gmail.com> I did some small changes in
the pt_BR.po file, but I was not able to confirm them.
@cottrell <cottrell(a)wfu.edu> I did try to force the language to Portuguese
Brasil, but never got to see it. Always pt_PT was shown.
[helio@localhos]$ export LANG=pt_BR && gretl
This is Fedora 32.
Hi jack and Allin,
One week ago or so I added an example to the function reference for the
mean() function by manipulating the
"doc/commands/gretl_functions_en.xml" file. Even though newly added
things appear in the gretl function reference correctly, this is not the
case for the online function reference:
How is the synchronisation between the xml and html file ensured? Does
this happen automatically? If not, how to initialize the synchronisation
let's image we have a session with a bundle inside which we known about
that it is a product of some package. If such a bundle was produced
directly by package, it is associated with the creator. But if this
bundle was acuired somehow - let say imported as a XML - it is not. Of
course, I can manually edit the session to make such assiocioation, but
maybe we could add an option for that?
a user just sent me a report on a problem with the RE probit estimator:
if one tries a specification that would lead to perfect prediction in the
pooled specification, the command just aborts instead of dropping the
offending regressor from the list, as it probably should.
The following script exemplifies the problem and suggests a possible
set seed 123
setobs 3 1:1 --stacked-time-series
series x = normal()
series d = uniform() > 0.8
series y = (1 + x + d + normal()) > 0
list X = const x d
# this won't do
# probit y X --random
# this will
probit y X --quiet
list X = $xlist
probit y X --random
It's very unlikely that I'll have time to work on this over the weekend,
but will try to do so on Monday. If you have alternative ideas on how to
handle this, suggestions are welcome!
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
I never really understood the reason why a <print m> shows _all_ values
in case m is a matrix or a series object. However, in case m is a string
array things depend on the length of m: If nelem(m) < 10, the print
command prints all values, otherwise none. Try this:
scalar n = 11
strings S = array(n)
S[i] = sprintf("foo_%d", $i)
print S # no values are shown
print S --range=2:11 # values are shown
This looks inconsistent to me but maybe there are arguments for it which
I can't see. If you agree, I would rather plead for printing per default
all values also for string array objects.
I guess I found a bug in the stringify() function. In the following
example both "x" and "z" are constant integer series taking, for
instance, value 1. In case the length of the string array "S" equals
nobs(series), the mapping is _not_ right. However, in case nelem(S) >
nobs(series) things work ok.
set verbose off
series y = seq(1,3)'
series x = 1
series z = 1
strings S1 = defarray("A", "B", "C")
strings S2 = defarray("A", "B", "C", "D")
scalar err1 = stringify(y, S1)
scalar err2 = stringify(x, S1)
scalar err3 = stringify(z, S2)
print err1 err2 err3
The last print command yields:
index y x z
1 1 A A A
2 2 B B A
3 3 C C A
Obviously, the mapping is not right for x but for z.
This is with 2-days old gretl (git) on Ubuntu 20.04.
prompted by Jack's recent biprobit explanation in the guide I checked
whether the automatically run test is available via $test -- it's not
I know biprobit is not a test but an estimation command. Does that mean
that $test/$pvalue shouldn't be used there? Should there be a new
this is not new (I guess), but I noticed section 31.4 about
"Cointegration tests" in the chapter "Univariate time series models". I
find this unfotunate because how can _co_integration be univariate? I
know that sometimes people refer to a single-equation setup as
univariate but I always thought that was at least sloppy and actually wrong.
So I'd like to move that section into the "Cointegration and VECM"