On 03/12/2012 05:28 PM, Janne Blomqvist wrote:

currently when writing a value of type real or complex using
list-directed output, the G0 edit descriptor, or namelist output,
gfortran chooses the number of significant digits such that a
binary->ascii->binary roundtrip recovers the original value exactly,
per IEEE 754-2008. Assuming, of course, that the target snprintf() and
strto{f,d,ld,q} functions are up to the task. However, I think this
choice is not a good idea:

- The standard doesn't require this behavior, it merely says something
along "reasonable processor-dependent values for w, d, and e shall be
chosen". Thus, a user who requires an exact roundtrip must specify the
number of digits (d) himself anyway.

True, but we did deliberately make an effort to do the round trip and at the time all thought it was the "right" thing to do, putting accuracy over speed. This would be a reversal of philosophy and in my opinion, if people need speed with formatted I/O, your other patch that adjusts the internal guard digits is the way to go. I vote do not change.

- If an exact roundtrip is required, the standard provides the B, O,
and Z edit descriptors which do guarantee this.

Maybe, but not very convenient.

- G formatting doesn't work very well when d is large (in libgfortran,
list-directed and namelist real output uses G formatting, so this
applies in these cases as well). Somewhat simplified, G formatting
works such that when the exponent is in the range [-1, d], F editing
is used, otherwise E editing. Thus, with a large d, F editing is used
for numbers with a large magnitude, making the result more or less
unreadable. For instance, what is the magnitude of
"-3333333333333333333333333333333.33350"? This output is for quad
precision, but the same problem exists to a lesser extent for smaller
real kinds as well.

We still have some outstanding rounding issues to resolve and I think we should do so before getting into these finer points. The above example illustrates a feature, not necessarily that anyone really uses it. if one wants more readable results, format it to suit.

- In many if not most uses, printing out the result in full precision
is not needed or just pointless if precision loss has already occured
during the calculation.


Thus, I suggest that the choice of d should be based on readability
and usefulness for the common case rather than guaranteeing an exact
roundtrip. The attached patch does this. Based on my own unscientific
tests, the patch chooses d=6 significant digits, as with 6 digits it's
still relatively easy to eyeball the magnitude of a number when F
editing is used without having to explicitly count digits. At the same
time, 6 significant digits is usually more than enough when reading
the output of a program.  Incidentally, 6 significant digits is also
what is used with the printf() "%g" specifier if the precision is not
explicitly specified, presumably for roughly similar reasons as stated

Regtested on x86_64-unknown-linux-gnu, Ok for trunk?

I appreciate your thoughts and efforts, but think we should hold off on this 

Sincerely best regards,


Reply via email to