# Re: [Mingw-users] msvcrt printf bug

*Date*: Mon, 6 Feb 2017 19:50:56 +0000*From*: "Cervinka, Mitch" <mitch.cervinka@xxxxxxx>*Subject*: Re: [Mingw-users] msvcrt printf bug

Just realized a typo. 2 hexadecimal digits is 1 byte, not two. -----Original Message----- From: Cervinka, Mitch Sent: Monday, February 06, 2017 1:49 PM To: MinGW Users List <mingw-users@xxxxxxxxxxxxxxxxxxxxx> Subject: RE: [Mingw-users] msvcrt printf bug Hi Emmanuel, Sorry if I stated the obvious. :) Perhaps the problem is that, to accurately express powers of 1/2 in decimal, one must use more digits of precision than the actual precision warrants. Example: 1/256 in hexadecimal is 0.01, but to represent it exactly in decimal, it is 0.00390625 . This means that, if a computer represented FP numbers with 8 bytes (2 hexadecimal digits) after the "decimal" point, then the precision of the numbers you could represent that way are on the order of 0.004, but if you're after an exact representation of the hexadecimal number in base 10, then you need to tack on an additional 5 digits that are not truly significant. I suppose there would be situations where you might want to know what the exact decimal representation of the number is, but usually, for FP calculations, we want to know what granularity we can expect. Having said that, I would think you could display the extra digits using a format that specifies a high precision. For example, printf("%f.3") should display 1/256 as 0.004, but printf("%f.8",x) should display 1/256 as 0.00390625 . I hope this is helpful and on-topic. -----Original Message----- From: Emanuel Falkenauer [mailto:E.Falkenauer@xxxxxxxxxxxxxxxxx] Sent: Saturday, February 04, 2017 8:11 PM To: mingw-users@xxxxxxxxxxxxxxxxxxxxx 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 ------------------------------------------------------------------------------ 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

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

**Re: [Mingw-users] msvcrt printf bug***From:*Emanuel Falkenauer

- Prev by Date:
**Re: [Mingw-users] msvcrt printf bug** - Next by Date:
**Re: [Mingw-users] [Allegro] Unable to achieve a successful build on Windows** - Previous by thread:
**Re: [Mingw-users] msvcrt printf bug** - Next by thread:
**[Mingw-users] Location of sqrt for g++ compilation** - Index(es):