Two GUI entry points for a package
by Sven Schreiber
Hi,
this is about the issue of having more than one menu entry for a
function package, or (related but slightly different) having one menu
entry but wanting to offer two or more GUI interfaces when calling the
package from the package listing window.
(Currently, if I'm not very much mistaken, either a package has no
gui-main function and thus no menu entry either, and then all public
functions are offered for a choice in the GUI; or when there's a
gui-main function as required for a menu entry, then the other public
functions are scripting-only.)
The whole thought is prompted by the renewed demand for a SVEC(M) GUI
access with the SVAR addon. Extending the current SVAR GUI would not be
good because it is already a little overloaded.
I see two solutions:
1: Using the fact that recently function packages can depend on each
other, simply introduce a formally separate package, say guiSVEC, which
gets its own menu entry and a single public function. When called and
executed, it pulls in the SVAR addon on which it depends, and calls the
appropriate functions from SVAR in the background.
This solution wouldn't require changes in core gretl, AFAICS.
2: Extend gretl's function package apparatus by allowing designated
gui-2, gui-3 etc. public functions with corresponding menu-attachment-2
menu-attachment-3...
Not sure how disruptive such a change would be.
What do you think?
thanks,
sven
5 years, 9 months
The mysterious stack() function
by Sven Schreiber
Hi,
a colleague made me notice the stack() function for handling a specific
case of panel data import in section 4.5 of the guide. I must admit I
have never been aware of that function, and I have one or two questions
here.
First, it does not appear in the function index (Gretl Command Reference
/ Functions proper, or in the built-in function documentation). Is this
an oversight, or is there a deeper reason?
Secondly, it is well documented in the guide section 4.5, but it appears
to be a strange beast: It is not a gretl command (gets function
arguments in parentheses, for example), but there are double-dash
options such as --offset or --length. I don't remember to have seen
something like this in gretl (or hansl) before.
I guess the story here is some path dependence of the early days, but I
wonder if this area could be cleaned up somehow?
thanks,
sven
5 years, 10 months
a bug with global series and user-specified (* series) function
by oleg_komashko＠ukr.net
Dear all,
To reproduce
nulldata 100
set seed 13
series serie = cum(normal())
eval mean(serie)
eval serie[1]
function series sc_sp (series *serie)
return (serie - mean(serie))/sd(serie) + 1
end function
function void funzione(series *serie)
serie = sc_sp(&serie)
comando = "arima 1 0; serie"
@comando -q
end function
funzione(&serie)
eval mean(serie)
eval serie[1]
No non-void function was called from the main script.
but serie become standardized and shifted by one
Oleh
5 years, 11 months
built-in functions and namespace issues
by Allin Cottrell
I'm resuming, after some investigation and updates to the libgretl
code, a discussion that took place not so long ago; see the thread
started by
http://lists.wfu.edu/pipermail/gretl-devel/2018-October/009146.html
The question I'm taking up is: What happens if you (try to) define
an object of some sort with a name that collides with that of a
built-in function? Here are some answers:
* We allow creation of variables (series, matrices, scalars, etc.)
that have the same name as built-in functions. For the most part
this should not lead to ambiguity, since a correctly used function
name must be followed directly by '(' while this character can only
follow a variable name in the case of lags of a series. In light of
the possible ambiguity in the case of series we now issue a warning
(and we try to figure out what's probably intended).
* When a function definition is encountered in a regular hansl
script, we flag an error if it uses the same name as a built-in
function. This has the implication that scripts that run at time t
may fail at time t+k if in the meantime a built-in function has been
added to libgretl, with a name equal to the name of a function in
the script. Maybe this should be revisited at some point.
* Function packages: Up till now the situation has not been very
secure. My testing indicates there have been no collisions to date,
but I guess package writers and libgretl coders must have been
careful and/or lucky -- since packaged functions have been exempt
from namespace checks (other than for inter-package collisions). If
a collision with a built-in function had occurred, the result would
have been that the built-in took priority and the packaged function
was ignored. In today's git that is changed as follows:
(1) We reject public packaged functions that collide with built-ins
and post an error message.
(2) We'll accept private packaged functions that collide with
built-ins, and give the packaged function priority in the context of
functions that belong to the package (only).
Since testing of all current function packages is part of the
routine prior to a release, it should be straightforward to detect
any problems arising under point (1).
Allin
5 years, 11 months
blank in lag spec: strange error message
by Sven Schreiber
Hi,
I'm getting a strange "lag order: second arg must be scalar" error
message in the following script. Notice the (unintended) blank between
the series name "RS" and the lag call "(-1)":
<hansl>
open hendry_jae
series d_short = diff(RS)
series d_long = diff(RL)
c = 0.01
ladung = -1
longrun = 1
series test = RS (-1) # works with the blank
nls d_short = c + ladung * ( RS (-1) - longrun * RL(-1)) # fails with
the blank
params c ladung longrun
end nls
</hansl>
No big deal, obviously, but doesn't help in debugging. This is Nov 23rd
git code base.
cheers,
sven
5 years, 11 months
NLS settings inside arima
by oleg_komashko＠ukr.net
Dear Allin,
It seems while tolerance for Hannan - Rissanen
was resetted, this is not so for models that
require non-linear autoregression:
open AWM.gdt --quiet
logs TFT
arima 3 0 0;1 0 0; TFT --verbose
arima 3 0 0;1 0 0; l_TFT --verbose
produces
? open AWM.gdt --quiet
Read datafile /usr/local/share/gretl/data/misc/AWM.gdt
? logs TFT
Warning: generated missing values
? arima 3 0 0;1 0 0; TFT --verbose
NLS: failed to converge after 1204 iterations
Error executing script: halting
> arima 3 0 0;1 0 0; TFT --verbose
? arima 3 0 0;1 0 0; l_TFT --verbose
NLS: failed to converge after 1200 iterations
Error executing script: halting
> arima 3 0 0;1 0 0; l_TFT --verbose
Oleh
5 years, 11 months
foreign julia: gretl_export in gretl_io.jl doesn't work with julia 1.0.2
by Sven Schreiber
Hi,
the current gretl_io.jl combined with a freshly downloaded julia-1.0.2
provokes the following error:
.... julia-1.0.2/bin/julia exited with status 256
stderr:
ERROR: LoadError: `write` is not supported on non-isbits arrays
Stacktrace:
[1] error(::String) at ./error.jl:33
[2] macro expansion at ./gcutils.jl:86 [inlined]
[3] write(::IOStream, ::Array{Any,2}) at ./io.jl:532
[4] gretl_export(::Array{Any,2}, ::String, ::Int64) at /home/ <...>
/.gretl/gretl_io.jl:35
[5] gretl_export(::Array{Any,2}, ::String) at /home/< ...>
/.gretl/gretl_io.jl:10
Compare this entry in the julia 0.7.0 changelog
(https://docs.julialang.org/en/v0.7.0/NEWS/):
"Calling |write| on non-isbits arrays is deprecated in favor of explicit
loops or |serialize| (#6466
<https://github.com/JuliaLang/julia/issues/6466>)."
So it seems to me that gretl_io.jl needs updating. Which should it be,
explicit loop or serialize?
thanks,
sven
5 years, 11 months
arima initial values when P(L) is close to zero
by oleg_komashko＠ukr.net
Dear Allin,
The file mentioned was attached in one of the recent messages
gretl version 2018d-git
Current session: 2018-11-15 22:29
? set verbose off
Read datafile /home/oleh/gretl/very_bad_data.gdt
'arima 2 1; var1 --x-12-arima' results:
Model 1: ARMA, using observations 1900-1999 (T = 100)
Estimated using X-13-ARIMA (exact ML)
Dependent variable: var1
coefficient std. error z p-value
------------------------------------------------------
const 2.09907 2.62101 0.8009 0.4232
phi_1 0.347239 0.331677 1.047 0.2951
phi_2 0.608396 0.321796 1.891 0.0587 *
theta_1 0.558995 0.345076 1.620 0.1052
Mean dependent var 0.164128 S.D. dependent var 3.069430
Mean of innovations 0.028041 S.D. of innovations 0.975996
Log-likelihood −140.8892 Akaike criterion 291.7784
Compare 'const' and 'Mean dependent var'!
Initial values from failed 'arima 2 1; var1 --verbose':
ARMA initialization: using linear AR model
Iteration 1: loglikelihood = -176.101858631
Parameters: 426.94 0.91245 0.087320 0.00010000
It seems, this is how the figures above were obtained:
Estimate 'ols var1 0 var1(-1 to -2)'
Then (b[1]/(1-sum(b[-1]))|b[-1])' is
426.94 0.91245 0.087320
But P(1), i.e. 1 - sum(b[-1]) = 0.000224941
Naturally, with such an initial constant eventually we get:
Iteration 999: loglikelihood = -145.834755022 (steplength = 1)
Parameters: 339.16 0.43512 0.56488 0.48653
Gradients: -0.0029644 -265.26 -265.19 -0.071660 (norm 8.16e+00)
--- FINAL VALUES:
loglikelihood = -145.828634454 (steplength = 1)
Parameters: 336.15 0.40383 0.59616 0.52404
Gradients: -0.0029303 -2808.7 -2808.0 -0.69924 (norm 2.65e+01)
The convergence criterion was not met
Obviously, it takes a couple of minutes
to change regression_costant/P(1) for mean(y),
or change only when, say P(1)<0.15
Code to reproduce
set verbose off
open very_bad_data.gdt --quiet
printf "\n'arima 2 1; var1 --x-12-arima' results:\n"
outfile mybuf --buffer --quiet
arima 2 1; var1 --x-12-arima
end outfile
smallbuf = substr(mybuf,1,strlen(mybuf)-strlen(strstr(mybuf,"Schwarz criterion")))
print smallbuf
printf "\nCompare 'const' and 'Mean dependent var'!\n"
outfile mybuf --buffer --quiet
catch arima 2 1; var1 --verbose
end outfile
err = $error
smallbuf = substr(mybuf,1,strlen(mybuf)-strlen(strstr(mybuf,"Gradients:")))
endbuf = strstr(mybuf,"Iteration 999:")
printf "\nInitial values from failed 'arima 2 1; var1 --verbose':"
printf "\n%s", smallbuf
printf "\nIt seems, this is how the figures above were obtained:\n"
printf "\nEstimate 'ols var1 0 var1(-1 to -2)'\n"
ols var1 0 var1(-1 to -2) --quiet
b = $coeff
printf "\nThen (b[1]/(1-sum(b[-1]))|b[-1])' is \n\n"
eval (b[1]/(1-sum(b[-1]))|b[-1])'
printf "\nBut P(1), i.e. 1 - sum(b[-1]) = %g\n\n",(1 -sum(b[-1]))
printf "Naturally, with such an initial constant eventually we get:\n\n"
print endbuf
eval errmsg(err)
Oleh
6 years
future of gretl mailing lists
by Allin Cottrell
For over 12 years Wake Forest University has hosted the gretl-devel
and gretl-users lists, using GNU Mailman. I'm now told that they're
going to discontinue Mailman support; we have about 6 weeks to run
before they pull the plug. Their proposed alternative is Google
Groups (GG), and they've set up groups to shadow gretl-devel,
gretl-users and gretl-announce. (I've been emphatic that we need to
preserve the existing archives, and I'm pretty confident that'll
happen OK.)
So we could migrate to GG with (I hope) little difficulty. But maybe
we want to consider alternatives. I have very little experience with
GG so I don't have a sense of how good a replacement they would
provide. One alternative would be to use the Sourceforge mailing
list apparatus, but I wouldn't favour that; I like many things about
SF but IMO their mailing list interface really sucks. And then we've
talked about moving to a "forum" approach in the past; I guess that
should be considered too. Personally I think a forum of some sort
might be a good replacement for the current gretl-users, but I have
a strong preference for a "mailing list" format for devel purposes.
Thoughts?
Allin
6 years
test!
by Allin Cottrell
If this gets through, sorry for the noise. I'm just checking if the
list is accepting posts at present.
Allin
6 years