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-10-03 17:21 -------
(In reply to comment #42)
> I agree with that. But note that this paragraph says that:
>     base 2 -> base 10 -> base 2
> must be the identity function. Of course, this doesn't apply to:
>     base 10 -> base 2 -> base 10
> 
> > x = 9.074439913906690
> > printf("%.15f", x);
> >   9.074439913906691
> 
> This is a "base 10 -> base 2 -> base 10" conversion sequence.
> 
> If you want "base 10 -> base 2 -> base 10" to be the identity function, you
> shouldn't use more than 15 significant decimal digits. In your example above,
> you have 16 significant digits.

Correct.  However, since my conversion understands that a maximum of 15
significant digits is implicit in IEEE doubles, it knows that it is not sensible
to output the value 9.074439913906691 in the first place.  It is therefore the
identity function regardless of the requested precision, or whether we go
base10->base2->base10 or base2->base10->base2:

char buf[64];
x = 9.074439913906691
dbl2buf(sizeof(buf), buf, x, 15);
printf("%s\n", buf);
  9.074439913906690
x = 9.074439913906690
dbl2buf(sizeof(buf), buf, x, 15);
printf("%s\n", buf);
  9.074439913906690
dbl2buf(sizeof(buf), buf, x, 20);
printf("%s\n", buf);
  9.07443991390669000000

Why is this not better?

Whilst I realise that some people would love to see as a decimal representation
of the binary number,
  printf("%.32f", 9.07443991390669);
=>9.07443991390669069119212508667260

...and are used to seeing this, all of the extra digits after significant digit
15 are misleading.  They really do not make any sense in the decimal context.  

People seem to think that the decimal digits after significant digit somehow
contribute to the precision of the value, and are meaningful, where in fact they
are not meaningful in the decimal world, since the binary number cannot be
represented accurately as decimal beyond a precision of 15.

Effectively, irrational numbers base 2 are not the same set of irrational
numbers base 10.  It is illogical in my mind to try to represent anything as
decimal beyond significant digit 15, providing the conversion properly rounds
"according to pertinent recommended practice" any digits after DECIMAL_DIG.

We know that to represent the decimal mantissa 907443991390669 in binary
equivalent will take up 52 bits.  The 53'rd bit can only hold that much
information.  Yet, we repeatedly continue to divide the remainder to make up all
the rest of those digits...

Isn't that silly?  Even worse, misleading?


-- 


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]