-3

I have created a 2D array to store double values,on executing the below code the decimal range of some values are getting modified unexpectedly !

package learnJavaProj;
public class SquareRootin2D {

public static void main(String[] args) {

    double [][] arr = new double[10][10];
    double f= 0.00;
    double g=0.00;

    for(int i=0;i<10;i++)
    {
        for(int j=0;j<10;j++)
        {
            arr[i][j]=0.00;
        }
    }

    for (int i=0;i<10;i++)
    {
        arr[i][0]=f;
        arr[0][i]=g;
        g=g+0.10;
        f++;
    }
    for(int i=0;i<10;i++)
    {
        for(int j=0;j<10;j++)
        {
            System.out.print(arr[i][j]+"     ");
        }
        System.out.println("\n");
    }
}

}

Output :

0.0     0.1     0.2     0.30000000000000004     0.4     0.5     0.6     0.7  0.7999999999999999     0.8999999999999999     

1.0     0.0     0.0     0.0     0.0     0.0     0.0     0.0     0.0     0.0     

2.0     0.0     0.0     0.0     0.0     0.0     0.0     0.0     0.0     0.0     

3.0     0.0     0.0     0.0     0.0     0.0     0.0     0.0     0.0     0.0     

4.0     0.0     0.0     0.0     0.0     0.0     0.0     0.0     0.0     0.0     

5.0     0.0     0.0     0.0     0.0     0.0     0.0     0.0     0.0     0.0     

 6.0     0.0     0.0     0.0     0.0     0.0     0.0     0.0     0.0     0.0     

 7.0     0.0     0.0     0.0     0.0     0.0     0.0     0.0     0.0     0.0     

 8.0     0.0     0.0     0.0     0.0     0.0     0.0     0.0     0.0     0.0     

 9.0     0.0     0.0     0.0     0.0     0.0     0.0     0.0     0.0     0.0     

This kind of fluctuation appeared while using float too ! Kindly explain this chaos. Thank You !

Paul R
  • 208,748
  • 37
  • 389
  • 560
Abdul Khader
  • 79
  • 1
  • 7
  • See [IEEE 754](https://en.wikipedia.org/wiki/IEEE_754). – Turing85 Jun 27 '18 at 16:36
  • [What Every Computer Scientist Should Know About Floating-Point Arithmetic](https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html) – azurefrog Jun 27 '18 at 16:37
  • @EricPostpischil Please do not speak about `javascript` if the code in question is clearly `java`. – Turing85 Jun 27 '18 at 16:50
  • @Turing85: Yes, I mistook the language, but the same rule applies in Java. – Eric Postpischil Jun 27 '18 at 16:51
  • 1
    @EricPostpischil I have no Idea what you are talking about. The question is in my opinion a duplicate of said question. The reasoin is aforementioned IEEE 754. In fact, the sampel given in [the duplicate](https://stackoverflow.com/questions/588004/is-floating-point-math-broken) is one sample of OPs question. Why do you think it is not a duplicate? – Turing85 Jun 27 '18 at 16:55
  • @Turing85: The reason is **not** IEEE 754. Nothing in IEEE 754 requires that 0.3 be printed as “0.3” or that the result of .1+.2 be printed as “0.30000000000000004”. Those are choices made by the language, and those choices cause calculations that appear simple to have complicated answers. When somebody asks about some particular Java behavior, you do not respond with an answer for “Is Java broken?” that just says Java does all sorts of things that people do not expect, so just live with it. You answer the **specific question**. While IEEE 754 is **involved** here, it is not the answer. – Eric Postpischil Jun 27 '18 at 17:00
  • @EricPostpischil First off, the duplicate is tagged as "language-agnostic", thus it does not say "Java is broken". Second, reading and understanding said question answers OP's question. Third: if the values were printed with their exact values, OP would still have the same question. The form how Java prints the values is not the core of the problem. But who am I to judge without a gold badge... – Turing85 Jun 27 '18 at 17:10
  • @Turing85: I did not say the original was tagged as Java. I was giving a hypothetical example: If somebody asked a question about Java, nothing to do with floating-point, you would not tell them, well, Java behaves in strange ways for complicated reasons, so it might look broken to you, but here are a bunch of papers about it. It is too generic an answer and is too discouraging an answer. When somebody asks a question about Java, you explain the particular Java feature or rules involved. Why is floating-point treated differently? Answer the specific question. – Eric Postpischil Jun 27 '18 at 17:14
  • @Turing85: No, reading and understanding the purported original and the references it links to does not answer OP’s question. As I wrote, nothing in IEEE 754 causes printing `0.1+0.2` to appear as “0.30000000000000004”. It does cause `0.1+0.2` to have the result 0.3000000000000000444089209850062616169452667236328125, but it does not make that result appear as “0.30000000000000004” while another appears as “0.3”. Reading all the material about IEEE 754 would not answer that because it is a **language choice**. It does not happen the same way in C. – Eric Postpischil Jun 27 '18 at 17:16

1 Answers1

1

Java does not display floating-point values exactly by default. The default is to display just enough digits to uniquely distinguish the value.

The result of this is that some values may be displayed as “0.1” and “0.2”, but they have small differences from exactly 0.1 and 0.2. When they are added, those differences combine and become larger. Then the sum is different from 0.3 by enough that distinguishing it from the value that is displayed as “0.3” requires using “0.30000000000000004”.

When 0.1 is used in source code, it is converted to 0.1000000000000000055511151231257827021181583404541015625, which is the nearest value to 0.1 that is representable in IEEE-754 basic 64-bit binary floating-point. Similarly, 0.2 becomes 0.200000000000000011102230246251565404236316680908203125, and 0.3 becomes 0.299999999999999988897769753748434595763683319091796875.

When you add those two values for 0.1 and 0.2, the computed result is 0.3000000000000000444089209850062616169452667236328125. Since this value is not 0.299999999999999988897769753748434595763683319091796875, it must be printed as “0.30000000000000004” to distinguish it.

Eric Postpischil
  • 195,579
  • 13
  • 168
  • 312