[Patch, libfortran] Reduce default precision for list-directed and G0 real output

[Jerry DeLisle]

On 03/12/2012 05:28 PM, Janne Blomqvist wrote:
> Hi,
>
> 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.

Agree

>
> 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
> above.
>
> Regtested on x86_64-unknown-linux-gnu, Ok for trunk?

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

Sincerely best regards,

Jerry