Casting

[Shanti sharma]

Hi Guys,

I am pretty new to Java. So could you please help me in sorting out my doubt.

When we write byte b = 1;
and print this variable, everything works fine.
But when i say float f = 2.3;
it gives a compile time error.
Why is that?
i know the default value is double and we need to tell the compiler that we are narrowing it down but why this thing does not work in case of byte??

[Jeff Verdegan]

Because the compile-time int constant 1 can be converted to a byte with no loss of precision, but the compile-time double constant 2.3 cannot be converted to a float without losing precision.

float f = 2.3f;
// OR
float f = (float)2.3;

Note that with both float and double is it impossible to store the value 2.3 exactly.

[Shanti sharma]

Hey Jeff,

Thanks for the prompt reply. i want to know what is the difference in 2.3 when stored as float and as double in context of the compiler.

[Koen Aerts]

A Java float is stored as a 32-bit value, whereas a double is stored as a 64-bit value.

[Jeff Verdegan]

Shanti sharma wrote:Hey Jeff,

Thanks for the prompt reply. i want to know what is the difference in 2.3 when stored as float and as double in context of the compiler.

System.out.printf("%.20f%n", 2.3); // double
System.out.printf("%.20f%n", 2.3f); // float

2.30000000000000000000
2.29999995231628400000

For more details, look into IEEE 754 floating point representation, and keep in mind that double has twice as many bits available as float, so its error will be smaller.

[Shanti sharma]

Yes. Similarly, byte datatype is stored as 8 bit value and int is stored as 32 bit value. then why byte does not need a casting when value is within the range and float does need the casting even if the value is as small as 2.3

[Shanti sharma]

Okay. Got it.
Thanks a lot guys for helping me out.
Cheers

[Jeff Verdegan]

Shanti sharma wrote:Yes. Similarly, byte datatype is stored as 8 bit value and int is stored as 32 bit value. then why byte does not need a casting when value is within the range and float does need the casting even if the value is as small as 2.3

As I already said: The int ⇒ byte conversion doesn't lose precision; both store the value 1. But the double ⇒ float conversion loses precision. Neither one can store 2.3 exactly, but float's error is bigger than double's.

[Henry Wong]

Jeff Verdegan wrote:Because the compile-time int constant 1 can be converted to a byte with no loss of precision, but the compile-time double constant 2.3 cannot be converted to a float without losing precision.

float f = 2.3f;
// OR
float f = (float)2.3;

Note that with both float and double is it impossible to store the value 2.3 exactly.

While the "loss of precision" statement is likely true, it isn't the reason. The reason is simply, because the JLS says so. The JLS only allows an implicit cast, for compile time constants, when they fit, for int, short, char, and byte. If the rule is based on loss of precision, then this statement ...

int i = 1L;

should work. And it doesn't.

Henry

[Henry Wong]

BTW, see section 5.2 of the JLS -- about a couple of paragraphs down...

http://java.sun.com/docs/books/jls/third_edition/html/conversions.html#5.2

Henry

[Shanti sharma]

Thanks for the info Henry. It sorted my doubts regarding this issue.
Thanks a lot

[Jeff Verdegan]

Henry Wong wrote:
While the "loss of precision" statement is likely true, it isn't the reason. The reason is simply, because the JLS says so. The JLS only allows an implicit cast, for compile time constants, when they fit, for int, short, char, and byte.

Good point. Rather than looking at the relevant rule in the JLS, I jumped to the reasoning behind it. I assume that the reason the JLS says it's not allowed for double ⇒ float is because of loss of precision.

However, as you point out...

If the rule is based on loss of precision, then this statement ...

int i = 1L;

should work. And it doesn't.

So, while I still believe the loss of precision is the reason for disallowing double ⇒ float, we do seem to have an inconsistency.

[Campbell Ritchie]

Welcome to the Ranch

It appears the wording of the error message is at best imprecise. It is difficult to ensure good error messages when writing a compiler.

[Rob Spoor]

Campbell Ritchie wrote:It is difficult to ensure good error messages when writing a compiler an application.

Fixed that for you

[Campbell Ritchie]

I meant compiler. I suppose it is true for all sorts of applications, however.
What I mean is that when you find yourself with a situation where you have a }, you end up saying “class interface or enum expected” because it is so difficult to work out the real reason is unbalanced {} unless you want lots of lookback and permit the compiler to run very slowly.
Similarly, in this sort of code

int i; // as local variable
if (j > 0)
{
   i = 999;
}
else if (j < 0)
{
   i = 123;
}
else if (j == 0)
{
   i = 456;
}

. . . you will get a might not have been initialised error. It would be too difficult (and intrdouce too much of a performance overhead) to implement lookback to verify that all possibilities are covered and i is in fact initialised. Even though that is obvious to the human eye.

In the instance in this present thread, a message like, “you can’t implicitly cast the double to a float” would probably have been feasible and preferable to what you actually read. Eclipse has a better repertoire of error messages than the sun/Oracle compiler.

[Jeff Verdegan]

Rob Spoor wrote:

Campbell Ritchie wrote:It is difficult to ensure good error messages when writing a compiler an application.

Fixed that for you

Actually, it was true and applicable in the original. (Javac is an application, after all, and it's always hard to ensure good error messages--that's been the topic of most of the bugs on my plate for a few weeks now!)

[Campbell Ritchie]

I think we all mean the same, but simply have different ways to express it.