This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


------- Additional Comments From paul at inet dot co dot za  2007-09-22 07:51 -------
(In reply to comment #13)
> (In reply to comment #12)
> > > Now, C99 describes the behavior of the printf family in 7.19.6.1#13. For the
> > > examples given in this bug report, C99 says that the result should be
> > > correctly rounded. C99 does not say which result should be returned in case
> > > of a tie, but in practice, it relies on the definition given in IEEE-754.
> > 
> > This is interesting.  I wonder whether we could dig up a definition for the
> > phrase "correctly rounded".
> 
> It is defined by C99 in the section "Terms and definitions". Perhaps you should
> take a bit time to read the standards.
> 
> > You already know my opinion on what is meant by the
> > phrase.  Again, are we not assuming too much about the scope of the IEEE-754? 
> > From what I understand, that document is describing how to round the result of
> > calculations, not how to round decimal numbers arithmetically.
> 
> IEEE-754 covers the arithmetic operations, the square root, binary format
> conversions, binary FP <-> integer, *and* binary <-> decimal conversions (I've
> already mentioned Section 5.6 twice, have you read it?). All of these operations
> basically correspond to a math function over the real numbers, then a rounding
> operation.
> 
> > As you say, there are many more numbers that are inexactly stored than those
> > which are exact.  It took a while for us to find the fact that our reports
> > were sometimes generating the wrong numbers.  It works most of the time.  Our
> > problem is that those reports are being used by investment houses to make
> > decisions sometimes worth billions, and we just cannot have those decisions
> > made against wrong numbers.
> 
> Before reporting inexistent bugs, I think you should really learn more about
> standards and computer arithmetic, probably starting with:
>   http://www2.hursley.ibm.com/decimal/


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.5625);
  2597.52

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 
> 
> It is defined by C99 in the section "Terms and definitions". Perhaps you should
> take a bit time to read the standards.
> 
> > You already know my opinion on what is meant by the
> > phrase.  Again, are we not assuming too much about the scope of the IEEE-754? 
> > From what I understand, that document is describing how to round the result of
> > calculations, not how to round decimal numbers arithmetically.
> 
> IEEE-754 covers the arithmetic operations, the square root, binary format
> conversions, binary FP <-> integer, *and* binary <-> decimal conversions (I've
> already mentioned Section 5.6 twice, have you read it?). All of these operations
> basically correspond to a math function over the real numbers, then a rounding
> operation.
> 
> > As you say, there are many more numbers that are inexactly stored than those
> > which are exact.  It took a while for us to find the fact that our reports
> > were sometimes generating the wrong numbers.  It works most of the time.  Our
> > problem is that those reports are being used by investment houses to make
> > decisions sometimes worth billions, and we just cannot have those decisions
> > made against wrong numbers.
> 
> Before reporting inexistent bugs, I think you should really learn more about
> standards and computer arithmetic, probably starting with:
>   http://www2.hursley.ibm.com/decimal/

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

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.

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.

You have now explained your reasoning thoroughly.  The fact that I do not agree
with your reasoning, and in this instance do agree with Microsoft's, and the
rest of the world's reasoning does not make me an idiot.


-- 


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]