aspose file tools*
The moose likes Java in General and the fly likes why is the <= operator not antisymmetric on operands of boxed numeric types Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "why is the <= operator not antisymmetric on operands of boxed numeric types " Watch "why is the <= operator not antisymmetric on operands of boxed numeric types " New topic
Author

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

drac yang
Ranch Hand

Joined: Apr 19, 2013
Posts: 61
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) ?

no, please see the program:



result:
true
false

is there any wrong?

thanks.


science belief, great bioscience!
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

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.
Steve Luke
Bartender

Joined: Jan 28, 2003
Posts: 4181
    
  21

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



Steve Luke
Bartender

Joined: Jan 28, 2003
Posts: 4181
    
  21

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
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.
 
Don't get me started about those stupid light bulbs.
 
subject: why is the <= operator not antisymmetric on operands of boxed numeric types