 |
 |
In a message dated 3/9/04 4:13:05 PM, [log in to unmask] writes: >In the huge majority of existing codes, people don't start out by asking >for a precision of p and a range of r. Instead, they ask for 32-bit >or 64-bit reals and then have to translate their request into the >standard's terms. I find selected_real_kind(12,30) to be a pretty >verbose and nonintuitive spelling of 64-bit real. It is clear to >me that so do a lot of other people. But 64-bit reals are such a common >requirement that I think we should provide a simpler way to spell it, >even though that spelling will be pretty duplicative of >selected_real_kind(12,30). Yes, I know that they don't say exactly the >same thing in theory, but they are sure pretty close in practice. > Those Fortran users that have to deal directly, or even indirectly, with data often find Fortran to be very awkward for similar reasons. The Fortran standard rightly puts a large emphasis on portability, but that emphasis makes it awkward to express key concepts in a form that maps directly to machine characteristics. That despite the fact that computer architectures (at least those Fortran needs to interface to) have greatly decreased in diversity. For better or worse Fortran is not used to program microcontollers. It would be a great convenience for such users if there were a "standard" means of interfacing to a generic binary computer, with two's complement integers, byte sized characters, 16, 32, and 64 bit integers and logicals, 32, 64, and 128(?) bit reals with well defined byte orderings, and the ability to equivalence the different intrinsic types. The byte ordering definitions should allow simple mapping to and from big and little endian processors. The natural way to express this is with a standard module, say ISO_binary_2scomplement_system. The module should be defined so that in principle it can be implemented on any processor (albeit at great inefficiency on a signed magnitude base 10 system), and so the processor can easily report that it does not support the capabilities the module is intended to supply, but the capabilities should have a simple enough mapping to the types of hardware that Fortran is currently available on that vendors would rapidly adopt it.