How does this work?

[Shweta R Dhaneshwar]

For the code below ....can anyone explain me how we get this o/p..please explain lines marked 1,2,3, and 4

public class Test041
    {    
        static double d;
        static float f;
 
        public static void main(String args[])
        {        
            compare(Long.MAX_VALUE,      Long.MAX_VALUE     );
            
            compare(Integer.MAX_VALUE,   Integer.MAX_VALUE  );   //1
            
            compare(Character.MAX_VALUE, Character.MAX_VALUE);   //2
            
            compare(Short.MAX_VALUE,     Short.MAX_VALUE    );  //3
            
            compare(Byte.MAX_VALUE,      Byte.MAX_VALUE     );   //4
        }
 
        static void compare(double d, float f)
        {
            if (f == d) System.out.print(" equal"   );
            else        System.out.print(" unequal");        
        }    
    }

o/p is

D:\Java\EditPlus 2>java Test
equal unequal equal equal equal

[Henry Wong]

Depending on the value, there may be lost of precision when converting an integer or long, to a float or double. Whether they remain equal after converting them to both will depend on how much precision is lost.

Henry

[amit taneja]

depends on what ??

this is not the answer ...

anybody pls give the correct and presise answer ..

that how and on what occassion the value will be lost...


one more thing i would like to ask is that....


long holds 64bits but float contains 32 bits...

and we all say that implicit cast as follow

byte->short->integer->long->float->double

but my question is how long (64 bits) can be implicitely casted to float(32bits) ...
it must loose some value....while doing it...

but how the compiler allows it even without using explicit cast

as we can cast integer to short without cast operater

how long to float is allowed ...i mean on what basis...

=============================

I want one more thing to ask is that what is the maximum value float can store....
and if suppose it allows some values to store..then how many it reserves for values after decimals ?? and if values after decimals are going to use its 32 bits then total maximum value it can store must be less then interger maximum value.. ?? pls do give comments on this too...

[Henry Wong]

depends on what ??

As I mentioned, it depends on the value !! Or to be more specific... whether the fixed (aka "Mantissa") component of the floating point number will fit into the number of bits reserved for it. A int is 32 bits, and while a float is also 32 bits, only 23(???) bits is reserved for the fixed component. So when it is converted, some will be lost. How much will be lost? Well... it depends on the value...

how long to float is allowed ...i mean on what basis...

An implicit cast from long to float is allowed because the float has a larger range. The MAX_VALUE and MIN_VALUE for a float is larger and smaller than the MAX_VALUE and MIN_VALUE for a long respectively. Of course, you do lose information, since you are going from 64 bits to 32 bits. What you lose is precision. Even though a positive float number can get bigger than a long, it doesn't have as many significant bits.

I know this is still confusing... this is not really something that can be explained in a single response. I would suggest you Google "floating point representions" to get more info on the subject.

Henry

[amit taneja]

An implicit cast from long to float is allowed because the float has a larger range. The MAX_VALUE and MIN_VALUE for a float is larger and smaller than the MAX_VALUE and MIN_VALUE for a long respectively. Of course, you do lose information, since you are going from 64 bits to 32 bits. What you lose is precision. Even though a positive float number can get bigger than a long, it doesn't have as many significant bits.

didn't get you much to be honest


regards,

[amit taneja]

any other rancher
have ability to answer the post in clear and simple manner

it would be good to all to know such point...

[Steven Bell]

The implicit cast from one primitive type to another is not concerned with precision. The rules for whether or not a cast is required is determined by considering if the conversion is a 'widening' or 'narrowing' conversion.

Lets look at the value range for the primitive types.

byte -128 to 127
short -32,768 to 32,767
int -2,147,483,648 to 2,147,483,647
long -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807
float 1.40129846432481707e-45 to 3.40282346638528860e+38 (positive or negative)
double 4.94065645841246544e-324d to 1.79769313486231570e+308d (positive or negative)

As we can see the range of values able to be represented increases as we go. However, due to the nature of floating point representation, float and double are not able to represent all values within their range as the integer types can.

When coverting from and integer type (byte, short, int, long) to a floating point type (float, double) there is a good chance there will be some loss of precision especially when you get into the upper and lower ranges (MIN_VALUE and MAX_VALUE) of the integer types.

To understand why requires some understanding of floating point representation, but from a logic though process if a float is 32 bits while a long is 64 bits the float, having a 'wider' range than the long, must be unable to represent some of the numbers within it's range.
[ June 02, 2005: Message edited by: Steven Bell ]

[amit taneja]

Originally posted by Steven Bell:

To understand why requires some understanding of floating point representation, but from a logic though process if a float is 32 bits while a long is 64 bits the float, having a 'wider' range than the long, must be unable to represent some of the numbers within it's range.

[ June 02, 2005: Message edited by: Steven Bell ]

------------------------------------

so the final conclusion is while casting from integer type to floating type
if no. is large some information is going to lost...

and even then it is implicitly castable...
and we ourself must be carefull while puting long to float...

---------------------------------

pls give comment on final conclusion... and other then that it seems bit illogical that compiler give error of warning when narrowing that presion will be lost..
but it not giving error while widening...its just a comment...don't take otherwise..


regards

but do comment on final conclusion and this post

[Steven Bell]

Originally posted by amit taneja:


------------------------------------

so the final conclusion is while casting from integer type to floating type
if no. is large some information is going to lost...

and even then it is implicitly castable...
and we ourself must be carefull while puting long to float...

---------------------------------

pls give comment on final conclusion... and other then that it seems bit illogical that compiler give error of warning when narrowing that presion will be lost..
but it not giving error while widening...its just a comment...don't take otherwise..


regards

but do comment on final conclusion and this post

In short, you have it right.

Something to keep in mind is that working with floating point primitives is inherently non-precise whether or not you are casting to/from integer types.

for example:

public class Count {
  public static void main(String[] args) {
    final float START = 2000000000.0f;
    int count = 0;
    for (float f = START; f < START + 50f; f++){
      count++;
    }
    System.out.println(count);
  }
}

Notice I've been careful to make everything a float so there is no casting taking place.

You may be surprised that this example prints out 0 (as in the for loop never ran). This is due to floating point 'granularity'. At the range of 2000000000.0f a float is unable to represent the difference between 2000000000.0f and 2000000050.0f so it will simply lose the 50.

[amit taneja]

but i still didn't get the answer to the original post ...
regarding equal/ unequal...


can anybody pls explain me