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@wfu.edu>
Дата: 25 квітня 2014, 23:49:01

On Fri, 25 Apr 2014, Riccardo (Jack) Lucchetti wrote:

> On Fri, 25 Apr 2014, oleg_komashko@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@lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
!