Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!stat!stat.fsu.edu!mccalpin From: mccalpin@masig3.ocean.fsu.edu (John D. McCalpin) Newsgroups: comp.lang.fortran Subject: Re: FORTRAN 8X PRECISION Message-ID: Date: 9 Nov 89 10:34:19 GMT References: <7563@xenna.Xylogics.COM> <8619@microsoft.UUCP> <1209@key.COM> Sender: news@stat.fsu.edu Organization: Supercomputer Computations Research Institute Lines: 64 In-reply-to: sjc@key.COM's message of 9 Nov 89 06:16:29 GMT In article <1209@key.COM> sjc@key.COM (Steve Correll) writes in reply to my earlier posting on ways to deal with the Fortran-8X specification of precision problem: >1. Using context doesn't work in examples like "CALL XYZ(3.5)". Good point.... This makes it even more important that the user can tell the compiler what the precision of an un-suffixed literal floating-point constant is supposed to be. >2. Another alternative mentioned earlier, the PARAMETER statement, doesn't > solve the problem either. In the following example (please correct me if I'm > wrong) the standard permits the compiler to convert "1e50" from text to real > and then to doubleprecision, possibly overflowing during the intermediate > step. When you change REAL to DOUBLEPRECISION in IMPLICIT statements, you > still need to change "e" to "d" in the exponents in PARAMETER statements. > implicit doubleprecision (d) > parameter (d = 1e50) This one does not bother me too much, because the user has specified something that the machine may not be able to give. I would just hope to be told about the overflow! >3. For many people, who simply want to change REAL to DOUBLEPRECISION globally > because (for example) REAL on the Cray gives them the same results as > DOUBLEPRECISION on the Vax, somehow extending the IMPLICIT statement to > constants would work well. Unfortunately, that's not a particularly general > or powerful approach, and therefore not attractive to a standards committee. I don't see why this approach is not "general" or "powerful", but in any event it is one HELL of a lot more powerful than no ability to specify at all! > The F88 approach solves the problem too, as soon as we all finish editing all > our sources to put "_my_precision" after all the constants.:-) Unfortunately, > it's going to be hard to find a missing "_my_precision" in a large program. And it is going to be difficult to read the !@#$%^ program once you've finished making those conversions. >4. My experience with PL/I says that if the language designer lets the > programmer specify the number of decimal digits of precision, the law of > unintended consequences takes effect, and you get exactly the opposite of > what you wanted. Very few PL/I programs say "float bin(my_precision)". Most > say "float bin(6)" or "float bin(5)" or whatever the programmer memorized as > an idiom for "single precision" when s/he first learned the language. [....] > In this, the current F88 draft improves on the previous one. Because you must > use an intrinsic to obtain precision in terms of digits, you are more likely > to store the precision in a parameter and use that instead of repeating the > number of digits (perhaps inconsistently) throughout the program. But you are not _required_ to used parameters. I can virtually guarantee that one of the most common problems that will show up with new users (and perverse old users :-) ) is the abuse of the ability to specify KIND's literally a(1:100) = a(1:100) + 0.3_4*b(1:100) ! KIND=4 is obviously 32-bit! >...{sun,pyramid}!pacbell!key!sjc Steve Correll -- John D. McCalpin - mccalpin@masig1.ocean.fsu.edu mccalpin@scri1.scri.fsu.edu mccalpin@delocn.udel.edu