Web lists-archives.com

# Re: [Mingw-users] msvcrt printf bug

• Date: Thu, 19 Jan 2017 11:19:13 +0000
• From: Peter Rockett <p.rockett@xxxxxxxxxxxxxxx>
• Subject: Re: [Mingw-users] msvcrt printf bug

 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, 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 I think the above is exactly the sort of misleading website Keith was complaining about. To take the calculation of the decimal equivalent of DBL_MAX example on this website, the calculation does indeed yield a 309 digit decimal number although the use of the word "significant" here is very misleading. But the question you should be asking is: what is the _precision_ of the binary floating point number. 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? 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! 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! P. ...snip
```------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
```_______________________________________________