[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-10-04 07:52 -------
(In reply to comment #44)
> (In reply to comment #43)
> > Correct.  However, since my conversion understands that a maximum of 15
> > significant digits is implicit in IEEE doubles,
> 
> A double is represented in binary and has 53 significant digits (bits) in base
> 2. Speaking of significant digits in base 10 for a binary number doesn't make
> much sense, as there isn't a canonical definition. For instance, if you want to
> make sure to distinguish any two double-precision numbers after a conversion
> into base 10, you need 17 decimal digits (BTW, this is explicitly stated in the
> IEEE-754 standard -- check it if you don't believe me).
> 
> > 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.
> 
> The number is represented in binary, but it is after all a real number. As a
> real number, it can make sense to display it with whatever number of digits. For
> instance, if one computes 2^100, the number is an exact power of 2, so that
> outputting all its digits is decimal is completely meaningful.
> 
> > 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.
> 
> You haven't understood the difference between "precision" and "accuracy". See
> the example above. Though 2^100 is represented in a double with a 53-bit
> *precision*, its *accuracy* is infinite (since the exact value is represented).

Ok, Vincent.  I have taken more than enough of your (and other's) valuable time
here.  I don't believe there's a single argument I can add to further explore
this topic.  If you at this stage still believe that it is correct to use the
default rounding mode in conversions to text, there is nothing I can say here to
change your mind, is there? :-)

I am not going to bash your point of view, as it is a valid one.  If I could ask
one thing, it would be that you don't bash mine, as it too is valid.

On a parting note,
 
Accuracy : The state of being accurate; freedom from mistakes, this
exemption arising from carefulness; exact conformity to
truth, or to a rule or model; precision; exactness; nicety;
correctness; as, the value of testimony depends on its
accuracy.
[1913 Webster]

Precision: The quality or state of being precise; exact limitation;
exactness; accuracy; strict conformity to a rule or a
standard; definiteness.
[1913 Webster]

The way I understand it, is that accuracy is defined by precision.  Therefore,
the phrase "the number is accurate to a precision of..." is used to describe the
confidence one might have in a number.  The same number accurate to a given
level of precision might be inaccurate to another level of precision.

My understanding is that there is no such thing as "infinite accuracy" when
applied to storing decimal values in floating point or going the other way
around.  Further, that the maximum level of precision for a decimal number
stored in binary format is finite, and set at DECIMAL_DIG, or 15 for IEEE doubles.

Much of the misunderstanding in this discussion has been due to the fact that I
kept harping on decimal numbers.  Your conclusion is that I don't understand
floating point.  In defense, I can only say that the topic of conversation here
has from the start been the textual representation of floating point numbers. 
Whenever someone tried to tell me about binary storage, I would ignore that
comment as it is off topic.  This exacerbated the misunderstandings and
consequent strong feelings that I was ignoring peoples input.

Perhaps, in fact certainly, I have been unclear in many of my comments,
incorrectly assuming a certain shared frame of reference or mindset on the part
of the reader.  For that, and the heated debates they sometimes sparked, I
apologise.

Please be aware that my intention was not to attack the GNU C library, it's
integrity, nor that of it's developers.  My intention was to improve it.  My
reference to the behaviour of the Microsoft library was to highlight the
differences, not to express my support for it as a whole.  Whilst I do tend to
support it's implementation of the sprintf() function over that of GLibC, you
have perfectly explained your perspective on the matter.

We could probably argue back and forth for weeks on this topic, and even derive
some enjoyment from the argument.  You would probably win most of those
arguments, since you are clearly the expert in this field.  I cannot, infringe
on more of your time though, and wish to thank you for that which you have
already given.

Best regards and wishes for the future
Paul Sephton

-- 


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.