From: Peter R. <p.r...@sh...> - 2017-01-19 11:19:24
|
On 19/01/17 08:21, tei...@tu... 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. 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 |