Re: [Bug libc/4943] Inconsistent rounding behaviour for sprintf and IEEE doubles

[Pierre Habouzit <madcoder at debian dot org>]

On jeu, sep 20, 2007 at 06:33:29 +0000, paul at inet dot co dot za wrote:
> ------- Additional Comments From paul at inet dot co dot za  2007-09-20 14:33 -------
> No, Sir, I will not "go away" as you put it.  Consider for a moment the
> implications:  I write an app that reports financial statements using Windows
> and sprintf().  I later port the whole shananigan to Linux.  You don't need a
> degree in astrophysics to guess which library will get kicked.

On Sat, Sep 22, 2007 at 11:52:01AM +0000, paul at inet dot co dot za wrote:
> Oh dear.  There you guys go again, inferring that I am an idiot.  Quite
> honestly, all of your explanations thus far fail to address
> 
> printf("%.2f", 2597.525);
>   2597.53
> 
> printf("%.2f", 2597.625);
>   2597.52

  I suppose you meant .62 ...

> You can call "works for me", "perfectly sensible" and "according to spec" all
> you like, but converting 2597.525000000000091 as stored in binary to decimal
> gives 2597.53, whilst converting 2597.625000000000000 to decimal gives 2597.62.

  Yeah and this is correct, because rounding is performed following IEEE
754, and IEEE 754 uses round to nearest by default, see
http://en.wikipedia.org/wiki/IEEE_754#Rounding_floating-point_numbers
for the short explanation, which says that in case of a number that
falls midway, it's sometimes rounded towards -â sometimes towards +â. If
you don't get this, then it's your loss, but the behavior is correct.

> You say that C99 does not say what to do with halfway cases.  C99 says the
> number should be correctly rounded.  The correctly rounded number for 2597.625
> is 2597.63.  You say that the IEEE spec, says that it should be rounded to
> "nearest even".  I say that IEEE cannot re-define the rules of decimal
> mathematics.  Even if they could, the number 2597.525 should then be rounded to
> 2597.52 in order to be consistent.  But, you say, the number 2597.525 is
> inexactly stored, and is thus being rounded to the closest.  I say that if
> Microsoft can address this problem, then so can you.

  If you want to write a financial application like you said, then you
shouldn't have used floating point in the first place. Floating point is
designed so that errors due to inexact storing of the least significants
digits of your number are evenly distributed in a computation, so that
they dont loose too much precision.

  But to write a financial application where you don't have to deal with
less than 10^-6 or 10^-4 fractions of 1, then you should have used fixed
point arithmetics, so that you don't have to rely on unspecified
rounding behaviors.

  You wrote your application based on false assumptions, don't put the
burden on the glibc, you are wrong in the first place.
-- 
ÂOÂ  Pierre Habouzit
ÂÂO                                                madcoder@debian.org
OOO                                                http://www.madism.org

Attachment: pgp00000.pgp
Description: PGP signature