Re: [Gretl-users] mysterious error discrepancy between two systems
On Thu, 15 Oct 2015, Sven Schreiber wrote:
Am 15.10.2015 um 21:29 schrieb Allin Cottrell:
> On Thu, 15 Oct 2015, Sven Schreiber wrote:
>>
>> On my local copy of the workfile the relevant value of the obs is
>> 0.870609. After transferring the full 350KB gdt file to the server this
>> value somehow becomes the problematic 4.90325e-310! All the other values
>> are fine (it seems).
>>
>> I thought it was file corruption, but the issue is reproducible after
>> transferring and overwriting on the server several times.
>
> How are you transferring the file to the server? A good test would be to
> check the md5sum at both ends. I mean something like this:
>
> ivanhoe:~$ md5sum xm729pmi.gdt
> b9d0d2e13f6547f4ba16e5c9e2626a2a xm729pmi.gdt
> ivanhoe:~$ scp xm729pmi.gdt ac.wfu.edu:./
> ivanhoe:~$ ssh ac.wfu.edu
> amsterdam:~$ md5sum xm729pmi.gdt
> b9d0d2e13f6547f4ba16e5c9e2626a2a xm729pmi.gdt
>
> If the checksums differ your file transfer mechanism is broken.
The checksums match ok (and I mean the files where the values differ on
inspection). I am using the sftp client WinSCP on Windows, binary transfer.
I'd be happy to do further testing, only right now I'm running out of
ideas what could be the cause.
Hmm, is the gdt file gzipped? (The "file" command can tell.) And if
so, what are the zlib and libxml versions on the server? E.g. here:
myrtle:~$ pkg-config --modversion zlib libxml-2.0
1.2.8
2.9.2
If the file is in fact gzipped, then one test to rule out corruption
on reading via zlib would be to save the full dataset to gdt without
compression, transfer it to the server and see if it's still wrong
there.
(Actually, the libxml version might be worth knowing regardless of
compression.)
Plus, maybe I can spot something if you could send me a copy of the
gdt file (and its checksum at your end, please).
Allin