# Re: [Mingw-users] msvcrt printf bug

*Date*: Sun, 5 Feb 2017 03:11:07 +0100*From*: Emanuel Falkenauer <E.Falkenauer@xxxxxxxxxxxxxxxxx>*Subject*: Re: [Mingw-users] msvcrt printf bug

Hello Mitch, I am quite confident that everybody in this thread knows (and always knew) that floats have finite precision, simply because their finite computer representation can only hold finite information. Ergo floats obviously can't represent all reals. But... that was NOT the point here, ever. Best, Emanuel On 03-Feb-17 18:27, Cervinka, Mitch wrote: > One of the limitations of floating point arithmetic is that it has a limited number of decimal places. This affects, not only the representation of irrational numbers like pi and e, but also rational numbers like 1/3 or 22/7. > > In particular, to represent 1/3 exactly using a binary or decimal representation would require an infinite number of bits. But computers are finite machines with a limited number of bits. So, for example, using 10 decimal digits of precision, the best representation you could achieve for 1/3 would be 0.3333333333 > > Then, if you multiply this value by 3, you will get 0.9999999999 rather than 1.0000000000, which is what you would want 3 * 1/3 to produce. > > By rounding to a smaller number of digits than the internal precision, you can often get the result you want. For example, rounding 0.9999999999 to nine digits results in 1.000000000, which is the correct answer. > > If rounding is not done, then an expression like (3*(1./3.) == 1.0) will return false, even though with infinite precision, it would return true. > > The problem is exacerbated when we are storing the numbers as pure binary (rather than binary coded decimal), and then convert the pure binary to a decimal number. In that case, the binary approximation of 1/3, when converted to decimal, may wind up being 0.33333333333333331. If you multiply this by 3, you get 0.9999999999999993, which, when rounded to 15 digits, is still 0.999999999999999, rather than the desired 1.000000000000000 > > Rounding to 14 digits gives the desired answer, of course. > > So, yes, there is a certain "squishiness" when trying to represent real numbers with finite-precision hardware. Not all real numbers can be represented exactly with finite-precision numbers. Even if we represent numbers internally as fractions (numerator, denominator), we are limited by machine precision to only a certain range of values for numerator and denominator, and certainly cannot represent pi or e or sqrt(2) exactly. > > > ------------------------------------------------------------------------------ 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

**Follow-Ups**:**Re: [Mingw-users] msvcrt printf bug***From:*Cervinka, Mitch

**Re: [Mingw-users] msvcrt printf bug***From:*Cervinka, Mitch

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

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

**Re: [Mingw-users] msvcrt printf bug***From:*Cervinka, Mitch

- 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):