Below are lines 1328-1332 from gretl_foreign.c
1328 fprintf(fp, "gretldata <- read.table(\"%s\", header=TRUE)\n",
Rdata); 1329 fprintf(fp, "gretldata <- ts(gretldata, start=c(%d, %d), frequency =
%d)\n", 1330 atoi(datestr), subper, dset->pd); 1331 } else { 1332 fprintf(fp,
"gretldata <- read.table(\"%s\", header=TRUE)\n", Rdata);
read.table should include after header=TRUE)\n explicit colClasses
=c("numeric",...
--- Оригінальне повідомлення ---
Від кого: "Allin Cottrell" < cottrell(a)wfu.edu >
Дата: 25 квітня 2014, 23:49:01
On Fri, 25 Apr 2014, Riccardo (Jack) Lucchetti wrote:
On Fri, 25 Apr 2014, oleg_komashko(a)ukr.net wrote:
> Thank everybody! Have tried on debian/jessie CVS and from Debian repos and
> on XP: the same
> The problem is 100% with R 3.1 Have installed 3.03 works
That's nice to know; however, the problem remains. Would it be worthwhile to
use binary format when exporting to R? From the R help:
All R platforms use the XDR (bigendian) representation of C ints
and doubles in binary save-d files, and these are portable across
all R platforms. (ASCII saves used to be useful for moving data
between platforms but are now mainly of historical interest. They
can be more compact than binary saves where compression is not
used, but are almost always slower to both read and write: binary
saves compress much better than ASCII ones.)
Maybe this discussion is getting a tad too technical. Should we continue on
gretl-devel?
I'll just say this for now: importing data in text form into R 3.1.0 works
OK so long as we don't use excess precision in printing the data. And in
fact our use of excess precision was inadvertent (a buglet, harmless until
we hit the current version of R). So this will be easy to fix for gretl
1.9.99 in the coming week.
Allin
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users