Web lists-archives.com

Re: [Mingw-users] msvcrt printf bug

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.

- -- 

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
Version: GnuPG v2.0.20 (GNU/Linux)


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

This list observes the Etiquette found at 
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:
Also: mailto:mingw-users-request@xxxxxxxxxxxxxxxxxxxxx?subject=unsubscribe