Double representation about bigfraction HOT 4 CLOSED

Doubles are scientific notation in binary, so the double value 1.1 isn't really 11/10; rather it's the closest binary representation of 11/10 that can fit in 64 bits. Inputting the double directly is for when you want that binary representation; inputting as a string is for when you want the true decimal 11/10.

from bigfraction.

Thanks for the feedback. However, I don't consider this an issue. There is no 1.1 in a base-2 floating point number, for basically the same reason there is no 1/3 in base 10. The fraction that it generates is exactly equivalent to what you passed in. 11/10 is not exactly equivalent to what you passed in. While it is confusing if you are not familiar with the details of floating point numbers, the behavior is well-defined and predictable. And I do my best to warn you in the javadocs and also provide a workaround (System.out.println(BigFraction.valueOf(Double.toString(1.1))))

Some sample code to consider:

double a = 0.1;
double b = 0.2;
if(a+b == 0.3)
  System.out.println("Math wins!");
else
  System.out.println("Computers win!");

This prints "Computers win!". In other words, 0.1 + 0.2 is NOT equal to 0.3, because 0.1, 0.2, and 0.3 cannot be exactly represented in base2. It's like if you say 1/3=0.33. 0.33+0.33+0.33 = 0.99, which is not equal to 1, even though 1/3 + 1/3 + 1/3 is equal to one.

It's also worth noting that BigDecimal(double) behaves the same way:

The results of this constructor can be somewhat unpredictable. One might assume that writing new BigDecimal(0.1) in Java creates a BigDecimal which is exactly equal to 0.1 (an unscaled value of 1, with a scale of 1), but it is actually equal to 0.1000000000000000055511151231257827021181583404541015625. This is because 0.1 cannot be represented exactly as a double (or, for that matter, as a binary fraction of any finite length). Thus, the value that is being passed in to the constructor is not exactly equal to 0.1, appearances notwithstanding.

I would actually argue that there is nothing unpredictable about that behavior, only unexpected and unintuitive to the average programmer. If you take the time to understand the underlying math, it is entirely predictable. If not, there is another method to give you the result you'd expect.

from bigfraction.

If you are interested in this topic, you might want to check out What Every Computer Scientist Should Know About Floating-Point Arithmetic. In my experience, very few computer scientists actually know this. :)

from bigfraction.

This video also gives a good explanation of floating point math.

from bigfraction.