# Re: [Mingw-users] msvcrt printf bug

*Date*: Sun, 05 Feb 2017 10:03:38 +0800*From*: KHMan <keinhong@xxxxxxxxx>*Subject*: Re: [Mingw-users] msvcrt printf bug

On 2/5/2017 6:40 AM, tei.andu@xxxxxxxxxxxx wrote: > [snip] > According to Dr. Regan, the number of fractional bits is equal to > the number of decimals in the corresponding decimal representation: > http://www.exploringbinary.com/number-of-decimal-digits-in-a-binary-fraction > <http://www.exploringbinary.com/number-of-decimal-digits-in-a-binary-fraction/> > http://www.exploringbinary.com/maximum-number-of-decimal-digits-in-binary-floating-point-numbers The phrasing in Rick Regan's articles may mislead some folks. Much earlier, someone discussed the usual way to visualize floats and doubles as unevenly spaced 'ticks' on a 'line'. Rick is doing something in an artificial setting -- like the other writers, he is discussing exact values of the tick marks. Articles by R Regan, B Dawson, etc. discusses where are some exact tick marks on a line of all floating point values. These tick marks are the exact values of the binary formats of floating point floats and doubles. This concept is only useful if your value is precisely on a tick mark -- an artificial condition that can only be meaningfully enforced in mathematical studies like what they are doing. I'd say, let us keep those mathematical studies and normal floating point usage separate. In normal use, values are almost always never on those tick marks. Just do one multiplication* -- are we going to keep all 106 bits from the 53 x 53 multiplier? (*Assume a real world calc where the result requires more than 53 bits to fit in exactly.) Then round, and stick it back into the double binary format. If you say that the result is exactly on a tick mark, that is no longer the calculation result, you have just decreed it to be exactly the tick mark, accumulating error. So one accumulates error and insist the calculation result is exactly on the tick mark, in the same breath. Is that good? In normal use, if the round trip conversion has no errors, the processor is getting and calculating the same numbers in binary format. Converting doubles beyond 17 significant digits is not really useful. Even B Dawson of Google says so. Well, it's fascinating there is so much support for exact tick marks. We should keep on discussing. > Yes, a float passed to printf will get converted to double because > of stdarg, but this conversion is lossless (no rounding). If we > convert this back to float we get the same input. (I had to use a > macro to prevent this conversion on my microcontroller, as arm-gcc > would use up a lot of code space for it.) > All the best. > [snipped all the rest] -- Cheers, Kein-Hong Man (esq.) Selangor, Malaysia ------------------------------------------------------------------------------ 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:*Emanuel Falkenauer

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

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