equality and null pointers

[CodeForTea]

in fact, you provide an example of use of what I was talking about...

Here is some code showing equals and hascode that you can implement in
your calsses. [snip]
if (name == null) {
if (other.name != null)
return false;
} else if (!name.equals(other.name))
return false;

This piece of code is more or less equivalent to calling my
"areEqual(name, other.name)" (except that I prefer my version, sorry).

So basically, you're answering my need for factorization with "don't
factorize, write it".

Thanks all the same
JR

public class Utils {
public static boolean areEqual(Object obj1, Object obj2) {
return (obj1 == null) ? (obj2 == null) : (obj1.equals(obj2));
}



}
I fail to see how this helps. Why do you need two methods to compare
an object when one will do? You call the equals method in your
areEqual method.

Dinesh

 

[Larry Barowski]

Why would one want NaN to equal NaN? Doesn't that violate the fundamental
meaning of NaN?

The last time I ran into it was indirectly. I was developing a
Java debugger that highlights fields when their values
change. Naively using com.sun.jdi.DoubleValue.equals()
for comparison of old and new values resulted in float
and double NaN values that were always highlighted after
their first appearance.

Also, in addition to what Jaakko pointed out, you may want
them to be considered equal for sorting purposes (where
you also need to use a different < or > comparison to
compare NaN to non-NaN).

In any case where floating point numbers can be NaN,
you need to watch out for:

if(x > y)
...
else if(x < y)
...
else
// Wrongly assume x == y in all cases here.

 

[Lew]

The last time I ran into it was indirectly. I was developing a
Java debugger that highlights fields when their values
change. Naively using com.sun.jdi.DoubleValue.equals()
for comparison of old and new values resulted in float
and double NaN values that were always highlighted after
their first appearance.

As you say, "naively" using. The fault, dear Caesar, lies not in our NaNs,
but in ourselves.

Also, in addition to what Jaakko pointed out, you may want
them to be considered equal for sorting purposes

You may want them to be, but they aren't.

(where you also need to use a different < or > comparison to
compare NaN to non-NaN).

In any case where floating point numbers can be NaN,
you need to watch out for:

if(x > y)
...
else if(x < y)
...
else
// Wrongly assume x == y in all cases here.

That error is the programmer's. The programmer should not wrongly assume x ==
y in all cases, as you point out.

The very definition of NaN is that it is not comparable to any number, and
that it is not equal to any number.

a numeric comparison operation involving one or two NaNs returns false and any != comparison involving NaN returns true, including x!=x when x is NaN.

Its purpose is to represent the value of "an operation that has no
mathematically definite result". If it's not mathematically definite, it
can't be compared and it can't be equal.

So the right way to code it would be

if ( x > y )
{ ... }
else if ( x < y )
{ ... }
else if ( x == y )
{ ... }
else
{ ... }

 

[visionset]

You may want them to be, but they aren't.


The very definition of NaN is that it is not comparable to any number, and
that it is not equal to any number.

Its purpose is to represent the value of "an operation that has no
mathematically definite result". If it's not mathematically definite, it
can't be compared and it can't be equal.

Lew you certainly are a Programmer.

 

[Larry Barowski]

You may want them to be, but they aren't.

I think you are responding to something I have not written.
They are considered equal for sorting purposes, by
java.lang.Double for example.

That error is the programmer's. The programmer should not wrongly assume
x == y in all cases, as you point out.

I never implied otherwise. I was not arguing that primitive NaNs
should compare as equal by the == operator, as you seem to be
assuming. I didn't think I gave that impression, but perhaps I was
not 100% clear.

 

[Lew]

I never implied otherwise. I was not arguing that primitive NaNs
should compare as equal by the == operator, as you seem to be
assuming. I didn't think I gave that impression, but perhaps I was
not 100% clear.

More likely I wasn't 100% listening.

If I understand you correctly, you want for certain purposes like sorting to
put all NaNs in the same bucket.

You could write a Comparator for Doubles that treats NaN the way you want,
then use
<http://java.sun.com/javase/6/docs/a...ml#sort(java.util.List, java.util.Comparator)>

 

[julien.robinson2]

I fail to see how this helps. Why do you need two methods to compare
an object when one will do? You call the equals method in your
areEqual method.

Dinesh

Hi, I feel like we're talking at right angles here.

Let me try to explain...
I was asking about code factorization. It's a piece of code that I
write very often*, and it's (very) good practice in that case to
factorize, i.e. write it only once and then call it.

You answered me with some equals() code.
1. the "equals" method itself does not address my problem, because I
was speaking about 2 pointers that may both be null... and you can't
call "equals" on a null pointer
2. inside your "equals" method was a part (that I quoted) that looked
like what I was doing, so I assumed that was what you were talking
about, and answered that.

Hope this clears it up. If not, it's just a slight miscomprehension,
no great deal.

The answer to your last question is:
.. I use the "equals" method, only one method, when I'm sure I have a
non-null pointer to call it on
.. the other method is for pointers that I'm not sure are null or not
.. I call "areEqual" in "equals" because that's factorization (avoiding
to write the same code again and again).

JR
* this was before recounting the votes of course