Why to mention 'f' while initialization float value but not in case of int in ?

[Tushar Goel]

Hi All,

I have general question: When we initialize value for both int and float then int works well when we assigned its to the byte but when doing the same thing for the float then it gives error.

class Initialization
{
   public static void main(String... args){
 
      byte b = 10;
      float c = 10.0;
    }
}

It gives compilation error:

Initialization.java:6: possible loss of precision
found : double
required: float
float c = 10.0;
^
1 error

If i used 10.0f then its works well...

float c = 10.0f ;


Can anyone explain this behavior?

[E Armitage]

The default type for integer literals is int and the default type for floating pint literals is double. These decisions were made by the language authors for convenience.
Values of the integral types byte, short, int, and long can be created from int literals. Assigning a double to a float can result in loss of precision so the compiler won't allow you to do it unless you explicitly down cast to float with the f or a cast.

You can learn more about the datatypes here: http://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html

[Tushar Goel]

Yeah right Armitage but why it is working for int case? By default integer literal are int and of 4 byte and i am assigning it to the byte which is 1 byte and it works well. It should also give same error as float is giving..

Are you getting my point??

[E Armitage]

Tushar Goel wrote:
Yeah right Armitage but why it is working for int case? By default integer literal are int and of 4 byte and i am assigning it to the byte which is 1 byte and it works well. It should also give same error as float is giving..

Are you getting my point??

I said above that

Values of the integral types byte, short, int, and long can be created from int literals.

[Matthew Brown]

In other words, although 10 is an int literal, the compiler is smart enough to tell that it will fit into a byte. Change it to too big a value and you should see different behaviour. Change it to an int value that isn't a compile-time constant and you'll also get an error.

[Tushar Goel]

Can you please throw some light on this:

Values of the integral types byte, short, int, and long can be created from int literals? << I am unable to get this statement..

Do you mean that we use int literals in byte,short.. ? If that your mean that i have tried to assigned int value to the byte it give precision loss error..

[E Armitage]

Tushar Goel wrote:
Can you please throw some light on this:

Values of the integral types byte, short, int, and long can be created from int literals? << I am unable to get this statement..

Do you mean that we use int literals in byte,short.. ? If that your mean that i have tried to assigned int value to the byte it give precision loss error..

The compiler doesn't like it when you ask it to automatically downcast (assigning a value from a wider type to a narrower reference ) values. If you want to downcast you have to explicitly tell the compiler that you are happy to do this and are willing to take the risks of the lost precision. Sometimes the compiler is smart enough to figure out that a downcast definitely won't lose precision e.g with

byte b = 127;

but then it stops you from doing

byte b = 128;

[Tushar Goel]

Agreeing to the point "compiler doesn't like it when you ask it to automatically downcast" but as you already mentioned "compiler is smart enough to figure out that a downcast definitely won't lose precision" is there any particular condition in which compiler think like tis way.. Or what i think in case of float mantissa comes into the picture. I read some where that for float values are stored in exponential form. Will it playing any role in this strange behavior?

[E Armitage]

The automatic downcasts are only allowed for some integral values not for floating point literals.

[Tushar Goel]

Got your point.. Thanks..

[Stuart A. Burkett]

Tushar Goel wrote:but as you already mentioned "compiler is smart enough to figure out that a downcast definitely won't lose precision" is there any particular condition in which compiler think like tis way.

Are you asking why the compiler is clever enough to know that 10 will fit into a byte variable, but not clever enough to know that 10.0 can be represented accurately in a float variable ?
If so, then it is probably because the values that will fit into a byte are finite and contiguous (-127 to 128) and so easy to verify.
But the values that will fit into a float are not contiguous - 10.0, 10.5 and 11.0 can be accurately represented by a float or double, but the representation of 10.1 (for example) will be less accurate in a float than it is in a double.
So, in order to verify that an assignment will not lose accuracy, the compiler would have to maintain a list of every possible value that can be represented precisely by a float.
This is obviously not feasible, so the compiler designers chose to make it illegal to assign any double value to a float without an explicit cast.

[Tushar Goel]

Thanks Stuart... Yeah i was wondering the same .. It is cleared to me now.. Thanks to you..

Actually my prof asked me the same question and i was not cleared why it was happening this way...

[Henry Wong]

Stuart A. Burkett wrote:
Are you asking why the compiler is clever enough to know that 10 will fit into a byte variable, but not clever enough to know that 10.0 can be represented accurately in a float variable ?
If so, then it is probably because the values that will fit into a byte are finite and contiguous (-127 to 128) and so easy to verify.
But the values that will fit into a float are not contiguous - 10.0, 10.5 and 11.0 can be accurately represented by a float or double, but the representation of 10.1 (for example) will be less accurate in a float than it is in a double.

Simply, it is defined that way in the JLS -- see section 5.2 ... http://docs.oracle.com/javase/specs/jls/se7/html/jls-5.html#jls-5.2

See the section regarding compile time constants (and keep in mind, that this section applies to assignments). Also, note that the compile time constant clause does not apply to long, in addition to not applying to any of the floating point primitive types -- meaning you can't implicitly cast a 10L literal to an int, even though it is easy to confirm that it fits at compile time.

Henry