1:33 p.m.
I just tried the new Rlib thing on one of Lee Adkins'
(http://www.learneconometrics.com/gretl/ebook.pdf) examples; attached
you'll find a simple script and the dataset to replicate Lee's section
16.9.2 (coditional logit). A couple of things that need to be fixed
appeared when you use the new mechanism:
1) If you run the script through the GUI client, the output of the R
foreign block isn't included in the output window; the cli client is ok.
2) More worryingly, it seems that the R computations are done _twice_. If
you run the script with Rlib on, you'll see the output
Calculating MLEs and large sample var-cov matrix.
This may take a moment...
Inverting Hessian to get large sample var-cov matrix.
before the output is displayed _and_ after. This is not a simple output
redirection issue, the R function is actually called twice. On my machine,
the output to
time gretlcli -b LA-cola.inp
is
real 0m16.775s
user 0m16.697s
sys 0m0.052s
with Rlib off and
real 0m32.201s
user 0m32.074s
sys 0m0.036s
with Rlib on.
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
4:02 p.m.
On Tue, 14 Jul 2009, Riccardo (Jack) Lucchetti wrote:
I just tried the new Rlib thing on one of Lee Adkins'
(http://www.learneconometrics.com/gretl/ebook.pdf) examples; attached
you'll find a simple script and the dataset to replicate Lee's section
16.9.2 (coditional logit). A couple of things that need to be fixed
appeared when you use the new mechanism...
Thanks for the report and example.
I'll reply at greater length before long, but for now I'll just
say that I've seen similar things myself, and I'm thinking of
restoring the libset option I junked, namely a switch, "R_lib on",
to use libR, with the default being to use the R binary. libR
ought to be much faster when a script contains multiple R blocks,
but it has some serious oddities. The points you mention as
"needing fixed" are not trivial to get right!
Allin.
1:52 a.m.
On Tue, 14 Jul 2009, Riccardo (Jack) Lucchetti wrote:
I just tried the new Rlib thing on one of Lee Adkins'
(http://www.learneconometrics.com/gretl/ebook.pdf) examples;
attached you'll find a simple script and the dataset to
replicate Lee's section 16.9.2 (coditional logit). A couple of
things that need to be fixed appeared when you use the new
mechanism:
1) If you run the script through the GUI client, the output of
the R foreign block isn't included in the output window; the cli
client is ok.
When we run the R binary, we do so using glib's "spawn" mechanism,
which attaches pipes to the called program's standard output and
error output so that we can capture these in files and send them
where we wish. I have not figured out how we can do the
equivalent when calling libR. Sane libraries offer a reasonably
simple way of redirecting printed output, sometimes by passing a
printing-function pointer. I can't find this in libR. but maybe
that's my failing.
2) More worryingly, it seems that the R computations are done
_twice_. If you run the script with Rlib on, you'll see the
output...
Yes, granted. I've put a bunch of debugging statements,
conditional on FDEBUG, into gretl_foreign.c, talking to stdout so
we can compare the sequence of events with gretl and libR's
stdout. So it seems that as soon as we call R(f)_initEmbeddedR
our current R command-set starts executing, and the subsequent
call to lib_run_Rlib_sync() is redundant -- see the sequence in
foreign_execute().
This may be fairly easy to fix -- or not. (Do we just have to
skip the first command?) Another clue may be in the argv passed
to R_initEmbeddedR. Varying the elements in that array can cause
things to break or behave oddly, or anyway differently. And in
different ways depending on whether we're starting gretl from a
shell prompt or launching it from a GUI icon, note.
One thing to watch out for, in varying anything in the libR calls,
is the condition where "gretl.export" (defined in our
gretl.Rprofile) is not found. I've run into that a bunch of
times.
I have to say that, compared to using all the other libraries
we've encountered with gretl, using libR is a rather frustrating
guessing-game.
Allin.
2:08 a.m.
On Tue, 14 Jul 2009, Allin Cottrell wrote:
> 2) More worryingly, it seems that the R computations are done
> _twice_. If you run the script with Rlib on, you'll see the
> output...
This may be fairly easy to fix -- or not. (Do we just have to
skip the first command?)
Hmm, maybe so. See the experimental change in foreign_execute()
marked "tricksy"!
Allin.
1:50 p.m.
On 15-07-2009, at 04:08, Allin Cottrell wrote:
On Tue, 14 Jul 2009, Allin Cottrell wrote:
>> 2) More worryingly, it seems that the R computations are done
>> _twice_. If you run the script with Rlib on, you'll see the
>> output...
>
> This may be fairly easy to fix -- or not. (Do we just have to
> skip the first command?)
Hmm, maybe so. See the experimental change in foreign_execute()
marked "tricksy"!
Maybe Simon Urbanek, who maintains and does clever things with R.app
in Mac OS X, can help
(mail address is "simon dot urbanek at r-project dot org " <== delete
spaces between " and change dot and at two punctuation).
Berend
6:23 p.m.
On Wed, 15 Jul 2009, Berend Hasselman wrote:
Maybe Simon Urbanek, who maintains and does clever things with R.app
in Mac OS X, can help
(mail address is "simon dot urbanek at r-project dot org " <== delete
spaces between " and change dot and at two punctuation).
Thanks, Berend, but I think we're OK now.
Allin.
3:41 p.m.
Allin Cottrell wrote:
On Tue, 14 Jul 2009, Riccardo (Jack) Lucchetti wrote:
> I just tried the new Rlib thing on one of Lee Adkins'
> (http://www.learneconometrics.com/gretl/ebook.pdf) examples;
> attached you'll find a simple script and the dataset to
> replicate Lee's section 16.9.2 (coditional logit). A couple of
> things that need to be fixed appeared when you use the new
> mechanism:
>
> 1) If you run the script through the GUI client, the output of
> the R foreign block isn't included in the output window; the cli
> client is ok.
When we run the R binary, we do so using glib's "spawn" mechanism,
which attaches pipes to the called program's standard output and
error output so that we can capture these in files and send them
where we wish. I have not figured out how we can do the
equivalent when calling libR. Sane libraries offer a reasonably
simple way of redirecting printed output, sometimes by passing a
printing-function pointer. I can't find this in libR. but maybe
that's my failing.
Did you check
http://cran.r-project.org/doc/manuals/R-exts.html#Setting-R-callbacks ?
8:39 p.m.
On Mon, 20 Jul 2009, chris wrote:
Allin Cottrell wrote:
> Sane libraries offer a reasonably simple way of redirecting
> printed output, sometimes by passing a printing-function
> pointer. I can't find this in libR. but maybe that's my
> failing.
>
Did you check
http://cran.r-project.org/doc/manuals/R-exts.html#Setting-R-callbacks ?
Thanks, Chris, but I think we've resolved this now. The main
thing was that I hadn't realized that R produces no printed output
when you source() commands, unless you explicitly tell it to (e.g.
by specifying echo=TRUE or print.eval = TRUE).
Allin.
5620
days inactive
5626
days old
8 comments
4 participants
participants (4)
-
Allin Cottrell -
Berend Hasselman -
chris -
Riccardo (Jack) Lucchetti