------- Comment #4 from burnus at gcc dot gnu dot org 2008-04-15 19:08 ------- > I agree with you for output: we currently do COMPATIBLE rounding I wanted to write this when I approved the code, but I found one *printf function and checking the POSIX standard one finds:
"f, F The double argument shall be converted to decimal notation [...] The low-order digit shall be rounded in an implementation-defined manner." Therefore, I think COMPATIBLE is a good guess, but I'm not sure whether COMPATIBLE is always true. (In reply to comment #3) > I agree with you for output: we currently do COMPATIBLE rounding and it > shouldn't be too hard to change. The only case where we might not have control > is for the last significant digit output by snprintf(), where we might rely > somehow on the system library's implementation. Well, I would argue that this digit is the most important for rounding ... Does this mean we have to roll out our own implementation which replaces snprintf? > For input, however, I think we don't really have control on what we do > (we rely on the system strtod) and it is probably not that easy to change. I probably miss something, but where on input do you need to round? > PS: for input, I have come to the conclusion that NEAREST and COMPATIBLE are > really the same, as it is not possible for a decimal value to be exactly > halfway between two machine-representable floating point values. Can someone > confirm/infirm this? I wanted to mention BOZ I/O, but there you don't have a decimal point. But still I'm not sure that you cannot dream up a decimal number which has one digit too much for the machine-representible FP number. But in any case NEAREST is contained in COMPATIBLE as NEAREST does not describe what to to if the numbers are equidistant. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35862
