Widening Conversion

[Kel Walker]

Hi,
R&H states that converting from a long to a float is a widening conversion and, as such, does not require an explicit cast.
A long is 64 bits and a float is 32 bits so how can this be considered a widening conversion?
Could someone please clarify this for me.
Thank you.

[Manfred Leonhardt]

Hi Kel,
Widening and Narrowing are related to the minimum and maximum values that will fit into the reference type.
long:
-2^63 (-9.2e-18) to 2^64 (9.2e18)
float:
-3.4e38 to 3.4e38
Since the float value can hold a much smaller value and much larger value than the long value can it is considered a widening.
Regards,
Manfred.
[ April 30, 2002: Message edited by: Manfred Leonhardt ]

[Corey McGlone]

Note, however, that, even though the range of a float is wider than the range of a long, it is still composed of fewer bits than a long. That means that, even though data won't be lost when converting from a long to a float, you may lose precision. Obviously, since the size of a long is larger than that of a float and the float can handle a larger range of values, there must be some values that a long can hold that a float can not (at least not as precisely).
Just something to keep in mind,
Corey

[Jian Yi]

Corey,
How many digits of precision does a float have?
Thanks,
Jenny

[Corey McGlone]

Originally posted by Jenny Yin:
Corey,
How many digits of precision does a float have?
Thanks,
Jenny

It's not really a question of digits of precision...Check this thread for a more thorough discussion.
I hope that helps,
Corey

[R Arun]

Corey, I read the other thread of discussion too, but would like to explore this "loss of precision" further.
Here is my (apparently flawed) understanding:
It seems to me that the loss of precision is not due to converting from an 8 byte value to a 4 byte value as much as converting from a real number to an integer due to the difference in representations.
Since each and every long value can be represented in a float (am I right here?), what precision is being lost in a conversion from a long to a float? None in my opinion - the float value represents my long value precisely.
However when I attempt to reconvert the float value to a long value, I may lose precision due to the difference in representation of a float and a long.
What am I missing here? The JLS wording (from your quote in the other thread of discussion) very specifically says that you may lose precision in converting from a long to a float, but I dont get it. Perhaps my understanding of the word "precision" is flawed?

[Corey McGlone]

Floating point values are stored in the following format:

Bit 31 (the bit that is selected by the mask 0x80000000) represents the sign of the floating-point number.

Bits 30-23 (the bits that are selected by the mask 0x7f800000) represent the exponent.

Bits 22-0 (the bits that are selected by the mask 0x007fffff) represent the significand (sometimes called the mantissa) of the floating-point number.

If the argument is positive infinity, the result is 0x7f800000.

If the argument is negative infinity, the result is 0xff800000.

If the argument is NaN, the result is 0x7fc00000.

This is known as IEEE 754 floating-point "single precision" bit layout. If you look in the API spec for the Float class, you can find a discussion of this.
However, you should note that only bits 22-0 are available for the mantissa. The value 1234567890, in binary, however, is: 1001001100101100000001011010010. That's 31 bits, which is more than can be held by the mantissa of the floating point representation. What happens is that, when this value is stored in a float, some of the least significant bits are lost and additional data is stored in the more significant bits (32-23) to serve as an exponent. That's where the loss of precision comes into play.
Thinking of it this way helps me:
In Java, ints and floats are both 32 bits. In a 32 bit value, there are a total of 2^32 combinations (or 4294967296). The range of an int goes from -2147483648 to 2147483647, which encompasses exactly 4294967295 values (which, after you add 1 for representing 0), equals exactly the number of distinct combinations you have. Therefore, every value in the range of an int can be represented exactly by an int.
Now, a float, however, has the same number of combinations (2^32), but it has a range that extends roughly from -3.4x10^38 to 3.4x10^38, which is a range of 6.8x10^38. That range is much larger than the number of combinations possible. Therefore, not every value that can be contained in a float is exactly representable by a float. There may be some rounding involved.
I hope that helps clear this up. And, please, if there is a flaw in my logic, someone correct me. This is my understanding of how this works.
Corey

[Corey McGlone]

Oh yeah - by the way, I don't think this is required for the exam. At least not to this extent.
Corey
[ April 30, 2002: Message edited by: Corey McGlone ]

[R Arun]

Yes it does clear it up Corey. Thanks.
The following code snippet proves it as well:

int i0 = 1234567890;
float f0 = i0;
System.out.println("i0 = " + i0);
System.out.println("f0 = " + f0);
int i1 = 1234567894;
float f1 = i1;
System.out.println("i1 = " + i1);
System.out.println("f1 = " + f1);
System.out.println("i0 == i1? " + (i0 == i1));
System.out.println("f0 == f1? " + (f0 == f1));

Produces the output:

i0 = 1234567890
f0 = 1.23456794E9
i1 = 1234567894
f1 = 1.23456794E9
i0 == i1? false
f0 == f1? true

[Corey McGlone]

I just got a copy of Beginning Java (SDK 1.4 Edition) and I found this information about floating point arithmetic, which goes right along with this disucssion:

The number of digits in the mantissa of a floating-point number depends on the type of the floating-point number that you are using. The Java type float provides the equivalent of approximately 7 decimal digits, and the type double provides around 17 decimal digits. The number of digits is approximate because the mantissa is binary, not decimal, and there's not an exact mapping between binary and decimal digits.
Suppose we have a large number such as 2,134,311,179. How does this look as a floating-point number? Well, as a float it looks like:
0.2134311E10
It's not quite the same. We have lost three low order digits so we have approximated our original value as 2,134,311,000. This is a small price to pay for being able to handle such a vast range of numbers, typically from 10^-38 to 10^+38 either positive or negative, as well having an extended representation that goes from a minute 10^-308 to a mighty 10^+308. As you can see, they are called floating-point numbers for the fairly obvious reason that the decimal point "floats" depending upon the exponent value.
Aside from the fixed precision limitation in terms of accuracy, there is another aspect you may need to be concious of. You need to take care when adding or subtracting numbers of significantly different magnitudes. A simple example will demonstrate the kind of problem that can arise. We can first consider adding .365E-3 to .365E+7. We can write this as a decimal sum:
.000365 + 3,650,000
This produces the result:
3.650,000,000.000365
When when converted back to floating point becomes:
.3650000E+7
So we might as well not have bothered. The problem lies directly with the fact that we only carry 7 digits precision. The 7 digits of the larger number are not affected by any of the digits of the smaller number because they are all further to the left. Funnily enough, you must also take care when the numbers are very nearly equal. If you compute the difference between such numbers you may end up with a result that has one or two digits precision. It is quite easy in such circumstances to end up computing with numbers that are total garbage.

Kudos to Mr. Ivor Horton. I hope that helps clear up any further questions about this.
Corey