# Re: [Mingw-users] msvcrt printf bug

*Date*: Thu, 19 Jan 2017 14:09:16 +0000*From*: Keith Marshall <keithmarshall@xxxxxxxxxxxxxxxxxxxxx>*Subject*: Re: [Mingw-users] msvcrt printf bug

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19/01/17 11:19, Peter Rockett wrote: > On 19/01/17 08:21, tei.andu@xxxxxxxxxxxx wrote: >> Keith, have a look here please: >> http://www.exploringbinary.com/quick-and-dirty-floating-point-to-decimal-conversion >> Quote from the article: >>>>> Every binary floating-point number has an exact decimal equivalent >> <http://www.exploringbinary.com/number-of-decimal-digits-in-a-binary-fraction/>, >> which can be expressed as a decimal string of finite length. >> >> When I started this, I didn't know about this article. Also another >> in-depth look at float to decimal conversion from the same author: >> http://www.exploringbinary.com/maximum-number-of-decimal-digits-in-binary-floating-point-numbers >> <http://www.exploringbinary.com/maximum-number-of-decimal-digits-in-binary-floating-point-numbers/> > > I think the above is exactly the sort of misleading website Keith was > complaining about. Indeed, yes. I stumbled across that same website several years ago: I immediately dismissed it as the gigantic pile of bovine manure which it so clearly represents. Sadly, there are far too many mathematically challenged programmers who are gullible enough to accept such crap at face value; (and far too much similarly ill-informed nonsense pervading the internet). > If you take the binary representation of DBL_MAX, replace the least > significant digit in the mantissa with a zero and calculate the > decimal equivalent, you will get another 309 digit number. But > compared to the decimal equivalent of DBL_MAX, I think you will find > that the bottom ~294 digits will have changed. If you got this number > from a calculation, what does it tell you about the reliability of > the bottom 294 digits if the smallest possible change to the binary > number produces such a massive shift? It tells us, as I've said before, that those excess ~294 digits are meaningless garbage, having no mathematical significance whatsoever. > Put another way, if you do arithmetic at this end of the floating > point scale, the smallest change you can make is ~10^{294}. Thus only > ~15 of the decimal digits are significant - the rest are completely > uncertain. Passing to the decimal equivalents ultimately clouds the > issue. Floating point arithmetic is done in binary, not using decimal > equivalents. > > I suspect the OP's conceptual problem lies in viewing every float in > splendid isolation rather than as part of a computational system. > This is why printing to false precision has not attracted much uptake > here. There is a fundamental difference between digits and digits > that contain any useful information! Exactly so. Nicely elucidated, Peter. Thank you. > Or another take: If you plot possible floating point representations > on a real number line, you will have gaps between the points. The OP > is trying print out numbers that fall in the gaps! And, taken to its ultimate, there are an infinite number of possible numbers falling in each gap: each of these is an equally speculative possible misrepresentation of the reality conveyed by the actual bits encoding the number at one or other end of the gap. - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJYgMiMAAoJEMCtNsY0flo/GVkQAI8kkW2uI45R2Qeb+bw0UFB9 7j7GhzzYGRv5Xoo4NA4aDb1D9fVUWhnncIcfsdCuYriYdGRjaqJsrFEUvL5gBIpi 61QfgdD4dJvi1mRDc5i3zrV2YErjAqYUgb2HcxZkuWon3G6C5GgppFV9JoDVinNn Zr0w9B8vvIDiKxrbuLQL9cZ6xRJDvwPlf7KwqAt/uABqiBrHM7uBE/Jw1rlF2arj om7MBp1rQ35jZSrTGLEOXtBWSXQ7r320iJoijqZSR1nC6nYwrUqnKNyoChAt51Jp 0M/ODWj8yJf5+6c/kMpy5p8hW5Wg5z4osOl6ka4EvHfx3IfJLSKoP5PS4siTWOWM oGq0wDqO3lDiGkTG9qU2JVQp/LOwDvU1H7DBTB0xoe3/TGg8ef5lSSVqicj8dSid lzXXsuxvgOqEgjkj02MiEW4F1DwYS5W9DI97n/Lgn/Mrw+YAlWcbuli8GpMHiXaS oxPOpTK/78qC61mJqbsDxtBoXoqbLOacxQFWWr+Jt+iZU2/k7XcL1L2eMYWyJbfN bFeZjNXfIVgrsJBB3aYYgixeOi46yc2ubHmZsOaTk0xUUwHyO2Ry2aknG/02LWdE 4fWyFOvPuh1o3rcyDEOr1ohMAMAm+XMS04XnvutrNQiPlESv4vTiJuGimLo9u/Gk 0ubaTsuMi5EvZYtdNseN =LRHr -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ 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:*Peter Rockett

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

**Re: [Mingw-users] msvcrt printf bug***From:*Peter Rockett

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