Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

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

 
drac yang
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 4181
21
IntelliJ IDE Java Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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:

 
drac yang
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 63
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 4181
21
IntelliJ IDE Java Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 63
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic