J3/10-179 To: J3 From: Malcolm Cohen Subject: Interp on G0 edit descriptor Date: 2010 June 11 ---------------------------------------------------------------------- NUMBER: TITLE: G0 edit descriptor and floating-point output. KEYWORDS: DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: For data types other than floating-point, the effect of the G0 edit descriptor is precisely defined. For floating-point output, the effect is precisely defined only if the value is an IEEE NaN or Infinity, the result is otherwise left up to the processor to select "reasonable" values for w, e, and d (if d is unspecified). The standard states "the G0 and G0.\si{d} edit descriptors follow the rules for the G\si{w}.\si{d}E\si{e} edit descriptor, except that any leading or trailing blanks are removed". One might deduce from the wording of this that there is no upper limit on the choice of w, since the production of additional leading (or trailing) blanks has no effect on the output. Q1. Is a value for w or e that results in the field being filled with asterisks reasonable? This is not, after all, an error condition. Q2. Is a value for d that results in significant loss of precision reasonable? E.g. d==1, or for a less extreme example, d==PRECISION(value)/2. Q3. Is a value for d that produces many more digits than the precision reasonable? E.g. d==1000000. Or, for a less extreme example, d==PRECISION(quad) with a single precision value. Q4. Is a value for e that produces many more digits in the exponent than the exponent range reasonable? E.g. e==1000000. Q5. If the standard cannot tell me what "reasonable" means, what purpose does it serve for it to say that it must be reasonable? I cannot see how to tell whether a processor conforms to the standard in this respect. DISCUSSION: It might be argued that these issues could be left to "Quality of Implementation", but that doesn't help portability. Furthermore, requiring the normal user to work output how many digits he needs to specify (as the value for d) to actually get close to the value he wants communicated is less than totally helpful. In order to promote maximum portability, to the extent that requirements can be placed on these values, they should be. The facility is not intended to guarantee round-trippability, regardless of how desirable that might be considered. The standard permits, but does not require, the "best" values of w, d or e to be chosen for each internal value. ANSWER: A1. No, that is not reasonable. An edit is supplied to clarify the meaning of "reasonable". A2. Yes, d==1 is reasonable. If the user wants more than one digit of precision he must specify the d value himself. A3. Yes, d==1000000 is reasonable. If the user wants fewer digits he must specify the d value himself. A4. Yes, e==1000000 is reasonable. If the user wants a smaller exponent field he should write his own output routine. A5. Yes, the use of the word "reasonable" in this context is entirely meaningless. An edit is supplied to remove this misleading terminology. EDITS to 10-007: for A1: Insert "that do not result in the field being filled with asterisks". for A5: Delete "reasonable". ALTERNATIVE ANSWERS: A2A. No, a value of d that results in a significant loss of precision is not reasonable. An edit is supplied to correct this. A3A. No, it is not reasonable for d to be ridiculously large. An edit is supplied to clarify the intent. A4A. No, e should not be bigger than that required to represent the largest finite machine-representable number. An edit is supplied to specify this. ALTERNATIVE EDITS: for A2A: Insert "The value of d shall not result in the production of an output value that differs from the internal value by a factor of more than 100*EPSILON(value)." {Allows loss of 2 digits, which seems reasonablely generous for large precisions, and very generous for single precision: maybe we should make a stronger requirement for small precisions?} for A3A: Insert "d shall not be more than 2 larger than the maximum number of digits that might be required to distinguish between two different machine numbers". {Allows production of two spurious digits, which seems reasonably generous. For some floating-point formats this would result in d <= 2+MAX(PRECISION(value)+2,RANGE(value)*2).} for A4A: Insert "e shall not be so large that the exponent would have a leading zero both when the internal value is the largest finite machine number and when it is the smallest finite machine number". {For a lop-sided exponent range, e.g. -1100 to +900, this would allow e==4. The idea here is that if the exponent range is e.g. -308 to +308, choosing e>3 is not reasonable.} SUBMITTED BY: Malcolm Cohen HISTORY: 10-179 m192 Submitted ----------------------------------------------------------------------