Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucsd!sdd.hp.com!elroy.jpl.nasa.gov!ames!skipper!elxsi!maine From: maine@elxsi.dfrf.nasa.gov (Richard Maine) Newsgroups: comp.lang.fortran Subject: Re: problem with "pe" format Message-ID: Date: 5 Jun 90 15:44:50 GMT References: <90155.122858GL4@psuvm.psu.edu> Sender: #news@skipper.dfrf.nasa.gov Organization: NASA Dryden, Edwards, Cal. Lines: 85 In-reply-to: GL4@psuvm.psu.edu's message of 4 Jun 90 16:28:58 GMT On 4 Jun 90 16:28:58 GMT, GL4@psuvm.psu.edu (Garth Longdon) said: Garth> A user brought the following program to my attention, and I am Garth> unable to explain the output: Garth> ... Garth> 32 format(1pe13.3,f10.1) Garth> ... Garth> ...[questions about the effects of the P scale factor in formats].. Garth> Any clarification would be greatly appeciated (even of the type, "This Garth> is standard Fortran behaviour, you lamebrain. RFTM"). Ok, I'll go with "This is standard Fortran behavior", but I can't agree with the "lamebrain" part. Though it is standard, it is certainly subtle and confusing. I've had quite competent programmers come to me after spending many hours trying to "debug" programs whose only problem was in the output format statement. (They were trying to figure out how the values got to be a factor of 10 off, not realizing that this was an artifact of the format). And I'll try to elaborate a little on the FM. You are seeing the combined effects of two confusing "features". The first feature, as pointed out by some other follow-ups, is that the P scale factor continues its effect throughout the format statement, even though it is placed next to the e13.3 in a manner that "looks like" it applies only to the e13.3 part. To make the !p apply only to the e13.3, you could do something like format(1p,e13.3,0p,f10.1) The second feature is the strange effect of the P scale factor on F format descriptors. I'd explain the effect by saying that the P scale factor does the same thing to the mantissa of E and F format items; it multiplies them by the appropriate power of ten. On E formats, it then compensates by lowering the exponent value. On F formats, there is no exponent, so the number is just left off by some factor of 10. I think this behavior is "wrong". I have never seen anywhere that such behavior was desirable, and I've seen plenty of users confused by it. Sure, you could invent some situation where this feature could be used, but I'm dubious that those rare cases justify the confusions caused elsewhere. Regardless of my opinions about this feature, it is standard. Oh yes, if I recall, the effects on input are equally confusing. While I'm on the subject of P scale factors, let me point out another "feature" that I think is a bug in the standard (but a bug that all the compiler vendors seem to strictly follow). I mentioned this bug in my official comments on the Fortran 90 standard, though I didn't really expect the ANSI committee to make any changes based on my comment, this bug having by now achieved the status of standard practice. If you use the P scale factor with G format descriptors, it does strange things to the number of significant digits for no ascertainable reason. For instance, without a scale factor, the format descriptor G10.4 always gives 4 significant digits. This is the most significance you can get in a 10-character field with E or G (or D) formats for arbitrary values (well, anyway if the exponent is limitted between -99 and +99). It happens that this precision is just barely adequate for some of my applications. You would not think (anyway, I wouldn't) that the scale factor would have anything to do with the number of significant digits. Indeed 1PG10.4 still has 4 significant digits when the value is in the range that gives an "F type" output. However, for large or small values such that an "E type" output results, 1PG10.4 gives 5 significant digits (and thus does not fit in the field of 10 for negative values). The same 5 significant digits result for all P values except 0; that is, 2PG10.4 and 3PG10.4 also give 5 significant digits (should anyone ever want them, negative scale values still give 5 digits, though some of them are leading 0's and thus not technically "significant" by most definitions). Thus, if you want to use a scale factor with G format decsriptors, the most significance you can fit in a field of 10 is with 1PG10.3. This gives 4 significant digits in the E form, but only 3 in the F form. The 3 significant digits are insufficient for me, so I avoid using scale factors with G format, much as I generally prefer !p to the default 0P. I have never been able to figure out the rationale for this behavior. My best guess is that it is simply a "typo" in the standard and not what was intended. Perhaps one of the committee members that frequent this group can correct this guess. Regardless of the intent, it IS in the standard, and compilers DO implement it. -- Richard Maine maine@elxsi.dfrf.nasa.gov [130.134.64.6]