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
----------------------------------------------------------------------