Gagan, This is more about the limitations on the way a float is stored than it is about the limitations on an int I believe. If I remember correctly a float is stored in 32 bits as a characteristic and a mantissa with each alotted a certain number of bits.
Now if you try that code with a double instead of a float I think it will retain the precision when you go to reassign it back to an int. A double will alot more bits for the mantissa and characteristic.
Conformity is the jailer of freedom and the enemy of growth.
Joined: Aug 23, 2005
Range for int is -2,147,483,648 to 2,147,483,647 & the number which i am assinging 123,456,789 to int very variable is very much with in this range. I don't know why you had asked me this ? Did you want to suggest anything else? Also thanks for suggestion on how to keep the formating of the code. i did nt know that from now i will use these buttons.
Dave, i got your point but any idea after what number it starts give this issue. Means till what number "System.out.println(intNumber == x );" will return 0.
Any one has more suggestion on this ?
Joined: Dec 30, 2005
That's the rub. It really depends how a float/double is stored. As I understand the requirements of the test we don't have to know how floats are stored. We do have to know their range of values. I have no clue at what number this starts to become a problem for floats or doubles. If this is a question on the test I'm calling my congressman.
If my analysis is correct, floats can exactly represent every int in the range -16777215 to +16777215. Outside that range they are susceptible to rounding error.
In a float, you have 32 bits. One bit is used for sign information. 8 bits are used for exponent information. The remaining 23 bits are used for mantissa information. 16777215 is the largest 23-bit unsigned integer.
For further study, you can have a look at the J2SE javadoc for the Float class, particularly the intBitsToFloat method. Also, you can play with this educational toy...
Joined: Feb 07, 2006
Hold the phone...my analysis was sloppy. The largest 23-bit unsigned integer is 8388607. So, floats can exactly represent integers in the range -8388607 to +8388607. Outside that range they are susceptible to rounding error (like me.)
The first integer at which assigning to float and casting back to int loses precision is : 16777217. The following code when run, gives the output as: =========================================================================
========================================================================= i = 16777217 i = -16777217
Floating points are first converted to form : N = � (1.b1b2b3b4 ...)2 x 2+E The left most one is not stored(always 1). The bits b1b2b3 etc.,(upto 23 bits) is what goes into the mantissa part. Hence, the first maximum bit for an integer can be 24 successive one's. (23 One's for mantissa and one implicit 1). 24 successive one corresponds to the number : 16777215. The next number is 16777216 for which the bit pattern is : 1000000000000000000000000 ie., one followed by 24 zero. So, even though the 24th zero is not stored, precision is not lost. Because when we convert back it is restored. So, the maximum integer without losing precision that can be converted back from float is now : 16777216
Now, if we consider the next number (16777217) for which the bit pattern is : 1000000000000000000000001. This has 1 followed by 23 zeros and then a 1. Because of 1 in the 24th bit, the 23rd bit will be rounded to 1 and the first precision loss comes for this number. Thus, the number 16777217 is the first integer number which when converted to float and converted back to integer will lose the precision as proved by the output of the above code.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com