Greg_Mark_Finnegan@cup.portal.com (02/10/89)
Has anyone ever tried to read a data file from an IBM PC that consisted of REAL (in the Pascal sense) numbers. It only took me a day to remember that byte order is swapped for INTEGERS, but the same logic (just swapping bytes) does not work for reals. Any help or code would be appreciated. Greg Finnegan
earleh@eleazar.dartmouth.edu (Earle R. Horton) (02/13/89)
In article <14486@cup.portal.com> Greg_Mark_Finnegan@cup.portal.com writes: > >Has anyone ever tried to read a data file from an IBM PC >that consisted of REAL (in the Pascal sense) numbers. It >only took me a day to remember that byte order is swapped >for INTEGERS, but the same logic (just swapping bytes) >does not work for reals. > >Any help or code would be appreciated. The 8087 "short real" data type is a 32-bit quantity, wherein bits 0 through 22 are the significand, bits 23 through 30 are an exponent with bias 127, and bit 31 is the sign bit. Bit numbering is from lowest to highest address in memory. The integer bit of the significand is implicit in both short and long reals. ------------------------------------------------------------------ |S| EXPONENT | SIGNIFICAND | ------------------------------------------------------------------ 3 2 0 1 3 ^ ^ |- high address low address-| ---- --- I'm not sure, but I believe that the SANE short real data type is the same, but with bit-ordering reversed. (The sign bit is at the lowest address within the real, and the lsb of the significand is at the highest address.) When you transfer the data from the PC to the Mac, if your file transfer is of a type which preserves character values, then it would seem that moving bytes around should work. Try the following scheme, where bytes are numbered from 0 to 3: IBM Mac --- --- 0 3 1 2 2 1 3 0 You should also get both a SANE manual and an 8087 manual, to make sure you are handling special cases (i.e. NAN values) correctly. If at all possible, arrange to get a dump of part of the file's contents in ASCII format on both the IBM and the Mac, to make sure you are doing the right thing... Earle R. Horton. 23 Fletcher Circle, Hanover, NH 03755--Graduate student. He who puts his hand to the plow and looks back is not fit for the kingdom of winners. In any case, 'BACK' doesn't work.
SIAC@applelink.apple.com (Eric Ulevik) (02/14/89)
In article <14486@cup.portal.com> Greg_Mark_Finnegan@cup.portal.com writes: >Has anyone ever tried to read a data file from an IBM PC >that consisted of REAL (in the Pascal sense) numbers.> > >Any help or code would be appreciated. The simplest method (_if_ you can afford the disk space and CPU time) is to re-read the pc data file into a pc program, and write it out as ascii-format numbers (eg. "0.123E4"). This makes it a lot easier to write a Mac program to read the data. This is what I used to do in a multi-machine environment (not at Apple, BTW). Of course, we had an Elxsi 6400, so disk and cpu wasn't really a problem :-) Eric Ulevik email: SIAC@applelink.apple.com -- These writings are mine, not Apple's. That's the way I like it.--
perry@key.COM (Peter Kiehtreiber) (02/15/89)
In article <655@internal.Apple.COM> SIAC@applelink.apple.com (Eric Ulevik) writes: > In article <14486@cup.portal.com> Greg_Mark_Finnegan@cup.portal.com > writes: > >Has anyone ever tried to read a data file from an IBM PC > >that consisted of REAL (in the Pascal sense) numbers.> > > >Any help or code would be appreciated. > The simplest method (_if_ you can afford the disk space and CPU time) is > to re-read the pc data file into a pc program, and write it out as > ascii-format numbers (eg. "0.123E4"). This makes it a lot easier to > write a Mac program to read the data. Be careful with (decimal) text representations for floating-point numbers. Both the conversion to and from decimal text involves rounding and therefore inaccuracies, and the changes are (generally) not reversible. Unless you take special precautions, the numbers coming out at the other end are marginally different from the original. Both the 80[23]87 and 6888[12] coprocessors purport to conform to the IEEE floating-point standard. As such, the separation in exponent/mantissa, exponent biasing, NaN recognition etc. are the same. The only difference lies in bit (and byte) ordering, and certain details like silent/screaming NaN distinction. The text transmission method Eric mentions above is OK if the programs separate the numbers into exponent and mantissa, and read and write them as hexadecimal (or octal or whatever) text. (Decimal is of course also OK, but might not be as easy unless your compilers support (very) long integers). -- ------------------------------------------------------------------------ Perry The Cynic (Peter Kiehtreiber) perry@arkon.key.com ** What good signature isn't taken yet? ** ...!pacbell!key!perry