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

["paul at inet dot co dot za" <sourceware-bugzilla at sourceware dot org>]

------- Additional Comments From paul at inet dot co dot za  2007-09-22 09:39 -------
(In reply to comment #15)
> Subject: Re:  Inconsistent rounding behaviour for sprintf and IEEE doubles
> 
> 
> 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 ...

I suppose so, yes.

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

... and I do not have a problem with this.  FP is the ideal format for us to use.

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

What a cop out.

We have been using FP successfully for over a decade.  FP is accurate for up to
15 decimal places- way more than we need. The problem is not accuracy here.  The
problem has to do with conversion of a number from the binary to a text
representation- a problem which the Microsoft library does not have. 

Please note:
  2597.525000000000091 to 15 decimals of precision is
  2597.52500000000
 - whichever rounding rules you choose to apply.  FP makes no claims at all
beyond 15 decimals of precision.

Is it in any way clearer, if I write
  2597.52500000000  == 2597.53
and
  2597.62500000000  == 2597.62

How can you claim consistency?????


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=4943

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.