1

Can someone please explain me that in java why 

     if(0.6 <= 0.6f ) System.out.printf("true");
     else System.out.printf("false");

this PRINTS true but

    if(0.7 <= 0.7f ) System.out.printf("true");
    else  System.out.printf("false");

this PRINTS false

Is it related to IEEE 754 standards when floating point number is converted to double for comparision?

can someone explain it in detail the exact working?

Kara
  • 6,115
  • 16
  • 50
  • 57
user2410495
  • 13
  • 1
  • 3
  • 2
    What's with the "is" part in your code? – w4etwetewtwet May 22 '13 at 17:37
  • This has to do with the way that floating-point numbers are stored in Java. If you want precise numbers, use the class java.math.BigDecimal. – gparyani May 22 '13 at 17:37
  • 1
    Does it actually compile? Never ever seen `is` in Java used that way. – zneak May 22 '13 at 17:38
  • The short answer is that floating-point numbers are not represented precisely. If you need to compare floats to each other, use `BigDecimal`. – Henry Keiter May 22 '13 at 17:39
  • 3
    @HenryKeiter: floating point numbers *are* represented precisely in themselves - they're just not a precise representation of a value such as 0.7. It's the conversion from 0.7 to "the closest `double` representation" which is losing information. Note that BigDecimal is also a floating-point type - it's just that it's a floating *decimal* point instead of a floating *binary* point. – Jon Skeet May 22 '13 at 17:43
  • @JonSkeet Yes, sorry for my imprecision. I meant what you said :) – Henry Keiter May 22 '13 at 17:45
  • If 0.6 and 0.6f were the same value why would you need two literals? ;) – Peter Lawrey May 22 '13 at 18:24

1 Answers1

14

Sure - it's just a matter of understanding that none of 0.6, 0.6f, 0.7 and 0.7f are those exact values. They're the closest representable approximations in the appropriate type. The exact values which are stored for those 4 values are:

0.6f => 0.60000002384185791015625
0.6  => 0.59999999999999997779553950749686919152736663818359375
0.7f => 0.699999988079071044921875
0.7  => 0.6999999999999999555910790149937383830547332763671875

With that information, it's clear why you're getting the results you are.

To think of it another way, imagine you had two decimal floating point types, one with 4 digits of precision and one with 8 digits of precision. Now let's look at how 1/3 and 2/3 would be represented:

1/3, 4dp => 0.3333
1/3, 8dp => 0.33333333
2/3, 4dp => 0.6667
2/3, 8dp => 0.66666667

So in this case the lower-precision value is smaller than the higher-precision one for 1/3, but that's reversed for 2/3. It's the same sort of thing for float and double, just in binary.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • Thank you . I understand that ,but how can i simply tell what will be the result by just looking at the code ? – user2410495 May 23 '13 at 07:14
  • @user2410495: You can't just do it by inspection, unless you're able to do the maths in your head to work out what the binary representations will be. Sometimes the nearest `float` will be greater than the nearest `double`, sometimes it'll be smaller. Why is that important to you anyway? – Jon Skeet May 23 '13 at 11:22