[TAG] article "A Question Of Rounding" in issue #143 (Was: [Bug libc/4943] Inconsistent rounding behaviour for sprintf and IEEE doubles)

[Kapil Hari Paranjape]

Hello,

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
   pronounciation!

   "Precision" is such a term when it comes to floating point
   computations.

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
   --- unreasonable.

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
   contexts.

   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.

Regards,

Kapil.
--