Path: utzoo!utgpu!watmath!att!dptg!rutgers!apple!sun-barr!texsun!convex!mozart!psmith From: psmith@mozart.uucp (Presley Smith) Newsgroups: comp.lang.fortran Subject: Re: Extended Precision for real constants Message-ID: <1632@convex.UUCP> Date: 30 Aug 89 21:12:40 GMT References: <282@unmvax.unm.edu> <303@unmvax.unm.edu> <1598@convex.UUCP> <123897@sun.Eng.Sun.COM> <1621@convex.UUCP> <1068@cernvax.UUCP> Sender: news@convex.UUCP Reply-To: psmith@convex.com (Presley Smith) Organization: Convex Computer Corporation, Richardson, Tx. Lines: 103 In article <1068@cernvax.UUCP> achille@cernvax.UUCP (achille petrilli) writes: > >Now, I like f8x and after having seen this debate presenting even the >possibility of having to REWRITE code to have it work in f8x, I'd be\ >glad to see some REAL code, that, for the draft std, will have to be >rewritten to work under f8x. I'm not talking about precision, this even >changes (or could change) with a new release of the fortran library, >nothing to do with f77, f8x or whatever, I agree in this with Keith. > Certainly the Fortran 8x standard claims to contain all of FORTRAN 77. And in fact, the compatibility between Fortran 77 and 8x is defined in section 1.4.1 of the proposed standard that is out for public review. The ANSI SD-9 requires the committee to document all changes in the standard that "represents a potential incompatibiltiy from the last existing standard." You will note that section 1.4.1 was ADDED to this proposed standard between the 1st public review and this public review as a result of the committee's attempt to conform to the SD-9. Thus 1.4.1 represents what the committee believes the incompatibilities are. Now, the SD-9 states that the committee must analyze each "addition, deletion, or modification that represents a potential incompatibility from the last existing standard" by the following criteria: 1. Rationale, with benefits and costs, for proposed change 2. Type of difference between versions. 3. Conversion complexity 4. Breadth of impact of incompatibility or variation from existing practice. In fact, changes have been made to this proposed standard for 10 years and each of those changes has NOT been analyzed in this manner specified by the SD-9. Some of the documented differences in section 1.4.1 have been found by reviewers of the document. No list has been kept by the committee of incompatibilities that have been introduced and why. So, one worries... is this a complete set? Many lines of text have been added to this document in the last few meetings and many lines have been changed or removed. How many of the changes to the document and the language effect the FORTRAN 77 part of this proposed standard. Since I don't know of anyone that has implemented Fortran 8x or tested it even by hand for FORTRAN 77 comptability, I certainly am not willing to say that it's FORTRAN 77 compatible with only the things in 1.4.1 being different. You can believe what you want in this matter and must make your own judgement. I have entered the 4 things from 1.4.1 of the proposed new standard. Included are: 1. FORTRAN 77 permitted a processor to supply more precision derived from a real constant than can be contained in a real datum when the constant is used to initialize a DOUBLE PRECISION data object in a DATA statement. This standard does not permit a processor this option. 2. If a named variable initialized in a DATA statement, and does not have the SAVE attribute specified, FORTRAN 77 leaves its SAVE attribute processor dependent. This standard specifies that this named variable has the SAVE attribute. 3. FORTRAN 77 requires that the number of values required by the input list must be less than or equal to the number of values in the record during formatted input. This standard specifies that the input record is logically padded with blanks if there are not enought values in the input list unless the PAD = NO option is specified in an appropriate OPEN statement. 4. This standard has more instrinsic functions than did FORTRAN 77 and adds a few intrinsic subroutines. Therefore, a standard- conforming FORTRAN 77 program may have a different interpretation under this standard if it invokes a procedure having the same name as one of the new standard intrinsic procedures, unless that procedure is specified in an EXTERNAL statement as recommended for nonintrinsic functions in the appendix to the FORTRAN 77 standard. >I guess the opponents to f8x have nothing better to do that try to have >people feel f77 and f8x are 2 different things. Certainly f77 and f8x are two different things. As to whether f77 is completely contained in f8x, you should form your own opinion on this subject. I've given you my rationale and worries in the above explanation. > >Let get pragmatic, what should I rewrite under f8x ? do loops, ifs, >I/O statements ? what ? That's up to you. do loops... do you want to use array notation for an example? If you don't want to use new features, then don't change your code. > >I'm really interested to know (despite the fact I like f8x, I'm still >able to listen to different ideas :-). I believe that those that want 8x should have 8x. And those that don't want it should not have it forced on them. Seems like a simple enough concept to me.