• Post Reply Bookmark Topic Watch Topic
  • New Topic

Casting  RSS feed

 
Shanti sharma
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.



Note that with both float and double is it impossible to store the value 2.3 exactly.
 
Shanti sharma
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 344
Java Linux Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A Java float is stored as a 32-bit value, whereas a double is stored as a 64-bit value.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.




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
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Okay. Got it.
Thanks a lot guys for helping me out.
Cheers
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
author
Sheriff
Posts: 23295
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.



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 ...



should work. And it doesn't.

Henry
 
Henry Wong
author
Sheriff
Posts: 23295
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the info Henry. It sorted my doubts regarding this issue.
Thanks a lot
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ...



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
Marshal
Posts: 56518
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 21131
87
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:It is difficult to ensure good error messages when writing a compiler an application.

Fixed that for you
 
Campbell Ritchie
Marshal
Posts: 56518
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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. . . 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
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Marshal
Posts: 56518
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think we all mean the same, but simply have different ways to express it.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!