From: John Stone (johns_at_ks.uiuc.edu)
Date: Thu Jun 18 2009 - 09:59:46 CDT

Rob,

On Thu, Jun 18, 2009 at 12:27:08AM -0700, Rob wrote:
[...]
> Remains the problem: what was the byte size of integers and
> doubles on the computer, which generated the binary file?
> (I guess this is a matter of just trying to read the file and check
> whether the numbers make sense.....).

Determining the integer size is usually the more common problem case.
You could do this by checking for record length markers of two different
sizes, one for output files generated with 4-byte integers, and another
for output files generated using 8-byte integers.

Standard IEEE double-precision numbers are required to be 64-bits,
so you can trust that anything using double precision will generate
8-byte (64-bit) numbers. Similarly, IEEE single-precision numbers
are always 32 bits (4 bytes). So long as the code you're dealing
with consistently uses either single- or double- precision numbers
for various things, you have nothing to worry about there.
If the code can be optionally compiled using different precision,
that's where things get interesting. You could probably still detect
such a case by the values stored in the record length markers in the file,
it just means more test cases to handle.

> If the byte size of integers/doubles in the file does not match
> with my program reading it, one has to do a lot of messy
> coding (at least for the real numbers) to figure out their values.
> Right?

Depends on how your code works and how the file is structured.
If the file is structures with long runs of floating point values, or
long runs of integer values all grouped together, then it's pretty
easy to write a read routine that simply takes flags according to
the size of the integer or floating point types it must read.

> For now I assume that integers are 4 bytes and doubles 8.
> May I assume that this is almost generic? Or generic enough?

Assuming integers are 4 bytes is a good default, and you can wait until
you get your hands on a file produced by a compilation that used 8 byte
integers to worry about the altnernative case..

Double precision FP numbers will always be 8 bytes, as I mention above.

Cheers,
  John Stone
  vmd_at_ks.uiuc.edu

-- 
NIH Resource for Macromolecular Modeling and Bioinformatics
Beckman Institute for Advanced Science and Technology
University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
Email: johns_at_ks.uiuc.edu                 Phone: 217-244-3349
  WWW: http://www.ks.uiuc.edu/~johns/      Fax: 217-244-6078