[TAG] article "A Question Of Rounding" in issue #143 (Was: [Bug libc/4943] Inconsistent rounding behaviour for sprintf and IEEE doubles)
Kapil Hari Paranjape
kapil at imsc.res.in
Thu Oct 4 21:08:06 MSD 2007
Having long ago been part of a similar flamefest^Wdiscussion on a
similar topic, I would like to insert my own 2 paise at the risk of
getting some 1 paise worth of tomato thrown at me :-)
Let me begin with some truisms:
1. There are technical terms that are "common language" words. The
technical terms *try* to abstract the meaning of the words --- but
once the former are defined (through "standards" or "definitions")
they acquire a life of their own. Strictly speaking they should be
treated as *different* words with the same spelling and
"Precision" is such a term when it comes to floating point
2. The rules for the handling of floating point computations
(printing a number is also a computation!) have been set up with
the scientific and engineering community in mind. An experiment
in science results in a certain "value with an error-bar". A
computational simulation of such an experiment needs to be accurate
in the sense that it produces the "same" result.
Rules and standards should fit the purpose for which they were
designed. Expecting them to behave "reasonably" out of context is
3. One should be very careful while using floating point computations
with glibc for financial computations --- perhaps floating point
computations with glibc should be completely avoided in such
Such a bug could also be a feature in the eyes of some beholders.
If Paul wants to assert that his code "works properly" with
Microsoft's library, I think the authors and maintainers of glibc
should be willing to live with that. Note that such an assertion is
largely a matter of faith since we do not have the source code to the
latter library. Moreover, I think Vicent Lefevre has provided an
example to show that such beliefs may be optimistic.
One of the respondents to the bug report has been somewhat
intemperate. While criticising this we should note that Paul is not
the first person to have tried to report this "feature" of glibc as a
"bug". Extended discussions with my colleague did not prevent him from
filing a similar bug report against glibc's floating point handling.
(This was some years ago.) So glibc maintainers probably get their
share of such reports.
On the whole, I tend to agree with the maintainers of glibc on the
bug report. At the same time an article like this and the subsequent
discussion *may* help some readers avoid the pitfalls of wrongly
interpreting the results of floating-point computations.
More information about the TAG