In Java, we can convert an int to float implicitly, which may result in loss of precision as shown in the example code below.
public class Test {
public static void main(String [] args) {
int intVal = 2147483647;
System.out.println("integer value is " + intVal);
double doubleVal = intVal;
System.out.println("double value is " + doubleVal);
float floatVal = intVal;
System.out.println("float value is " + floatVal);
}
}
The output is
integer value is 2147483647
double value is 2.147483647E9
float value is 2.14748365E9
What is the reason behind allowing implicit conversion of int to float, when there is a loss of precision?
You are probably wondering:
Why is this an implicit conversion when there is a loss of information? Shouldn't this be an explicit conversion?
And you of course have a good point. But the language designers decided that if the target type has a range large enough then an implicit conversion is allowed, even though there may be a loss of precision. Note that it is the range that is important, not the precision. A float has a greater range than an int, so it is an implicit conversion.
The Java specification says the following:
A widening conversion of an int or a long value to float, or of a long value to double, may result in loss of precision - that is, the result may lose some of the least significant bits of the value. In this case, the resulting floating-point value will be a correctly rounded version of the integer value, using IEEE 754 round-to-nearest mode.
Converting an integer type to a floating point type that uses the same number of bits may result in a loss of precision, but will be done automatically.
"Loss of precision" means that some of the less significant digits may become zeros, but the most important digits and the size of the number will remain. Recall that float has only about seven decimal digits of precision. For example, converting the int 123456789 to a float 123456700.0 shows a loss of precision.
Related
How does the output turn out to be '1'?
long number = 499_999_999_000_000_001L;
double converted = (double) number;
System.out.println(number - (long) converted);
TLDR: It's because of overflow bits
If you check java documentation Double.MAX_VALUE. You will observe that max double integer value supported by java is 2^53 ≅ 10^16 but your value becomes (4.99999999 * 10^17) after typecasting which is outside the range of double so because of overflow it is rounded. For better understanding run this code.
public class Main
{
public static void main(String[] args) {
long longNumber = 499_999_999_000_000_001L;
double doubleNumber = (double) longNumber;
long longConverted = (long)doubleNumber;
System.out.println(longNumber+" "+doubleNumber+" "+longConverted);
}
}
Its output will be:
499999999000000001 4.99999999E17 499999999000000000
All you need to do is a little "debugging".
Try running this code...
long number = 499_999_999_000_000_001L;
System.out.println(number);
double converted = (double) number;
System.out.println(converted);
System.out.println((long) converted);
System.out.println(number - (long) converted);
This is what it displays...
499999999000000001
4.99999999E17
499999999000000000
1
Do you want to know why the conversion back to long from double drops the 1?
If you do then I refer you to the java specifications.
EDIT
To be precise, refer to section Widening Primitive Conversion
A widening primitive conversion from ... long to double, may result in loss of precision - that is, the result may lose some of the least significant bits of the value. In this case, the resulting floating-point value will be a correctly rounded version of the integer value, using IEEE 754 round-to-nearest mode (§4.2.4).
All integer literals are treated as int in java and floating point literals are treated as double in java.
Then why does
byte b =10;
does not give any error but
float f = 10.0;
gives a loss of precision error when in both cases down-casting takes place?
In the case of int to byte, there's no real concern about a loss of precision, because both types have the same degree of granularity. You'll get an error if you try to convert a literal with a value outside the range of byte to byte. (The error message given in that case is slightly misleading.)
In the case of double to float, you can have a constant value which is in the right range, but still lose precision. In your specific case of 10.0, the value can be represented exactly in both float and double, but that's not the case in general.
As an example of that, consider this:
float f = (float) 10.1; // Or float f = 10.1f;
double d = 10.1;
System.out.println(f == d); // Prints false
That's because precision is being lost in the conversion from double tofloat - neither type can represent 10.1 exactly, but double gets close to it than float does. The == operator will mean f is converted back to a double, with a different value to d.
This question already has answers here:
Why does Java implicitly (without cast) convert a `long` to a `float`?
(4 answers)
Closed 8 years ago.
if you call the following method of Java
void processIt(long a) {
float b = a; /*do I have loss here*/
}
do I have information loss when I assign the long variable to the float variable?
The Java language Specification says that the float type is a supertype of long.
Do I have information loss when I assign the long variable to the float variable?
Potentially, yes. That should be fairly clear from the fact that long has 64 bits of information, whereas float has only 32.
More specifically, as float values get bigger, the gap between successive values becomes more than 1 - whereas with long, the gap between successive values is always 1.
As an example:
long x = 100000000L;
float f1 = (float) x;
float f2 = (float) (x + 1);
System.out.println(f1 == f2); // true
In other words, two different long values have the same nearest representation in float.
This isn't just true of float though - it can happen with double too. In that case the numbers have to be bigger (as double has more precision) but it's still potentially lossy.
Again, it's reasonably easy to see that it has to be lossy - even though both long and double are represented in 64 bits, there are obviously double values which can't be represented as long values (trivially, 0.5 is one such) which means there must be some long values which aren't exactly representable as double values.
Yes, this is possible: if only for the reason that float has too few (typically 6-7) significant digits to deal with all possible numbers that long can represent (19 significant digits). This is in part due to the fact that float has only 32 bits of storage, and long has 64 (the other part is float's storage format † ). As per the JLS:
A widening conversion of an int or a long value to float, or of a long value to double, may result in loss of precision - that is, the result may lose some of the least significant bits of the value. In this case, the resulting floating-point value will be a correctly rounded version of the integer value, using IEEE 754 round-to-nearest mode (§4.2.4).
By example:
long i = 1000000001; // 10 significant digits
float f = i;
System.out.printf(" %d %n %.1f", i, f);
This prints (with the difference highlighted):
1000000001
1000000000.0
~ ← lost the number 1
It is worth noting this is also the case with int to float and long to double (as per that quote). In fact the only integer → floating point conversion that won't lose precision is int to double.
~~~~~~
† I say in part as this is also true for int widening to float which can also lose precision, despite both int and float having 32-bits. The same sample above but with int i has the same result as printed. This is unsurprising once you consider the way that float is structured; it uses some of the 32-bits to store the mantissa, or significand, so cannot represent all integer numbers in the same range as that of int.
Yes you will, for example...
public static void main(String[] args) {
long g = 2;
g <<= 48;
g++;
System.out.println(g);
float f = (float) g;
System.out.println(f);
long a = (long) f;
System.out.println(a);
}
... prints...
562949953421313
5.6294995E14
562949953421312
This is the snippet of code in Java:
int i = 1234567890;
float f = i;
System.out.println(i - (int)f);
Why is that the output is not equal to 0? It performs widening, so it is not supposed to loose data. Then you just truncate the value.
Best regards
See the difference
int i = 1234567890;
float f = i;
System.out.println(i - f);
System.out.println((int)f);
System.out.println(f);
System.out.println(i-(int)f);
Ouput:
0.0
1234567936
1.23456794E9
-46
Your mistake is here:
It performs widening, so it is not supposed to loose data.
This statement is wrong. Widening does not mean that you do not lose data.
From the Java specification:
Widening primitive conversions do not lose information about the overall magnitude of a numeric value.
Conversion of an int or a long value to float, or of a long value to double, may result in loss of precision - that is, the result may lose some of the least significant bits of the value. In this case, the resulting floating-point value will be a correctly rounded version of the integer value, using IEEE 754 round-to-nearest mode (§4.2.4).
Emphasis mine.
The specification clearly states that the magnitude is not lost, but precision can be lost.
The word widening refers not to the precision of a data type, but to its range. Floats are wider than ints because they have a larger range.
int
4 bytes, signed (two's complement). -2,147,483,648 to 2,147,483,647.
float
4 bytes, IEEE 754. Covers a range from 1.40129846432481707e-45 to 3.40282346638528860e+38 (positive or negative).
As you can see, float has a larger range. However some integers cannot be represented exactly as floats. This representation error is what causes your result to differ from 0. The actual value stored in f is 1234567936.
You'd be shocked to find out that even this can be true:
(f==(f+1))==true
given f is a float large enough...
int i = 1234567890;
float f = i;
System.out.println((int)f);
System.out.println(i);
System.out.println(i - (int)f);
output is:
1234567936
1234567890
-46
see the difference.
compare integer float have larger value.
Widening can lose precision. An int has 32-bits of precision where as a float has a 25-bits of precision (a 24-bit mantissa and an implied top bit). Java considers float to be wider than the 64-bit long which is a bit mad IMHO
With an 8-bit difference in precision, the error can be up to about +/-64 as it rounds the int value to the nearest float representation.
int err = 0;
for (int i = Integer.MAX_VALUE; i > Integer.MAX_VALUE / 2; i--) {
int err2 = (int) (float) i - i;
if (Math.abs(err2) > err) {
System.out.println(i + ": " + err2);
err = Math.abs(err2);
}
}
prints
... deleted ...
2147483584: 63
2147483456: -64
Can someone explain how typecasting works in the line int y = (int) x;
Thank You
public class typecast
{
public static void main(String [] args)
{
double x=10.5;
int y=(int) x;
System.out.println("x="+x);
System.out.println("y="+y);
}
}
The type cast performs a narrowing type conversion. The exact conversion depends on the double value, as follows:
If it is within the range of int values, it is rounded towards zero.
If it outside of the range or is an "Inf" value, then the conversion gives Integer.MIN_VALUE or Integer.MAX_VALUE, depending on the sign.
If it is a "NaN" value, the conversion gives zero.
Reference: JLS 5.1.3
Note: "round towards zero" is defined as follows:
"The Java programming language uses round toward zero when converting a floating value to an integer (§5.1.3), which acts, in this case, as though the number were truncated, discarding the mantissa bits. Rounding toward zero chooses at its result the format's value closest to and no greater in magnitude than the infinitely precise result."
In this particular case, the code won't compile if you try and take a double (variable x) and assign it's value to an int (variable y). So you have to explicitly tell the compiler to cast (convert) the type from a double to an int. When it does that, in this particular case, I believe it drops the fractional part instead of rounding up/down. I could be wrong about that last point.