Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!usc!ucsd!ames!skipper!elxsi!maine From: maine@elxsi.dfrf.nasa.gov (Richard Maine) Newsgroups: comp.lang.fortran Subject: Re: Char to real Message-ID: Date: 27 Aug 90 21:39:53 GMT References: <1990Aug24.133337.4114@sun.soe.clarkson.edu> Sender: news@skipper.dfrf.nasa.gov Organization: NASA Dryden, Edwards, Cal. Lines: 72 In-reply-to: taylor@sun.soe.clarkson.edu's message of 24 Aug 90 13:33:37 GMT On 24 Aug 90 13:33:37 GMT, taylor@sun.soe.clarkson.edu (Ross Taylor) said: Ross> I am looking for help with a problem converting character strings Ross> to real numbers.... Ross> Each 4 byte substring is either a special sequence of bytes Ross> (ASCII 255) indicating that some particular calculation is to be Ross> performed OR string contains the IEEE representation of an integer or Ross> real number and must be converted to one of these two formats (I always Ross> know which). Ross> My problem is that I cannot figure out a way of doing the data Ross> conversion THAT IS ABSOLUTELY STANDARD FORTRAN 77 AND COMPLETELY Ross> PORTABLE and does not involve any physical disk access. The code will Ross> be running on a variety of machines (PC, VAX, IBM, Sun) under a variety Ross> of OS's (DOS, VMS, CMS, unix) so portability is extremely important. If you are insistent on the parts about being absolutely standard and completely portable, I'm afraid you are out of luck. The standard does not even define the concept of a byte. You cannot guarantee that a character is 8 bits. For instance, old CDC Cyber systems had 6-bit characters, so you certainly aren't going to store an 8-bit byte in each of them. All of the systems you mentioned have 8-bit characters, so maybe you are ok there, but it is niether a standard nor completely portable assumption. Your sample code (omitted) is extremely non-portable. It has a reasonable chance of working only on systems that use IEEE floatting point and have the same byte order as the data file. That is rather severely restrictive. It is possible to write reasonably portable code that can determine the host system byte order (where applicable; forget it on systems that don't have "bytes"). Handling more general variations in floatting point format is really gory. The standard does not define any guarantee that you can read a binary file from one system on another system at all. The trick of reading the file as direct access does not work on all systems. On some systems a direct access file has non-portable special structure. Note also, if you are really picky about the standard, that Hollerith is not technically part of the standard. It is specified only in appendix C to the standard. The standard itself explicitly makes the distinction that the appendices are not part of the standard. You are using Hollerith when you try to use an "A" format for numeric data. I find the "best" approach to this class of problem to be modularization. It is pretty easy to do subroutines that do the job on various specific systems. Thus as long as you isolate the problem to a single small subroutine, you can provide a version of that subroutine for each supported system. The only other plausible approach I can think of is to remove the dependence on the host floatting point format by extracting the exponent and mantissa fields from the data and then using normal host arithmetic to put them together into a floatting point value expanding out the IEEE definition. Roughly something like value = isign*imantissa*(2.**(iexponent-ibias)) Fill in the details including the hidden bit handling. If you assume that characters are 8-bit quantities, the iChar intrinsic should reasonably portably get you an integer in the range 0-255 representing those 8 bits. Once you have the 4 integers representing the 4 bytes, it's not too hard to put them together into the sign, exponent, and mantissa values. I know the description in the paragraph above is a bit sketchy. I don't have actual code handy. Note that though this can be done "reasonably" portably, it is neither completely portable nor standard. -- Richard Maine maine@elxsi.dfrf.nasa.gov [130.134.64.6]