programming forums Java Java JSRs Mobile Certification Databases Caching Books Engineering OS Languages Paradigms IDEs Build Tools Frameworks Products This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
Sheriffs:
Saloon Keepers:
Bartenders:

# How Autoboxing is going here?

Kishor Joshi
Ranch Hand
Posts: 674
Hi there

This is my code

its Output is

false
false

I am expecting

true
false

Why is this output?

Thanks

Tushar Goel
Ranch Hand
Posts: 934
4
Hi Kishore, due to rounding errors we don't directly compare floats and double values. We use compareTo for
the same. like below:

Double.compare(x2, y2) == 0
a2.compareTo(b2) == 0

Paul Clapham
Sheriff
Posts: 22828
43
I don't think it's that -- I think it's something to do with the special value which you get when you divide zero by zero as double values. Have a look at Roedy Green's page about Java "gotchas" and search for the part where he talks about "divide by zero".

Tushar Goel
Ranch Hand
Posts: 934
4
Thanks Paul. Link shared by you seems to be good. In that link it is mentioned that

Because there are two different flavours of NAN, Double.POSITIVE_INFINITY and Double.NEGATIVE_INFINITY
You can’t directly compare == Double.NAN to check for NAN. However, you can directly compare == Double.NAN;
However, you can use Double.isNaN or == to compare with Double.POSITIVE_INFINITY.

and i have doubt in this line:

You can’t directly compare == Double.NAN to check for NAN. However, you can directly compare == Double.NAN;

Paul Clapham
Sheriff
Posts: 22828
43
Tushar Goel wrote:and i have doubt in this line:

You can’t directly compare == Double.NAN to check for NAN. However, you can directly compare == Double.NAN;

My explanation is that the author was typing too fast and not proofreading enough, or something like that! However there's a phrase a bit later which contains the information which is relevant to the OP's question:

The theory is making NaN not equal to itself...

Campbell Ritchie
Marshal
Posts: 56536
172
Tushar Goel wrote: . . .
Because there are two different flavours of NAN, Double.POSITIVE_INFINITY and Double.NEGATIVE_INFINITY
You can’t directly compare == Double.NAN to check for NAN. However, you can directly compare == Double.NAN;
However, you can use Double.isNaN or == to compare with Double.POSITIVE_INFINITY.

. . .

No, because that does not make sense. A NaN and XXX_INFINITY are different. You can see their values in the Double class: 1 2 3. The documentation even tells you what the bit patterns are (in hex), so you don't need to use the constant fields values link. There are not two flavours of NaN (not NAN); in double arithmetic there are actually 2⁵² − 2 different flavours of NaN but Java® defaults to using only one of them. The apparently strange behaviour of NaN is described in the Java® Language Specification: it tells you here (6th •) that dividing 0.0 by 0.0 (or 0.0f by 0.0f) gives you NaN and it tells you here (1st •) how the equality operator works on NaNs.
You can use the == operator on NaNs and it always returns false. Note that the Double#equals method is not equivalent to the == operator. Try this:-You need the cast in line 8 otherwise it won't compile; nan2 will be boxed from double to Double. Also try equality between 0.0 and −0.0 with == and Double#equals.

Campbell Ritchie
Marshal
Posts: 56536
172
A few minutes ago, I wrote: . . . there are actually 2⁵² − 2 different flavours of NaN . ..
I might be mistaken; there might be 2⁵³ − 2 different flavours of NaN.

Tushar Goel
Ranch Hand
Posts: 934
4
You can use the == operator on NaNs and it always returns false. Note that the Double#equals method is not
equivalent to the == operator.

Thanks, i am completely un-aware of this.

Campbell Ritchie
Marshal
Posts: 56536
172
I hadn't noticed you were using == on reference types in the original post. That of course produces completely different behaviour.

Tushar Goel
Ranch Hand
Posts: 934
4
OP used == for primitive type 'double' as well.

Campbell Ritchie
Marshal
Posts: 56536
172
You're right; he used them for both. Avoid mixing the two because the rules about which is boxed and which is unboxed are difficult to remember. It says “convertible to numeric type” in the Java® Language Specification, so the wrapper would be unboxed.

Tushar Goel
Ranch Hand
Posts: 934
4
Yup thanks

Kishor Joshi
Ranch Hand
Posts: 674
Thanks to all of you very good discussion
A lot of points clear