Java Float multiplication giving wrong result

Question

Multiplication using FLOAT is giving noticeable difference.

public static void main(String[] args) {
    // using string and parsing instead of actual data type is part of use case, that is why representing the same here

    double v1 = parseDouble("590.0");
    double v2 = parseDouble("490.0");
    double v3 = parseDouble("391.0");

    float v4 = parseFloat("590.0");
    float v5 = parseFloat("490.0");
    float v6 = parseFloat("391.0");

    System.out.println(new BigDecimal(v1 * v2 * v3));
    System.out.println(new BigDecimal(v4 * v5 * v6));

    System.out.println(BigDecimal.valueOf(Float.parseFloat("289100.0") * Float.parseFloat("391.0")));
    System.out.println(BigDecimal.valueOf(Double.parseDouble("289100.0") * Double.parseDouble("391.0")));

}

Output:

113038100 // double multiplication
113038096 // float multiplication
113038096
113038100

For above code,

(590.0 * 490.0 * 391.0) gives 113038100 using double

(590.0 * 490.0 * 391.0) gives 113038096 using float (113038100 - 113038096 = 4 // difference)

I have read through https://floating-point-gui.de/basic/ this link and able to understand how floating point calculation happens and all however 4 count different is unexpected.

Please help me understand below things

• Is this correct first
• Does always float gives wrong numbers ??
• As I can see double also use same technique, so how much guarantee we have to get correct result if we use double

Answer 1

Does always float gives wrong numbers ??

it depend on the number if the number can be represented using the float precision then it will be fine

"As I can see double also use same technique, so how much guarantee we have to get correct result if we use double"

double has same issue but since double has more precision the possibility get lower but it still happen

so when you need a very precise result like in scientific or financial app you will need to use BigDecimal

watch this video it explain how the float point number work https://www.youtube.com/watch?v=ajaHQ9S4uTA

Answer 2

Is this correct first

The Java float format is IEEE-754 binary32. In this format, every finite number is represented as a sign, a 24-bit integer, and a scaling by a power of two from 2⁻¹⁴⁹ to 2¹⁰⁴. The integer part is called the significand. (The format is often described as a sign, a 24-bit number with a binary point after the first bit, so it has a value in [0, 2), and a scaling from 2⁻¹²⁶ to 2¹²⁷. These are mathematically equivalent, and the format used here is noted in the IEEE-754 standard as an option.) In normal form, the 24-bit integer is 2²³ or greater. (Representable numbers less than 2⁻¹²⁶ cannot be represented in normal form and are necessarily subnormal.)

In this format, 590 can be represented as +590•2⁰ or +8,339,456•2⁻¹⁴. 490 is +490•2⁰ or +16,056,320•2⁻¹⁵.

Their product is +289,100•2⁰ or +9,251,200•2⁻⁵.

391 is +391•2⁰ or +12,812,288⁻¹⁵.

The ordinary arithmetic product of +289,100•2⁰ and +391•2⁰ is +113,038,100•2⁰. However, 113,038,100 is not a 24-bit number; it is a 27-bit number. To get it under 2²⁴, we can adjust the scaling, multiplying the significand by ⅛ and multiplying the scaling by 8 = 2³.

That gives us +14,129,762.5•2³. However, now the significand is not an integer. This result is not representable in the float format. To produce a result, the operation of adding in the float format is defined to round the ordinary arithmetic to the nearest representable value. In this case, there is a tie, we could round the .5 up or down. Ties are resolved by rounding to make the low digit even, so we round to +14,129,762•2³.

+14,129,762•2³ is 113,038,096. That is the result you got, so it is correct.

Does always float gives wrong numbers ??

This is not wrong; the computer behaved according to its specification.

Observe float is a 32-bit format, but there are infinitely many real numbers. There are even infinitely many rational numbers. It is impossible for a 32-bit format to produce the same results as theoretical real-number arithmetic or rational-number arithmetic. There are simply more possible results than there are representable values.

This is true of the 64-bit double format as well. It is also true of integer formats, fixed-precision formats, and all numerical formats with a fixed number of bits. A fixed number of bits cannot represent infinitely many values.

Your comments suggest you thought floating-point would produce approximate results for fractional values, numbers less than one. But the limitation on how many values can be represented applies at all scales. At each scale (each power of two), only 2²⁴ values are representable (2²³ in normal form). For scale 2⁰, all the non-negative integers below 2²⁴ are representable. But, above that, only some of the integers are representable. At first, we have to skip every second integer, then every fourth, then every eighth, and so on.

Floating-point arithmetic is designed to approximate real-number arithmetic. It should be used when you want to approximate real-number arithmetic. It should not be used, with rare exceptions, when you want exact arithmetic.