# I want to use a TreeSet, but my compare method isn't consistent with equals.

Nick George
Ranch Hand
Posts: 815
First off, let me post the (simplified) code to a Node:

What I want is a TreeSet such that there are no two elements with the same location (i.e. (x,y)), but sorted by the 'f' value (cost+h=f, TreeSet sorted by f... can anyone guess the algorithm I'm taking a stab at?). As it is now, my list continues to grow endlessly adding multiple points for which a.equals(b)==true, because (just a guess here) a.compareTo(b)!=0. Now, it would seem to me that a TreeSet ought not to have multiple things for which .equals returns true, but if they implemented that with compareTo, so be it. Any pointers?
[ May 01, 2004: Message edited by: Joseph George ]
[ May 01, 2004: Message edited by: Joseph George ]

Ranch Hand
Posts: 1873
Hi Joseph,

and see if it works.
The logic here is the just same you think,
1. If object is equal to some object Set must not put it. ie. we must return 0 to indicate that to the Set implementation
2. If object in not equal than we have to return result besed on the order we want (I guess that is the current impl you have in compareTo())...
See if it solves your problem
Regards
Maulin

Ranch Hand
Posts: 1873
Hi Joseph,
Finally I wrote this sample to say what I want...

Regards
Maulin

Nick George
Ranch Hand
Posts: 815
What you post makes alot of sense. I implemented compareTo as you suggested, and I even made a little test like yours with my Node, and it passed with flying colors. However, (And I have the output to prove it!), in the context of my program, I have a TreeSet printing out the following list:
[(-11,-17,0.0), (-12,-17,1.0), (-11,-18,1.0), (-11,-16,1.0), (-10,-17,1.0), (-12,-18,1.4), (-12,-16,1.4), (-10,-18,1.4), (-10,-16,1.4), (-13,-17,2.0), (-11,-19,2.0), (-11,-17,2.0), (-11,-15,2.0), (-10,-16,2.0), (-9,-17,2.0), (-13,-18,2.4), (-13,-16,2.4), (-12,-19,2.4), (-12,-15,2.4), (-11,-18,2.4), (-11,-16,2.4), (-10,-19,2.4), (-10,-17,2.4), (-10,-15,2.4), (-9,-18,2.4), (-9,-16,2.4), (-13,-19,2.8), (-13,-17,2.8), (-13,-15,2.8), (-11,-19,2.8), (-11,-17,2.8), (-11,-15,2.8), (-9,-19,2.8), (-9,-17,2.8), (-9,-15,2.8), (-14,-17,3.0), (-13,-16,3.0)]
The crazy part is that when I put those same nodes into the test program, it will only accept one of them, yet here it is, the very same class, with all three accepted. How is this possible?
Now, I know i'm being a bit vague, but the problem is that to post any more code would be extremely difficult, as the the Node is a very small part of a rather large project. Even to post the class that it is encapsulated in would be extremely difficult, as it refers to various interfaces, is called upon by an entirely differnt class, etc...
[ May 02, 2004: Message edited by: Joseph George ]

Ranch Hand
Posts: 1873
Hi Joseph,
Is there a threading in your code? There could be the problem of synchronization.
Look at the TreeSet API to know more about how we can synch the treeset.
One easy way is,
SortedSet s = Collections.synchronizedSortedSet(new TreeSet(...));
as per the API.
Try making that TreeSet synchronized and see if it gives you correct results. If it does then it means there is some threading somewhere hidden or aparent.
Regards
Maulin

Nick George
Ranch Hand
Posts: 815
I don't beleive multiple threads should be accessing the TreeSet, but even if they were, what difference would it make? If thread a tires to put it in, even if a duplicate was put in by thread b, it should still not accept it. It's either there or it isn't. but i will try syncronizing it.
Just synced it, and am still getting faulty output. I really hope this isn't just a case of me doing something stupid and wasteing everyone's time...
[ May 02, 2004: Message edited by: Joseph George ]

Ranch Hand
Posts: 1873
Hi Joseph,
At this point I am not sure what could be going wrong and as you stated its difficult to post your code so I guess we are in deadlock
Any other brilliant mind have ideas?
Regards
Maulin

Stefan Wagner
Ranch Hand
Posts: 1923
In 'Effektiv Java programmieren' (Joshua Bloch, Effective Java Programming) I read:
If two Objects are equal to the method 'equals', the call to 'hashCode' has to return the same value for both objects.
compareTo and equals need to be consistent too.
But compareTo depends on f,
equals depends on x, y
and hashCode only on x.

Nick George
Ranch Hand
Posts: 815
the hash code method i am using depends on x and y, and as such is consistent with equals.