5:34 p.m.
Some considerations about this new feature after a little using.
- Sometimes, when executing (non-interactively) an R script which
contains syntax errors Gretl crashes after informing the user about
the error.
Here an example is where I'm trying to estimate an APARCH with fGarch.
<i>
library(fGarch)
rr = gretldata[,"rr"]
a = garchFit(~aparch(1,1),data=rr,cond.dist="dged",trace=FALSE)
</i>
- Besides, Gretl does not keep trace of the opened R script, like it
does for normal *.inp files in the recent opened files list. I think
they are supposed to be listed there as well, maybe underlined with a
different color or font.
- Strangely, Gretl does not support the opening of an R script by
simply dragging and dropping the file within the program window. I
have to open it through the graphical menu.
- Last, when I have an R script window opened and I open somehow a new
dataset, the R script window is automatically closed. That is pretty
unfair.
That's all!
Bye
6:55 p.m.
On Sat, 24 May 2008, Stefano Balietti wrote:
Some considerations about this new feature after a little using.
- Sometimes, when executing (non-interactively) an R script which
contains syntax errors Gretl crashes after informing the user about
the error...
Oops, the verbose message from R was overflowing our error-message
buffer. Fixed in CVS.
- Besides, Gretl does not keep trace of the opened R script, like it
does for normal *.inp files in the recent opened files list. I think
they are supposed to be listed there as well, maybe underlined with a
different color or font.
That could perhaps be added. It would require a fair number of
changes.
- Strangely, Gretl does not support the opening of an R script by
simply dragging and dropping the file within the program window. I
have to open it through the graphical menu.
Well, there's nothing very "strange" about that, it doesn't happen
by magic ;-) However, that's now coded in.
- Last, when I have an R script window opened and I open somehow a
new
dataset, the R script window is automatically closed. That is pretty
unfair.
OK, fixed in CVS.
Allin.
9:49 p.m.
While we're on this: I just committed a few changes, mostly cosmetic, to
the "export from R" machine:
1) the function gretl_export and the string gretl_dotdir were renamed to
gretl.export and gretl.dotdir. I'm no R export, but it looks like more
polite to use the dot rather than the underscore in R-land.
2) we had a naming problem when exporting a time-seried object with just
one variable; now fixed (a bit clumsily, but as I said I'm no R expert).
We have an open problem: if some sort of subsampling is in effect on the
gretl side, mostl likely the append mechanism won't work. This is due to
the fact that I haven't been able to figure out how to stuff into the csv
file row labels in a format that that gretl can digest, so I removed row
labels altogether. An alternative possibility would be to intervene on the
gretl side: in fact, the script below (which has nothing to do with R
interaction _per se_) won't work
<script>
nulldata 10
x = normal()
smpl +1 -1
store @dotdir/foo.csv
delete x
append @dotdir/foo.csv
</script>
unless, of course, you get rid of the "smpl" command on line 3. I don't
know if this is actually a problem. It certainly makes things more
difficult when it comes to R interaction.
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
1:17 a.m.
On Sat, 24 May 2008, Riccardo (Jack) Lucchetti wrote:
While we're on this: I just committed a few changes, mostly
cosmetic, to the "export from R" machine:
1) the function gretl_export and the string gretl_dotdir were
renamed to gretl.export and gretl.dotdir. I'm no R export, but
it looks like more polite to use the dot rather than the
underscore in R-land.
It seems to me a weird tic in the R language that '.' has no
special syntactical charge in the middle of an identifier -- but
let it not be said that we are lacking in politesse!
BTW, please watch out for some changes in CVS: I'm moving the
R-file writing apparatus from gui_utils.c to a new file,
lib/src/foreign.c, so as to support command-line invocation of
chunks of external script, as per Ignacio's suggestion.
2) we had a naming problem when exporting a time-seried object
with just one variable; now fixed (a bit clumsily, but as I said
I'm no R expert).
If it works, then hey!
We have an open problem: if some sort of subsampling is in
effect on the gretl side, mostl likely the append mechanism
won't work...
Append has some "issues". That's been on my agenda for a while,
but I'll see if I can do anything that might be useful in this
context.
Allin.
1:40 a.m.
On Sat, 24 May 2008, Allin Cottrell wrote:
BTW, please watch out for some changes in CVS: I'm moving the
R-file writing apparatus from gui_utils.c to a new file,
lib/src/foreign.c, so as to support command-line invocation of
chunks of external script, as per Ignacio's suggestion.
E.g., based on the example in the manual:
<script>
open bjg.gdt
foreign language=R
# extract the log series
y <- gretldata[, "lg"]
# estimate the model
strmod <- StructTS(y)
# save the fitted components
compon <- as.ts(strmod$fitted)
# save the estimated variances
vars <- as.matrix(strmod$coef)
# export into gretl's temp dir
gretl.export(compon)
gretl.export(vars)
end foreign
append @dotdir/compon.csv
vars = mread("(a)dotdir/vars.mat")
print vars
</script>
This works in CVS. I'll do some proper testing tomorrow.
("foreign language=ox" should be a possibility too, but it's not
ready yet.)
Allin.
6:48 a.m.
On Sat, 24 May 2008, Allin Cottrell wrote:
This works in CVS. I'll do some proper testing tomorrow.
("foreign language=ox" should be a possibility too, but it's not
ready yet.)
Well, we do have a "special relationship" with R, so generalising this
(which may include octave, gnuplot... whatever) requires a bit of
planning. For example, the way we launch R is hardwired. In the case of,
say, ox, the user should have a way to tell gretl where the executable is,
and so on. I'd say, let's focus on R right now and postpone the
generalisation for 1.7.5++.
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
2:49 p.m.
On Sun, 25 May 2008, Riccardo (Jack) Lucchetti wrote:
On Sat, 24 May 2008, Allin Cottrell wrote:
> This works in CVS. I'll do some proper testing tomorrow.
> ("foreign language=ox" should be a possibility too, but it's not
> ready yet.)
Well, we do have a "special relationship" with R, so
generalising this (which may include octave, gnuplot...
whatever) requires a bit of planning. For example, the way we
launch R is hardwired. In the case of, say, ox, the user should
have a way to tell gretl where the executable is, and so on. I'd
say, let's focus on R right now and postpone the generalisation
for 1.7.5++.
Yes, agreed.
Allin.
12:58 p.m.
On Sun, 25 May 2008, Allin Cottrell wrote:
On Sat, 24 May 2008, Allin Cottrell wrote:
> <script>
> open bjg.gdt
> foreign language=R
...
> end foreign
"foreign" now has two options: --send-data, which does what you
think, and --quiet, which suppresses non-error printed output from
the foreign program (i.e. R).
This is now in the user's manual (a bit concisely, perhaps) in the R
chapter.
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
5:17 p.m.
On Mon, 26 May 2008, Riccardo (Jack) Lucchetti wrote:
On Sun, 25 May 2008, Allin Cottrell wrote:
>
> "foreign" now has two options: --send-data, which does what you
> think, and --quiet, which suppresses non-error printed output from
> the foreign program (i.e. R).
This is now in the user's manual (a bit concisely, perhaps) in
the R chapter.
Very nice. Like the sample R-calling function.
Allin.
2:22 a.m.
On Sat, 24 May 2008, Riccardo (Jack) Lucchetti wrote:
[T]he script below (which has nothing to do with R interaction
_per se_) won't work
<script>
nulldata 10
x = normal()
smpl +1 -1
store @dotdir/foo.csv
delete x
append @dotdir/foo.csv
</script>
I think this problem is specific to unstructured data. If you
stick in, for example, "setobs 1 1950" after the "nulldata"
command, the script works OK. I'll take a further look at this.
Allin.
6:53 a.m.
On Sat, 24 May 2008, Allin Cottrell wrote:
I think this problem is specific to unstructured data. If you
stick in, for example, "setobs 1 1950" after the "nulldata"
command, the script works OK. I'll take a further look at this.
Hmm, not quite. For example:
<script>
nulldata 10
setobs 4 1990:1
x = normal()
smpl +1 -1
store @dotdir/foo.csv --omit-obs
delete x
append @dotdir/foo.csv
</script>
My point is that we ought to find a way to do without the row labels if
the number of observations in the current sample matches the number of
rows in the csv file.
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
6371
days inactive
6373
days old
12 comments
3 participants
participants (3)
-
Allin Cottrell -
Riccardo (Jack) Lucchetti -
Stefano Balietti