# 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 MinGW-users@xxxxxxxxxxxxxxxxxxxxx This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists. 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: https://lists.sourceforge.net/lists/listinfo/mingw-users Also: mailto:mingw-users-request@xxxxxxxxxxxxxxxxxxxxx?subject=unsubscribe

**References**:**[Mingw-users] msvcrt printf bug***From:*tei.andu

**Re: [Mingw-users] msvcrt printf bug***From:*K. Frank

- Prev by Date:
**Re: [Mingw-users] msvcrt printf bug** - Next by Date:
**Re: [Mingw-users] msvcrt printf bug** - Previous by thread:
**Re: [Mingw-users] msvcrt printf bug** - Next by thread:
**Re: [Mingw-users] msvcrt printf bug** - Index(es):