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
