Bug in java.lang.FLOAT?

You should use the methods floatValue () and doubleValue () to print the values wrapped by objects of Float, Double, etc.

Float obj = new Float ( 398381.91 ) ;
System.out.println ( obj.doubleValue () ) ;

Floating-point values are single-precision type, that's why you get that result.

Mayank.

mruff:
This old question needs to be finalized -- accept an answer, split points, or get a refund.  For information on your options, please click here-> http:/help/closing.jsp#1 
EXPERTS:
Post your closing recommendations!  No comment means you don't care.

>> You should use the methods floatValue () and doubleValue () to print the values wrapped by objects of Float, Double, etc.

>> Float obj = new Float ( 398381.91 ) ;
>> System.out.println ( obj.doubleValue () ) ;

This comment does not explain why the questioner is having the problem.


>>Floating-point values are single-precision type, that's why you get that result.

This comment is a repeat of what I had said.


Therefore, I should get the points since my comment is correct.

Are we fighting for points here? If so, then please go ahead and give all points to yongsing

Anyways, yongsing, I have a question for you. Try this in C (Turbo C preferably):

float a = 0.6 ;

if ( a < 0.6 )
  printf ( "Lesser " ) ;
else
  printf ( "Not lesser. " ) ;

a = 0.7 ;

if ( a < 0.7 )
  printf ( "Lesser " ) ;
else
  printf ( "Not lesser. " ) ;


Mayank.

What's the point? My first comment recommended using the BigDecimal class for true precision, and this will fix the question's problem.

No no.... just for the sake of experimentation and fun - try it once.... its not got to do anything with this question.... just a problem in C.

I know that your code will give some unexpected result, but I don't have a C compiler now, and it's been a while since I've done any C programming. Sorry to disappoint you. :-(

Yes, it will. Actually, the problem happens because of the 0.6 and 0.7 constants in the if () condition. In the if condition, the 'a' is a float, whereas the 0.6 and 0.7 values on the right-hand-side of the inequality are treated as doubles by default. Turns out, there is a temporary type-conversion, which results in loss of precision - in Turbo C, after values starting from 0.645299 - this value differs for gcc and other compilers. Turns out, the values smaller than this one are converted with full precision and the values greater than this are not but there is loss in precision while converting bigger values. So, ( a < 0.6 ) still gives false as expected because here, the precision is maintained, but ( a < 0.7 ) gives true because here, the precision is lost. So the output you get is:

Not Lesser.
Lesser.

Though you were expecting:

Not Lesser.
Not Lesser.

So how do we go about fixing it? To avoid the type-conversion, declare 'a' as double - in that case, there is no temporary type-conversion and so no loss in precision. In that case, the output you get is:

Not Lesser.
Not Lesser.

Another way to do it is by using the constants 0.6f and 0.7f instead of 0.6 and 0.7 respectively, in the RHS of the if () condition's inequality.

if ( a < 0.6f )

and

if ( a < 0.7f )

Then the output will again be:

Not Lesser.
Not Lesser.

Its always better to use 'double', in fact, because you never know when such constants come into expressions and there is some kind of loss of precision which drives you mad and you'll never be able to figure out what went wrong!

But of course, this code in Java will give a compilation error saying: 'Possible loss of precision'. Man, that's why I love that language! It makes sure that you don't make many mistakes which go unnoticed in C/ C++.

Cheers,
Mayank.

No comment has been added lately, so it's time to clean up this TA.
I will leave a recommendation in the Cleanup topic area that this question is:

- Points to yongsing

Please leave any comments here within the next seven days.

PLEASE DO NOT ACCEPT THIS COMMENT AS AN ANSWER!

girionis
EE Cleanup Volunteer