0

According to this float converter(https://www.h-schmidt.net/FloatConverter/IEEE754.html), 0.1 is actually stored binary as 00111101110011001100110011001101.....(infinite). Its decimal representation then is something like 0.100000001490116119384765625. How Java,for example, when we store a float like 0.1 and we print it, is actually represented as "0.1" and not the real value stored like "0.100000001490116119384765625"?

Thanks

fernando1979
  • 1,727
  • 2
  • 20
  • 26
  • 2
    Rounding, most likely. – Robert Harvey Feb 04 '19 at 19:39
  • @RobertHarvey: This question does not seeking debugging help or ask “why isn’t this code working’, so closing it on that basis is inappropriate. – Eric Postpischil Feb 05 '19 at 00:23
  • 1
    Java does not represent .1 as .1. When “0.1” is read in source text or from a string converted to a `double`, the result is 0.1000000000000000055511151231257827021181583404541015625. When printed with default formatting, this is shown as “0.1” because Java’s default formatting is to convert the actual number to the shortest decimal numeral such that converting the decimal numeral back to `double` yields the `double` value. This creates an illusion that the `double` is .1, but, actually, .1 is just close to the `double` value. (Shortest by number of significant digits, not string length.) – Eric Postpischil Feb 05 '19 at 00:27
  • @EricPostpischil: Which close reason do you prefer? – Robert Harvey Feb 05 '19 at 01:16
  • @RobertHarvey: it is a valid question and has an answer, so it should either be opened and answered or closed as a duplicate if a proper one is identified. – Eric Postpischil Feb 05 '19 at 01:17
  • [That](https://stackoverflow.com/questions/21895756/why-are-floating-point-numbers-inaccurate) is not a duplicate. The fact that floating-point operations are rounded does not explain why Java chooses to display 0.100000001490116119384765625 as .1. This display is not caused by limitations in floating-point arithmetic, because Java could display the full value. Java chooses to display .1. [This](https://stackoverflow.com/questions/14082287/why-are-floating-point-numbers-printed-so-differently/14084096#14084096) is a more relevant question (Java is in the question although untagged). – Eric Postpischil Feb 05 '19 at 02:27
  • Additionally, there are a number of other proper duplicates, such as [this one](https://stackoverflow.com/questions/30808492/if-0-1-has-no-binary-representation-why-i-get-0-1). However, the first few I looked at did not have good thorough answers, so I will write up something, perhaps in the next few days. For the moment, I discuss the specification of Java’s `toString` briefly [here](https://stackoverflow.com/questions/13088648/unexpected-behavior-of-double-primitive-type-data/13088918#13088918). – Eric Postpischil Feb 05 '19 at 02:28
  • @RobertHarvey: I provided a [new answer](https://stackoverflow.com/a/54640328/298225). I attempt to provide detailed floating-point information when I can. Where there are duplicates, please refer floating-point questions to specific questions they duplicate. Marking questions as duplicates of [that one](https://stackoverflow.com/questions/21895756/why-are-floating-point-numbers-inaccurate) promulgates treatment of floating-point arithmetic as uncontrollable and not completely understandable. We can do a better job of teaching floating-point arithmetic with more specific questions and answers. – Eric Postpischil Feb 11 '19 at 22:54
  • @EricPostpischil: It's a valiant effort (which I upvoted), but you don't necessarily need to read a treatise like "What Computer Scientists Should Know about Floating Point Arithmetic" to effectively use floating-point numbers. There is such a thing as Too Much Information. – Robert Harvey Feb 11 '19 at 23:09

0 Answers0