From: Keith Marshall <keithmarshall@us...>  20110502 06:34:34

On 01/05/11 14:36, K. Frank wrote: > Hello Keith! > > On Sun, May 1, 2011 at 3:43 AM, Keith Marshall > <keithmarshall@...> wrote: >> On 30/04/11 23:14, Kai Tietz wrote: >>> long double (80bit): >>> digits for mantissa:64 >>> ... >> >> Alas, this sort of mathematical ineptitude seems to be all too common >> amongst the programming fraternity. It isn't helped by a flaw in the >> gdtoa implementation common on BSD and GNU/Linux, (and also adopted by >> Danny into mingwrt); it fails to implement the Steele and White stop >> condition correctly, continuing to spew out garbage beyond the last bit >> of available precision, creating an illusion of better accuracy than is >> really achievable. > > If I understand your point here, your complaint is that gdtoa will happily > generate more that twenty (or nineteen, if you will) decimal digits for a > gcc long double. (I won't speak to the technical correctness of gdtoa; > for all I know, it has bugs.) I think your point is that those "extra" decimal > digits represent false (and misleading) precision. > > (Sorry if I've misinterpreted your comment.) My complaint is that, long after the last bit of precision has been interpreted, gdtoa (which is at the heart of printf()'s floating point output formatting) will continue to spew out extra decimal digits, based solely on the residual remainder from the preceding digit conversion, with an arbitrary number of extra zero bits appended. (Thus, gdtoa makes the unjustified and technically invalid assumption that the known bit precision may be arbitrarily extended to ANY LENGTH AT ALL, simply by appending zero bits in place of the less significant unknowns). > I don't agree with this. Well, you are entitled to your own opinion; we may agree to disagree. > In most cases, it is not helpful to print out a long double to more > than twenty decimal place, but sometimes it is. The point is that it > is not the case that floatingpoint numbers represent all real > numbers inexactly; rather, they represent only a subset of real > numbers exactly. If I happen to be representing a real number exactly > with a long double, I might wish to print it out with lots (more than > twenty) decimal digits. Such a use case is admittedly rare, but not > illegitimate. This may be acceptable, provided you understand that those additional digits are of questionable accuracy. When you attempt to claim an accuracy which simply isn't available, then I would consider that it is most definitely illegitimate. > Let's say that I have a floatingpoint number with ten binary digits, so > it gives about three decimal digits of precision (2^10 == 1024 ~= 10^3). > I can use such a number to represent 1 + 2^10 exactly. Well, yes, you can if we allow you an implied eleventh bit, as most significant, normalised to 1; thus your mantissa bit pattern becomes: 10000000001B > I can print this number out exactly in decimal using ten digits after > the decimal point: 1.0009765625. That's legitimate, and potentially a > good thing. Sorry, but I couldn't disagree more. See, here you are falling into the gdtoa trap. You have an effective bit precision of eleven, which gives you: 11 / log2(10) = 3.311 decimal digits (i.e. 3 full digits) > If I limit myself to three digits after the decimal point I get 1.001 > (rounding up). You can't even claim that. Once again, you are confusing decimal places and significant digits. You may claim AT MOST 3 significant digits, and those are 1.00; (significance begins at the leftmost nonzero digit overall, not just after the radix point). > Sure, this is not a common use case, but I would prefer that the software > let me do this, and leave it up to me to know what I'm doing. I would prefer that software didn't try to claim the indefensible. Your 1.0009765625 example represents 11 significant decimal digits of precision. To represent that in binary, you need a minimum of: 11 * log2(10) = 36.54 bits (which we must round up to 37 bits). While a mantissa of 10000000001B MAY equate exactly to your example value of 1 + 2^10, it is guaranteed to be exact to 11 decimal digits of significance only if its normalised 37bit representation is: 1000000000100000000000000000000000000B Since you have only 11 bits of guaranteed binary precision available, you are making a sweeping assumption about those extra 26 bits; (they must ALL be zero). If you know for certain that this is so, then okay, but since you don't have those bits available, you have no technically defensible basis, in the general case, for making such an assumption; your argument is flawed, and IMO technically invalid.  Regards, Keith. 