# Re: [Mingw-users] msvcrt printf bug

*Date*: Fri, 20 Jan 2017 16:19:05 +0000*From*: Peter Rockett <p.rockett@xxxxxxxxxxxxxxx>*Subject*: Re: [Mingw-users] msvcrt printf bug

On 19/01/17 14:09, Keith Marshall wrote:Thinking about this further, I believe there is another level of subtlety here.-----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. Again taking the DBL_MAX example from http://www.exploringbinary.com/number-of-decimal-digits-in-a-binary-fraction/, the logic goes: DBL_MAX is 1.1111111111111111111111111111111111111111111111111111 x 2 ^{^1023
}Add so:1.1111111111111111111111111111111111111111111111111111 x 2 ^{1023
= }(2 – 2^{-52}) ·
2^{1023
= }17976931348623...58368 (309 digits worth)The second step - the conversion from (2 – 2 ^{-52})
· 2^{1023} to this
monster 309-digit decimal number, and therefore the validity of the
trailing 294 digits - is unquestionably correct. All 294 digits are
perfectly good! The logical flaw in the above argument is actually
the very first step that equates the IEEE-format binary number to (2 – 2^{-52}) · 2^{1023}.
This is not an equation, it is a logical equivalence (should be a
'<=>' symbol)! (How do you assign a discrete data structure to
a number?) It thus follows that any reasoning about the IEEE-format
binary number using the decimal equivalent has to be tempered by
some key conditions because there has been a fundamental change in
the problem in the first step.Given the subtlety of this, I am not surprised many people miss the point and erroneously assert things like "every ^{
}binary floating-point number has an exact decimal
equivalent". The equivalent number written in terms of powers of 2
does indeed have an exact decimal equivalent; but this does not
extend 'upstream' to the original binary number. The second stage of
the reasoning is absolutely correct. But a correct piece of logic
following a flawed logical step is still false. The net conclusion,
of course, is that we still only have 15-16 significant digits and
any further digits are false precision due to the finite width of
the binary mantissa.From some unpromising beginnings, I have actually found this a very useful thread. I now have a clearer formal understanding of why so many people get floating point numbers wrong. I have also been corrected about recent versions of gcc not reordering instructions during optimisation - that is really useful to know! Peter 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. |

------------------------------------------------------------------------------ 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**:**Re: [Mingw-users] msvcrt printf bug***From:*tei.andu

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

**Re: [Mingw-users] msvcrt printf bug***From:*Keith Marshall

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