Am 11.01.2021 um 19:38 schrieb Allin Cottrell:
On Mon, 11 Jan 2021, Sven Schreiber wrote:
> Am 11.01.2021 um 16:12 schrieb Sven Schreiber:
>> Hi,
>> another minor glitch: I had a large Stata dta file and imported it into
>> gretl - this actually worked flawlessly via dragging-and-dropping (on
>> Windows). Then I went on to save it; in the save dialog gretl inserted
>> the extension "gdt" automatically, and when I changed the format to
the
>> binary gdtb type in the drop-down box at the bottom, in the end I had a
>> file ending in .gdt.gdtb.
>> Obviously very easy to correct manually in various ways along the steps
>> taken, but maybe now we want to shake out even minor stuff like this.
>
> Hm, I'm observing something strange with this conversion to gdtb, and
> using the choice of "new missing codes".
Please try the test under "data-io" at
https://sourceforge.net/p/gretl/workspace/ci/master/tree/
Sorry, observing this on Windows here I just did a much cruder
comparison: Loading the same dataset from gdtb (new I think) and from
gdt. BTW gdt in this heavily unbalanced case is smaller at only 18MB
compared to 26MB before. I get:
- 6.6s for gdtb
- 14.7s for gdt
So yes, the binary stuff still helps a lot. It was just my expectation
that 26MB somehow "should" be faster loadable than that, but I guess
that was simply too optimistic.
Hm, then I wanted to check what the file size would be without
compression. So I exported to gdtb, setting compression to 0 (all in the
GUI); after a while I get an error window: " .... error zipping" !?
thanks
sven