latex required for building addons (even though no --enable-build-doc)
by Sven Schreiber
Hi again,
I'm noticing that I cannot build from git without having a Latex
installation, when I want to also build the addons. In other words, the
regular gretl build skips Latex and pdf creation when the configure
option --enable-build-doc is _not_ given, but using
--enable-build-addons fails without Latex.
Not a big deal of course, but on a Debian test system I had to pull in
texlive-latex-recommended, texlive-fonts-recommended,
texlive-latex-extra just because of that, which is easily 1GB in size.
thanks,
sven
5 years, 4 months
new accessor
by Allin Cottrell
Jack and I have recently been working on a new accessor. It's named
"$result" (so far) and it gets you a matrix after execution of
commands that don't have specific accessors of their own but whose
output can reasonably be represented as a matrix.
So far we've implemented this for corr, freq, summary, vif (the BKW
matrix) and xtab (the simple two-variable case only). We have in
mind a few other commands that could benefit from this treatment.
The accessor works a bit like $model, in that each time a supported
command is executed the prior $result matrix (if any) is destroyed
and a new one substituted.
We considered requiring a new option (say, --savemat) to make this
happen (since if the matrix isn't wanted we've wasted some CPU
cycles building it) but our current view is that it's not really
worthwhile.
Allin
5 years, 9 months
string-valued series
by Riccardo (Jack) Lucchetti
Hi all,
I'm working with a panel dataset that includes a few string-valued series,
and I'm finding a few things annoying, so I'm sending this message to the
list with a two-fold purpose: (a) to hear you guys' opinions and see of
there's antything I'm missing and (b) as a reminder to myself to work on
these things as soon as possible.
- when you compute lags of a discrete variable, the "discrete" flag is not
propagated (I think it should); can anyone think of similar cases?
- similar to the above: lagging a string-valued variable does not preserve
labels. Example:
<hansl>
nulldata 6
setobs 1 1 --special-time-series
l = defarray("foo", "bar", "baz")
series x = ceil(uniform()*3)
stringify(x, l)
lags 1 x
print x x_1 -o
</hansl>
produces
<output>
x x_1
1 bar
2 baz 2
3 baz 3
4 foo 3
5 bar 1
6 bar 2
</output>
of course you can do "stringify(x_1, l)", but it's sort of annoying.
- printing out an array of strings requires a loop if it has more than 9
elements. In some cases, this is VERY inconvenient. I see two way to go
around this: either we introduce a "set" variable, which replaces the
hard-wired limit at 10 we have now (something like "set arrayprint 20") or
introduce an option to the print command ("--full" or similar). What do
you guys prefer?
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
5 years, 10 months
Crash when trying to access an element in a nested bundle
by Artur T.
Dear all,
I've attached a json-file and ran the following example using latest git
on ubuntu 18.10. Gretl crashes at some point when trying to access some
element of a nested bundle as you will see.
<hansl>
string wd = "/home/at/git/json_gretl" # adjust path
string jfile = "@wd/ex3.json"
string json_str = readfile(jfile)
B = jsongetb(json_str, "/store/*" ) # all things in store
eval B.store.book[1] # grab 1st of the 4 bundles
# Accessing "price" of the 1st bundle works
eval B.store.book[1].price
# CRASH when accessing the 1st element (price)
eval B.store.book[1][1] # Is this actually a valid accessor?
</hansl>
Best,
Artur
5 years, 10 months
gretlcli termination (crash?) with gnuplot error
by Sven Schreiber
Hi,
the following happened when running the awm.inp example file from the
SVAR addon on a console-only installation (Linux), within a "gretlcli"
session via gretl's 'run' command.
The awm.inp script must fail because it tries to send stuff to gnuplot
with the "display" option. That's understood. Here is some error output:
gnuplot stderr: '01:48:52 PM: Error: Unable to initialize GTK+, is
DISPLAY set properly?
Failed to initialize wxWidgets.
'
Failed command: 'gnuplot -persist "/home/gretlcheck/.gretl/gpttmp.plt"'
However, after that I don't get back to the gretlcli prompt ("?"), but
instead gretl(cli) terminates and I'm at the shell prompt. And I think
that's not right.
This is with current git.
thanks
sven
5 years, 10 months
undefined identifier in non-evaluated code branches
by Sven Schreiber
Hi,
in the changelog I read this:
"Allow use of undefined symbols in the right-hand
operand of "&&": don't flag an error unless theleft-hand
operand evaluates as true."
Which is great! I interpret this as meaning that stuff like
"if exists(hey) && hey == 1"
will be possible even where 'hey' does not exist. This will save a lot
of lines of code and nested if-blocks.
My question: What about ternary operations like:
"ho = exists(hey) ? hey : 0"
Is this covered as well? If it isn't, could it be enabled?
thanks
sven
5 years, 10 months
Screen resolution and gretl window "sharpness"
by Sven Schreiber
Hi,
I have now seen gretl operate on a Laptop with a 1920x1080 resolution on
a fairly small screen, thus high pixel density. Gretl's window and the
fonts in there look noticeably less sharp / more pixelated than other
programs (say, more "native" Windows programs). I suppose this is a GTK
limitation? Or is there something that can be done?
thanks
sven
5 years, 10 months
function execution within if check
by Sven Schreiber
Hi,
here's an example I found slightly unexpected:
<hansl>
function scalar hey(void)
print "do we see this?"
return 1
end function
bundle b = null
if hey() == 1 # no printout from inside hey()
print "oho"
endif
</hansl>
The hey() function is executed alright because the if-clause evaluates
to True. But whatever happens inside the function isn't visible apparently.
Bug or feature?
thanks
sven
5 years, 10 months
signs in equation system restrictions
by Pozdeev, Igor
Hi all,
Behavior of restrictions with patterns like "b[1, 1] + -2*b[2, 1] = 0" is strange. In the following MWE, the restricted coefficients differ by exactly 1.0 when restrictions are defined in the "bugged" way:
open greene13_1.gdt
# set up system
system name="Grunfeld"
equation I_GM const C_GM F_GM
equation I_WE const C_WE F_WE
end system
# restriction w/bug
restrict "Grunfeld"
b[1,1] + -1.0*b[2,1] = 0.0
end restrict
estimate "Grunfeld" method=sur --iterate
# restriction w/o bug
restrict "Grunfeld"
b[1,1] - 1.0*b[2,1] = 0.0
end restrict
estimate "Grunfeld" method=sur -iterate
This a bug or a feature? Thanks for looking into this.
Best,
Igor
Igor Pozdeev
+41786120928
www.igorpozdeev.me<http://www.igorpozdeev.me/>
5 years, 10 months
Re: [Gretl-devel] Gretl-devel Digest, Vol 145, Issue 13
by Clive Nicholas
Your very last line call missed off a dash in the option call to iterate:
# restriction w/o bug
? restrict "Grunfeld"
? b[1,1] - 1.0*b[2,1] = 0.0
? end restrict
Restriction:
b[1,1] - b[2,1] = 0
? estimate "Grunfeld" method=sur --iterate
Equation system, Grunfeld
Estimator: iterated Seemingly Unrelated Regressions
Convergence achieved after 8 iterations
Log-likelihood = -191.162
Equation 1: SUR, using observations 1935-1954 (T = 20)
Dependent variable: I_GM
coefficient std. error t-ratio p-value
--------------------------------------------------------
const 0.905304 7.34529 0.1232 0.9034
C_GM 0.382970 0.0350351 10.93 4.14e-09 ***
F_GM 0.0840394 0.00717758 11.71 1.46e-09 ***
Mean dependent var 608.0200 S.D. dependent var 309.5746
Sum squared resid 160284.7 S.E. of regression 89.52227
R-squared 0.914146 Adjusted R-squared 0.904046
Equation 2: SUR, using observations 1935-1954 (T = 20)
Dependent variable: I_WE
coefficient std. error t-ratio p-value
-------------------------------------------------------
const 0.905304 7.34529 0.1232 0.9034
C_WE 0.0959631 0.0513073 1.870 0.0788 *
F_WE 0.0504019 0.0143477 3.513 0.0027 ***
Mean dependent var 42.89150 S.D. dependent var 19.11019
Sum squared resid 1776.588 S.E. of regression 9.424935
R-squared 0.744287 Adjusted R-squared 0.714204
Cross-equation VCV for residuals
(correlations above the diagonal)
8014.2 (0.186)
157.11 88.829
log determinant = 13.4404
LR test for the specified restrictions:
Restricted log-likelihood = -191.162
Unrestricted log-likelihood = -190.109
Chi-square(1) = 2.10586 [0.1467]
Does that answer your question?
C
On Fri, 22 Feb 2019 at 14:10, <gretl-devel-request(a)lists.wfu.edu> wrote:
> Send Gretl-devel mailing list submissions to
> gretl-devel(a)lists.wfu.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.wfu.edu/mailman/listinfo/gretl-devel
> or, via email, send a message with subject or body 'help' to
> gretl-devel-request(a)lists.wfu.edu
>
> You can reach the person managing the list at
> gretl-devel-owner(a)lists.wfu.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Gretl-devel digest..."
>
>
> Today's Topics:
>
> 1. Screen resolution and gretl window "sharpness" (Sven Schreiber)
> 2. gretlcli termination (crash?) with gnuplot error (Sven Schreiber)
> 3. Re: gretlcli termination (crash?) with gnuplot error
> (Riccardo (Jack) Lucchetti)
> 4. Re: gretlcli termination (crash?) with gnuplot error
> (Sven Schreiber)
> 5. signs in equation system restrictions (Pozdeev, Igor)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 21 Feb 2019 18:09:11 +0100
> From: Sven Schreiber <svetosch(a)gmx.net>
> To: Gretl development <gretl-devel(a)lists.wfu.edu>
> Subject: [Gretl-devel] Screen resolution and gretl window "sharpness"
> Message-ID: <0727e328-f36b-3924-8347-7ae733785895(a)gmx.net>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hi,
> I have now seen gretl operate on a Laptop with a 1920x1080 resolution on
> a fairly small screen, thus high pixel density. Gretl's window and the
> fonts in there look noticeably less sharp / more pixelated than other
> programs (say, more "native" Windows programs). I suppose this is a GTK
> limitation? Or is there something that can be done?
>
> thanks
> sven
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 22 Feb 2019 13:54:57 +0100
> From: Sven Schreiber <svetosch(a)gmx.net>
> To: Gretl development <gretl-devel(a)lists.wfu.edu>
> Subject: [Gretl-devel] gretlcli termination (crash?) with gnuplot
> error
> Message-ID: <265b39ea-5664-571a-6b8b-abe9f978fad6(a)gmx.net>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hi,
>
> the following happened when running the awm.inp example file from the
> SVAR addon on a console-only installation (Linux), within a "gretlcli"
> session via gretl's 'run' command.
>
> The awm.inp script must fail because it tries to send stuff to gnuplot
> with the "display" option. That's understood. Here is some error output:
>
> gnuplot stderr: '01:48:52 PM: Error: Unable to initialize GTK+, is
> DISPLAY set properly?
> Failed to initialize wxWidgets.
> '
> Failed command: 'gnuplot -persist "/home/gretlcheck/.gretl/gpttmp.plt"'
>
> However, after that I don't get back to the gretlcli prompt ("?"), but
> instead gretl(cli) terminates and I'm at the shell prompt. And I think
> that's not right.
> This is with current git.
>
> thanks
> sven
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 22 Feb 2019 14:49:01 +0100 (CET)
> From: "Riccardo (Jack) Lucchetti" <r.lucchetti(a)univpm.it>
> To: Gretl development <gretl-devel(a)lists.wfu.edu>
> Subject: Re: [Gretl-devel] gretlcli termination (crash?) with gnuplot
> error
> Message-ID: <alpine.DEB.2.21.1902221448130.30721@joehenderson>
> Content-Type: text/plain; charset="iso-8859-15"; Format="flowed"
>
> On Fri, 22 Feb 2019, Sven Schreiber wrote:
>
> > Hi,
> >
> > the following happened when running the awm.inp example file from the
> SVAR
> > addon on a console-only installation (Linux), within a "gretlcli"
> session via
> > gretl's 'run' command.
> >
> > The awm.inp script must fail because it tries to send stuff to gnuplot
> with
> > the "display" option. That's understood. Here is some error output:
> >
> > gnuplot stderr: '01:48:52 PM: Error: Unable to initialize GTK+, is
> DISPLAY
> > set properly?
> > Failed to initialize wxWidgets.
> > '
> > Failed command: 'gnuplot -persist "/home/gretlcheck/.gretl/gpttmp.plt"'
> >
> > However, after that I don't get back to the gretlcli prompt ("?"), but
> > instead gretl(cli) terminates and I'm at the shell prompt. And I think
> that's
> > not right.
> > This is with current git.
>
> Uhm, that's strange, things work ok here.
>
> It look as if you're running a remote ssh session without X tunneling.
>
> -------------------------------------------------------
> Riccardo (Jack) Lucchetti
> Dipartimento di Scienze Economiche e Sociali (DiSES)
>
> Universit? Politecnica delle Marche
> (formerly known as Universit? di Ancona)
>
> r.lucchetti(a)univpm.it
> http://www2.econ.univpm.it/servizi/hpp/lucchetti
> -------------------------------------------------------
>
> ------------------------------
>
> Message: 4
> Date: Fri, 22 Feb 2019 15:03:14 +0100
> From: Sven Schreiber <svetosch(a)gmx.net>
> To: gretl-devel(a)lists.wfu.edu
> Subject: Re: [Gretl-devel] gretlcli termination (crash?) with gnuplot
> error
> Message-ID: <7c4bd26d-42a6-df93-adf3-1e385af0f31d(a)gmx.net>
> Content-Type: text/plain; charset=iso-8859-15; format=flowed
>
> Am 22.02.2019 um 14:49 schrieb Riccardo (Jack) Lucchetti:
> > On Fri, 22 Feb 2019, Sven Schreiber wrote:
>
> >
> > Uhm, that's strange, things work ok here.
>
> Well, are you testing on a setup without desktop environment?
>
> >
> > It look as if you're running a remote ssh session without X tunneling.
>
> This is actually on the Linux Subsystem for Windows or what it's called
> (WSL), in the form of a Debian userspace. But even if it were ssh
> without X tunnel, shouldn't gretl recover gracefully from that error?
>
> The error per se or my setup here is obviously not terribly important.
>
> cheers
> sven
>
>
> ------------------------------
>
> Message: 5
> Date: Fri, 22 Feb 2019 14:09:57 +0000
> From: "Pozdeev, Igor" <igor.pozdeev(a)unisg.ch>
> To: "gretl-devel(a)lists.wfu.edu" <gretl-devel(a)lists.wfu.edu>
> Subject: [Gretl-devel] signs in equation system restrictions
> Message-ID: <d36e9d8b727948acba4f9b77fd793d30(a)unisg.ch>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi all,
>
> Behavior of restrictions with patterns like "b[1, 1] + -2*b[2, 1] = 0" is
> strange. In the following MWE, the restricted coefficients differ by
> exactly 1.0 when restrictions are defined in the "bugged" way:
>
> open greene13_1.gdt
>
> # set up system
> system name="Grunfeld"
> equation I_GM const C_GM F_GM
> equation I_WE const C_WE F_WE
> end system
>
> # restriction w/bug
> restrict "Grunfeld"
> b[1,1] + -1.0*b[2,1] = 0.0
> end restrict
>
> estimate "Grunfeld" method=sur --iterate
>
> # restriction w/o bug
> restrict "Grunfeld"
> b[1,1] - 1.0*b[2,1] = 0.0
> end restrict
>
> estimate "Grunfeld" method=sur -iterate
>
> This a bug or a feature? Thanks for looking into this.
>
> Best,
> Igor
>
>
> Igor Pozdeev
> +41786120928
> www.igorpozdeev.me<http://www.igorpozdeev.me/>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.wfu.edu/pipermail/gretl-devel/attachments/20190222/09cf9881/...
> >
>
> ------------------------------
>
> _______________________________________________
> Gretl-devel mailing list
> Gretl-devel(a)lists.wfu.edu
> http://lists.wfu.edu/mailman/listinfo/gretl-devel
>
> End of Gretl-devel Digest, Vol 145, Issue 13
> ********************************************
>
--
Clive Nicholas
"My colleagues in the social sciences talk a great deal about methodology.
I prefer to call it style." -- Freeman J. Dyson
5 years, 10 months
