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] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |