Re: [Mingw-users] msvcrt printf bug
- Date: Fri, 03 Feb 2017 10:38:28 +0200
- From: Eli Zaretskii <eliz@xxxxxxx>
- Subject: Re: [Mingw-users] msvcrt printf bug
> From: "K. Frank" <kfrank29.c@xxxxxxxxx>
> Date: Thu, 2 Feb 2017 22:38:07 -0500
> (By the way, Alexandru asked nothing about floating-point calculations
> in his original post, and everything he has said in this thread indicates
> that he does understand how floating-point calculations work, so I have no
> reason to think that he needs to be tutored in the fact that floating-point
> arithmetic can be inexact.)
> Alexandru asked about printing out floating-point numbers. People
> have called this the "decimal" or "ASCII" representation of a
> floating-point numbers. I will stick to calling it the "decimal
> representation," by which I will mean a decimal fraction, of
> potentially arbitrary precision, that approximates a given
> floating-point number.
> In keeping with my point that floating-point numbers are well-defined,
> precise mathematical values, it is the case that every floating-point
> number is exactly equal to a single, specific decimal fraction.
> Alexandru complains that msvcrt doesn't use as its decimal representation
> of a floating-point number the decimal fraction that is exactly equal to it.
> This is a perfectly legitimate complaint.
Your description omits one crucial detail. Printing a floating-point
value using the printf family of functions involves formatting the
value's representation as specified by the format spec. In
particular, that spec defines the number of digits after the decimal
or the number of significant digits that the program wants to produce.
In most cases, the number of those digits is way less than in the full
decimal representation of the original value. Therefore, printing a
value almost always requires rounding the value to produce a
representation that accurately approximates the value within the
specified number of digits. And rounding involves floating-point
calculations. That is the reason for talking about floating-point
calculations in general in the context of printing FP values: these
two are in practice inseparable. Anyone who ever looked at the
innards of a printf implementation where it formats FP values will
tell you that.
IOW, your representation of this discussion as a confrontation between
the absolute mathematical rigor on one side and FUD on the other side
is an over-simplification. In practice, we do need to keep in mind
the general issues with FP calculations even when we are discussing
printf implementations. I would even say that talking about the exact
decimal representation of an arbitrary FP value when the issue being
discussed is what is produced by printf given a specific format which
mandates a certain number of digits after the decimal simply misses
the issue at hand.
> Representing a floating-point number with the decimal fraction
> (or ASCII string or whatever you want to call it) that is exactly,
> mathematically equal to that floating-point number is, quite
> simply, accuracy, rather than inaccuracy.
Not when the format requested a specific number of digits: then the
implementation should produce that number of digits and no more.
> Alexandru is right here, and is stating truths. The printf() that
> emits the decimal fraction that is exactly, mathematically equal
> to the floating-point number being printed is in a very legitimate
> and substantive sense more accurate than the one that does not.
Not with most uses of printf, which almost always involves some kind
of rounding to show less digits than in the full representation.
> > Pragmatically, there is every reason. For a binary representation
> > with N binary digits of precision, the equivalent REPRESENTABLE
> > decimal precision is limited to a MAXIMUM of N * log10(2) decimal
> > digits;
> Again, you conflate the inaccuracy of some floating-point calculations
> with individual floating point numbers themselves.
And they _are_ conflated, because decimal representation is almost
always rounded to the specified number of digits.
> When I read Alexandru's original post, it appears to me that he is trying
> to print out individual, specific floating-point numbers. That's his use
> case. I see nothing to suggest that he is trying to print out values in
> the gaps.
FP values are almost _always_ "in the gaps". Even if your program
just converts a single literal value in the sources to the internal
representation, and then converts it back while printing, this
involves FP calculations under the hood which almost always will
produce values not representable in the underlying FP system, and
almost always will produce round-off errors on the way. To avoid that
to some extent, one can do FP calculations at higher precision (wider
FP data type), but eventually you always bump into this brick wall, at
least in principle. It isn't FUD, it's a fact of life.
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
MinGW-users mailing list
This list observes the Etiquette found at
We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated.
You may change your MinGW Account Options or unsubscribe at: