J3/10-179r2
To: J3
From: Malcolm Cohen/Stan Whitlock
Subject: Interp on G0 edit descriptor
Date: 2010 June 15
----------------------------------------------------------------------
NUMBER: F08/0029
TITLE: G0 edit descriptor and floating-point output.
KEYWORDS: G edit descriptor, 0 width
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 [258:7-9 10.7.5.2.2p2]:
"the G0 and G0.d edit descriptors follow the rules for the
Gw.dEe 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:
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. No, a value of d that results in a significant loss of precision
is not reasonable. An edit is supplied to correct this.
A3. No, it is not reasonable for d to be ridiculously large.
An edit is supplied to clarify the intent.
A4. No, e should not be bigger than that required to represent the
largest finite machine-representable number. An edit is
supplied to specify this.
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:
In 10.7.5.2.2, paragraph 2:
[258:9] "Reasonable processor-dependent" -> "Processor-dependent".
{A5.}
[258:10] After "value" insert
", that do not result in the field being filled with asterisks".
{A1.}
[258:10] Append new sentences to paragraph:
"The value of shall not result in the production of an output
value that differs from the internal value by more than
100*SPACING(value), and shall not be more than two larger than the
maximum number of digits that might be required to distinguish
between two different machine numbers of the kind of the internal
value. The value of 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 of that kind."
{The first sentence limits the choice of to lose no more than 2
digits of precision (A2) and to have no more than 2 spurious digits
of precision (A3); for some floating-point formats, the upper bound
is not strong, being d <= 2+MAX(PRECISION(value)+2,RANGE(value)*2).
The second sentence would allow e==4 for a lop-sided exponent range,
e.g. -1100 to +900, but would limit e to at most 3 if the exponent
range is e.g. -308 to +308 (A4).
Neither of these restrictions prevent a processor from producing
fewer mantissa or exponent digits for particular values if that does
not result in serious loss of accuracy.}
SUBMITTED BY: Malcolm Cohen
HISTORY: 10-179 m192 F08/0029 submitted
10-179r1 m192 Draft answer with straw vote on alternative
10-179r2 m192 Revised draft
----------------------------------------------------------------------