from <<Java Puzzlers>> Puzzle 32: Curse of Looper
there's a paragraph saying:

In release 5.0, autoboxing and auto-unboxing were added to the language. If you are unfamiliar with them see: http://java.sun.com/j2se/5.0/docs/guide/language/autoboxing.html [Boxing]. The <= operator is still antisymmetric on the set of primitive numeric values, but now it applies to operands of boxed numeric types as well. (The boxed numeric types are Byte, Character, Short, Integer, Long, Float, and Double.) The <= operator is not antisymmetric on operands of these types, because Java's equality operators (== and !=) perform reference identity comparison rather than value comparison when applied to object references.

i can understand why the <= operator is antisymmetric on the set of primitive numeric values, because a <=b can't imply b <= a in all cases, like 3<=5 can't imply 5<=3, so it's antisymmetric.
but i can't understand why is the <= operator not antisymmetric on operands of boxed numeric types, can it prove new Integer(1) <= new Integer(2) and also new Integer(2) <= new Integer(1) ?

The reason is right there in what you quoted: because Java's equality operators (== and !=) perform reference identity comparison rather than value comparison when applied to object references.

If you read the definition of antisymmetric relation on Wikipedia you see this:

R is antisymmetric precisely if for all a and b in X
if R(a,b) and R(b,a), then a = b,

So are there any cases in Java, using Autoboxing, where a <= b, and b <= a, but a != b? Is so, then <= is not possibly antisymmetric for Integers. So let's give it a try:

Steve

drac yang
Ranch Hand

Joined: Apr 19, 2013
Posts: 61

posted

0

Jeff Verdegan wrote:The reason is right there in what you quoted: because Java's equality operators (== and !=) perform reference identity comparison rather than value comparison when applied to object references.

thanks, initially i didn't know the definition of the antisymmetric, i thought antisymmetric means if R(a,b), then R(b,a) must not hold. so it just confused me.

drac yang
Ranch Hand

Joined: Apr 19, 2013
Posts: 61

posted

0

Steve Luke wrote:If you read the definition of antisymmetric relation on Wikipedia you see this:

R is antisymmetric precisely if for all a and b in X
if R(a,b) and R(b,a), then a = b,

thank you very much, your definition of antisymmetric helped a lot.

In mathematics, a binary relation R on a set X is antisymmetric if there is no pair of distinct elements of X each of which is related by R to the other. More formally, R is antisymmetric precisely if for all a and b in X

if R(a,b) and R(b,a), then a = b,

or, equivalently,

if R(a,b) with a ≠ b, then R(b,a) must not hold.

then if either of the two conditions failed, it should not be called antisymmetric, right? this one if R(a,b) and R(b,a), then a = b is not true, although this one if R(a,b) with a ≠ b, then R(b,a) must not hold is true.

drac yang wrote:...if either of the two conditions failed, it should not be called antisymmetric, right? this one if R(a,b) and R(b,a), then a = b is not true, although this one if R(a,b) with a ≠ b, then R(b,a) must not hold is true.

The two statements are the same, they are just stated in reverse order. The first one is positive, so it is easier to prove, which is why I used it. But the second statement also fails the same way. It says f R(a,b) is true, and a is not equal to b, the R(b,a) must be false. In my scenario, the 'order' relationship is true and the equality is false, so to be antisymmetric, the 'anti_order' relationship must be false. But it is not, so this rule fails, just like the positive rule.

drac yang
Ranch Hand

Joined: Apr 19, 2013
Posts: 61

posted

0

Steve Luke wrote:
The two statements are the same, they are just stated in reverse order. The first one is positive, so it is easier to prove, which is why I used it. But the second statement also fails the same way. It says f R(a,b) is true, and a is not equal to b, the R(b,a) must be false. In my scenario, the 'order' relationship is true and the equality is false, so to be antisymmetric, the 'anti_order' relationship must be false. But it is not, so this rule fails, just like the positive rule.

yeah, thanks for correcting mine.

after you pointed out, i rechecked it carefully, i should notice it says "equivalently" which has the very enough implication.

and also look into it, if a binary relation R on a set X is antisymmetric, it's supposed to behave like this. if R(a,b) and R(b,a), which seems not antisymmetric, only resulted from no distinct elements of X, i.e. from the elements of the same value. just like the formal definition suggested: if there is no pair of distinct elements of X each of which is related by R to the other.

thanks.

With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.

subject: why is the <= operator not antisymmetric on operands of boxed numeric types