Say I have objects A,B,C,D. They can contain references to one another, for example, A might reference B and C, and C might reference A. I want to create segments but dont want to create them twice, so I don't want segment A C and segment C A, just 1 of them. So I want to keep a list of created segments, ex: A C, and check if I already have an A C or C A and skip it if so.
Is there a data structure that can do this?
Thanks
if(list.contains(a,b)
{
//dont add
}
you may introduce something like
class PairKey<T extends Comparable<T>> {
final T fst, snd;
public PairKey(T a, T b) {
if (a.compareTo(b) <=0 ) {
fst = a;
snd = b;
} else {
fst = b;
snd = a;
}
}
#Override
public int hashCode() {
return a.hashCode() & 37 & b.hashCode();
}
#Override
public boolean equals(Object other) {
if (other == this) return true;
if (!(other instanceOf PairKey)) return false;
PairKey<T> obj = (PairKey<T>) other;
return (obj.fst.equals(fst) && obj.snd.equals(snd));
}
}
then you may put edges into HashSet < PairKey < ? extends Comparable> > and then check if the given pair is already there.
You will need to make your vertexes comparable, so it will be possible to treat PairKey(A,B) equal to PairKey(B,A)
And then HashSet will do the rest for you, e.g you will be able to query
pairs.contains(new PairKey(A,B));
and if pairs contain either PairKey(A,B) or PairKey(B,A) - it will return true.
hashCode implementation might be slightly different, may be IDE will generate something more sophisticated.
Hope that helps.
I would use an object called Pair that would look something like this:
class Pair
{
Node start;
Node end;
public Pair(Node start, Node end)
{
this.start=start;
this.end=end;
}
public Pair reverse()
{
return new Pair(end,start);
}
}
Now you can do something like this:
if(pairs.contains(currentPair) || pairs.contains(currentPair.reverse())
{
continue;
} else{
pairs.add(currentPair);
}
As pointed out in the comments, you will need to implement equals and hashcode. However, doing the check in equals to make it match the reversal of the segment is a bad practice in a pure OO since. By implementing equals in the fashion, described within the comments, would bind Pair to your application only and remove the portability of it.
You can use a set of sets of objects.
Set<Set<MyObjectType>> segments = new HashSet<Set<MyObjectType>>();
Then you can add two-element sets representing pairs of MyObject. Since sets are unordered, if segments contains a set with A and B, attempting to add a set containing B and A will treat it as already present in segments.
Set<MyObjectType> segment = new HashSet<MyObjectType>();
segment.add(A); // A and B are instances of MyObjectType
segment.add(B);
segments.add(segment);
segment = new HashSet<MyObjectType>();
segment.add(B);
segment.add(A);
segments.add(segment);
System.out.println("Number of segments: " + segments.size()); // prints 1
Your problem is related with graph theory.
What you can try is to remove that internal list and create a Incidence Martrix, that all you objects share.
The final solution mostly depend of the task goal and available structure. So is hard to choose best solution for you problem with the description you have provided.
Use java.util.Set/ java.util.HashSet and keep adding the references you find e.g.
Set set1 = new HashSet();
set1.add(A), set1.Add(C), set1.Add(C)
You can add this finding in an external set, as finalSet.add(set1)
Set<Set> finalSet = new HashSet<Set>();
finalSet.add(set1);
This will filter out the duplicates automatically and in the end, you will be left with A & C only.
Related
Hello guys I have two entities connected with each other with a relationship, like this:
Entity A is known to entity B, and entity B knows entity A.
Which is the most efficient data structure that I can use in order to maintain this information?
I was think of having 2 hashmaps with key the entity's A key and value a list for each B entity that knows about A, and another one with key entity B's key etc. But I was wondering if I can use just one data structure.
I am aiming for performance in speed rather than space, so it doesn't matter if it's big as long as it's fast.
Why are you want to use a Datastructure?
It is a "normal" bidirectional association between the two objects.
class A {
B b;
....
// Perhaps you can do somthinkg like this to maintain consitsncy
void setB(B b) {
this.b = b;
b.a = a;
}
class B {
A a;
....
}
Given that you've mentioned the focus is on speed, this really comes down to how you need to acess the data, ie what question do you need to ask of the data structure.
For example, if you only need to ask the question, "does X know about Y", or "does Y know about X" then you only need one hash map. or hash set,
as long as you can produce a decent hashCode() implementation for a pair of them
(see further before for a sample hashCode implementation though probably not a good one and it's been many years since I used Java)
ie with a set
class Item extends Pair {
Item(A,B)
// override hashCode() and equals() methods as necessary
}
hashset<Item> relationships;
relationships.add(new Item(A,B))
relationships.add(new Item(B,C))
if( ! relationship.contains (new Item(B,A)))
// print "b does not know a"
or a map:
HashMap<Item,Boolean> relationships;
relationships.put(Item(A,B),True)
....
but, if you need to look at one entity and then find all the things that it knows about, then a graph structure is better.
If you're building a one time data set that doesn't need much flexibility You can implement a graph as a single linked list though, containing all edges from a starting point, and have a hash (by object key) pointing to the first edge in each list of known items.
For example, untested pseudocode, not correct java
Class Item {
Entity first
Entity second
Item next;
Item prior;
Item(x,y) { first = x; second = y; }
Item Join(nextItem) {
next = nextItem; next.prior = this; return next;
}
// override hashCode and equals() but don't use 'next' or prior as part of the hash calculation or equals comparison
//this is just for example, not sure if this is a good hash
long hashCode() { return a. hashCode() & b.hashCode(); }
}
class Graph extends HashSet<Item> {
Bool containsRelationship(Entity x, Entity y) {
return contains(new Item(x,y))
}
Bool isRcognisedEntity(Entity x) {
return contains(new Item(x,x))
}
Item getRelationships(Entity x) {
Item ret = get(new Item(x,x))
if ret is not null
return ret.next // return the first entity x knows, other than itself
else
return null // nothing known
}
Item addEntity(Entity e, Entity[] e_knows) {
Item first = new item (e,e)
add(first)
Item lastItem = first
for k in e_knows
lastItem = lastItem.join(new item(e,k))
add(lastItem)
return first
}
}
Entity a;
Entity b;
Entity c;
Graph g;
g.addEntity(a, {b,c})
g.addEntity(b, {c})
g.addEntity(c,{ a,b,c})
if g.contains(item(a,b))
Print "a knows b"
c_knows = g.getRelationships(c)
while c_knows is not null
Print "c knows " + c_knows.second
c_knows = c.next
So you see this way with just one Set, you can ask "does x know y" and also "who does x know", at the expense of some memory overhead from the next/prior attributes (you might only need one)
If instead of a common Entity base class, you have two separate classes A and B, then you could do this instead with Object, and cast the results as necessary, within routines of the Graph class to provide type safety.
For example
class Item {
Object first;
Object second;
...
}
class Graph {
// as above except use Object instead of Entity, and make the methods protected not public
}
class ABGraph extends Graph {
Iterator getRelationships(A a) {
return new B_Itemterator(super.getRelationships(a));
}
void addRelationships(A a,B[] b_knows) {
super.getRelationships( a, b_knows)
}
// Similar functions for B
}
class A_ItemIterator implements Java.collections...Iterator<A> {
A_ItemIterator(Item i) { this.i = I }
bool hasNext() { return i.next != null; }
A next() { item n = i.next; I = n; return n; }
}
// similar iterator class for B_ItemIterator
ABGraph g;
A a;
B b1;
B b2;
g.addRelationships(a, new B[]{b1,b2})
if g.contains (a,b1) // should still work
Iterator<B> i= g.getRelationships(a)
while(i.hasNext())
print " thing "+ a + " of type A knows about " + b.next() + "of type B'
Say I have class called MyClass as follow:
public class MyClass
{
//Identifier is alpha-numeric. If the identifier starts will 'ZZ'
//is special special identifier.
private String identifier = null;
//Date string format YYYY-MM-DD
private String dateString = null;
//Just a flag (not important for this scenario)
private boolean isCoolCat = false;
//Default Constructor and getters/setters implemented
//Overrides the standard Java equals() method.
//This way, when ArrayList calls contains() for MyClass objects
//it will only check the Date (for ZZ identifier)
//and identifier values against each other instead of
//also comparing the isCoolCat indicator value.
#Override
public boolean equals(Object obj)
{
if(this == obj)
{
return true;
}
if(obj == null)
{
return false;
}
if(getClass() != obj.getClass())
{
return false;
}
MyClass other = (MyClass) obj;
if(this.identifier == null)
{
if(other.identifier != null)
{
return false;
}
} else if(!this.identifier.equals(other.identifier)) {
return false;
}
if(other.identifier.startsWith("ZZ"))
{
if(!this.dateString.equals(other.dateString))
{
return false;
}
}
return true;
}
}
In another class I have two List of MyClass type, each contain 100,000 objects. I need to check if items in one list are in the other list and I currently accomplish this as follow:
`
List<MyClass> inList = new ArrayList<MyClass>();
List<MyClass> outList = new ArrayList<MyClass>();
inList = someMethodForIn();
outList = someMethodForOut();
//For loop iterates through inList and check if outList contains
//MyClass object from inList if it doesn't then it adds it.
for(MyClass inObj : inList)
{
if(!outList.contains(inObj))
{
outList.add(inObj);
}
}
My question is: Is this the fastest way to accomplish this? If not can you please show me a better implementation that will give me a performance boost? The list size is not always going to be 100,000. Currently on my platform it takes about 2 minutes for 100,000 size. Say it can vary from 1 to 1,000,000.
You want to use a Set for this. Set has a contains method which can determine if an object is in the set in O(1) time.
A couple things to watch out for when converting from List<MyClass> to Set<MyClass>:
You will lose the ordering of the elements
You will lose the duplicate elements
Your MyClass needs to implement hashcode() and equals(), and they should be consistent.
To convert your List to Set you can just use:
Set<MyObject> s1 = new HashSet<>(inList);
Set<MyObject> s2 = new HashSet<>(outList);
This Java doc explains how to find the union, intersection, and difference of two sets. In particular, it seems like you're interested in the Union:
// transforms s2 into the union of s1 and s2. (The union of two sets
// is the set containing all of the elements contained in either set.)
s2.addAll(s1)
Hashing ! Hashing is always the answer !
Current complexity of this code is, O(nm) where n is the size of inList and m is the size of outList.
You can use a HashSet to reduce your complexity to O(n). Because contains will now take O(1)
This can be done like this,
HashSet<MyClass> outSet = new HashSet<>(outList);
for(MyClass inObj : inList)
{
if(!outSet.contains(inObj))
{
outList.add(inObj);
}
}
Credits and Sources.
returning difference between two lists in java
Time complexity of contains(Object o), in an ArrayList of Objects
HashSet.contains performance
2 minutes comparing 2 very large lists, probably not going to get much time savings here, so depending on your application, can you set a flag so that things dependant on this cannot run until finished and push this into it's own thread and let the user do something else (while also telling them this is on-going.) Or at least put up a progress bar. Letting the user know the app is busy and telling them (ish) how long it will take on something only taking a few minutes in a very complex computation like this is OK and probably better than just shaving a few seconds off the time. users are quite tolerant of delays if they know how long they will be and you tell them there is time to go get a coffee.
So, I don't know if there is an elegant solution to this but here goes. I want to sort a list but the list contains three types of items. What i want is for type A to be on top sorted alphabetically, type B & C to be on the bottom and sorted alphabetically (type B & C will be combined).
Here is my code:
public int compareTo(Friendship another) {
if(this.getType().equals(TypeA) &&
another.getType().equals(TypeA)){ //if they are both type A, just sort based on user name
return this.getUsername().compareTo(
another.getUsername());
}
else if(this.getType.equals(TypeA)){
return -1;
}
else if(another.getType().equals(TypeA)){
return 1;
}
else{ //this will be hit if they are either Type B or C, then just sort based on username
return this.getUsername().compareTo(
another.getUsername());
}
}
EDIT: sorry, I should have explained this a lot better. The problem is that the above code isn't working. From what I am seeing, the list doesn't seem to be properly ordered.
The TypeA list is for some reason ordered opposite of what I want( Z -> A). And the TypeB & C list is only half sorted. So I am assuming that there is a bug in my code. Let me know if you need more info.
EDIT2: Did some more tests on samples and it looks like the strings aren't being sorted at all. I did both
this.getUsername().compareTo(
another.getUsername());
and
another.getUsername().compareTo(
this.getUsername());
EDIT 3: you guys were right. there was a mistake elsewhere in my code (that was unrelated). Sorry... also don't really know what to do in this case. Who do I give the right answer to?
If i be you, i won't change structure, but only optimize this little bit
public int compareTo(Friendship another) {
if(!this.getType().equals(another.getType()){
//if type are not equal, so we might have at most one A
if(this.getType.equals(TypeA)){ //on left side
return -1;
}
if(another.getType().equals(TypeA)){ //or, on rightside
return 1;
}
}
//or we have on both sides or neither side
return this.getUsername().compareTo(
another.getUsername());
}
I use a similar solution in the same situation, and I think it is good.
But code can be shorter:
public int compareTo(Friendship another) {
boolean thisOnTop = getType().equals(TypeA);
boolean anotherOnTop = another.getType().equals(TypeA);
if (thisOnTop != anotherOnTop) {
return thisOnTop ? -1 : 1;
} else {
return this.getUsername().compareTo(another.getUsername());
}
}
You just have to implement your compareTo in the 3 classes with that logic you said. Something like this:
// TypeA.class
// TypeA class will have priority over the other two, so just sort by whatever you want
public int compareTo(AnotherType anotherType) {
if (this.equals(anotherType)) // TypeA vs TypeA - alphabetically
return this.getUsername().compareTo(anotherType.getUsername());
else // otherwise typeA is greater
return 1; // 1 means greater than
}
// TypeB.class
public int compareTo(AnotherType anotherType) {
if (this.equals(anotherType)) // both typeB, sort alphabetically
return this.getUsername().compareTo(anotherType.getUsername());
else
if(this.equals(typeC)) // TypeB vs TypeC, alphabetically
return this.getUsername().compareTo(typeC.getUsername());
else // TypeB vs TypeA
return -1; // -1 means lesser than
}
//TypeC.class
public int compareTo(AnotherType anotherType) {
if (this.equals(anotherType)) // TypeC vs TypeC - alphabetically
return this.getUsername().compareTo(anotherType.getUsername());
else
if(this.equals(typeB)) // TypeC vs TypeB - alphabetically
return this.getUsername().compareTo(typeB.getUsername());
else
return -1; // -1 means lesser than
}
There is an elegant way to solve this, and it does not involve ugly compareTo trainwrecks.
Pass through your list and make 2 SortedSet, one for A and one for B + C. Add your Friendships based on their Type.
Make a new list and use Collections.addAll() method to appent to the list the 2 arrays you can get from the 2 SortedSet, first the one for A, then the one for B+C.
Since SortedSet will keep the contents in natural order, which is lexicographical for strings, your final list will have Type A first, sorted lexicographically, B and C after, also sorted lexicographically.
Why cannot I retrieve an element from a HashSet?
Consider my HashSet containing a list of MyHashObjects with their hashCode() and equals() methods overridden correctly. I was hoping to construct a MyHashObject myself, and set the relevant hash code properties to certain values.
I can query the HashSet to see if there "equivalent" objects in the set using the contains() method. So even though contains() returns true for the two objects, they may not be == true.
How come then there isn’t any get() method similar to how the contains() works?
What is the thinking behind this API decision?
If you know what element you want to retrieve, then you already have the element. The only question for a Set to answer, given an element, is whether it contains() it or not.
If you want to iterator over the elements, just use a Set.iterator().
It sounds like what you're trying to do is designate a canonical element for an equivalence class of elements. You can use a Map<MyObject,MyObject> to do this. See this Stack Overflow question or this one for a discussion.
If you are really determined to find an element that .equals() your original element with the constraint that you must use the HashSet, I think you're stuck with iterating over it and checking equals() yourself. The API doesn't let you grab something by its hash code. So you could do:
MyObject findIfPresent(MyObject source, HashSet<MyObject> set)
{
if (set.contains(source)) {
for (MyObject obj : set) {
if (obj.equals(source))
return obj;
}
}
return null;
}
It is brute-force and O(n) ugly, but if that's what you need to do...
You can use HashMap<MyHashObject, MyHashObject> instead of HashSet<MyHashObject>.
Calling containsKey() on your "reconstructed" MyHashObject will first hashCode() - check the collection, and if a duplicate hashcode is hit, finally equals() - check your "reconstructed" against the original, at which you can retrieve the original using get()
Complexity is O(1) but the downside is you will likely have to override both equals() and hashCode() methods.
It sounds like you're essentially trying to use the hash code as a key in a map (which is what HashSets do behind the scenes). You could just do it explicitly, by declaring HashMap<Integer, MyHashObject>.
There is no get for HashSets because typically the object you would supply to the get method as a parameter is the same object you would get back.
If you know the order of elements in your Set, you can retrieve them by converting the Set to an Array. Something like this:
Set mySet = MyStorageObject.getMyStringSet();
Object[] myArr = mySet.toArray();
String value1 = myArr[0].toString();
String value2 = myArr[1].toString();
The idea that you need to get the reference to the object that is contained inside a Set object is common. It can be archived by 2 ways:
Use HashSet as you wanted, then:
public Object getObjectReference(HashSet<Xobject> set, Xobject obj) {
if (set.contains(obj)) {
for (Xobject o : set) {
if (obj.equals(o))
return o;
}
}
return null;
}
For this approach to work, you need to override both hashCode() and equals(Object o) methods
In the worst scenario we have O(n)
Second approach is to use TreeSet
public Object getObjectReference(TreeSet<Xobject> set, Xobject obj) {
if (set.contains(obj)) {
return set.floor(obj);
}
return null;
}
This approach gives O(log(n)), more efficient.
You don't need to override hashCode for this approach but you have to implement Comparable interface. ( define function compareTo(Object o)).
One of the easiest ways is to convert to Array:
for(int i = 0; i < set.size(); i++) {
System.out.println(set.toArray()[i]);
}
If I know for sure in my application that the object is not used in search in any of the list or hash data structure and not used equals method elsewhere except the one used indirectly in hash data structure while adding. Is it advisable to update the existing object in set in equals method. Refer the below code. If I add the this bean to HashSet, I can do group aggregation on the matching object on key (id). By this way I am able to achieve aggregation functions such as sum, max, min, ... as well. If not advisable, please feel free to share me your thoughts.
public class MyBean {
String id,
name;
double amountSpent;
#Override
public int hashCode() {
return id.hashCode();
}
#Override
public boolean equals(Object obj) {
if(obj!=null && obj instanceof MyBean ) {
MyBean tmpObj = (MyBean) obj;
if(tmpObj.id!=null && tmpObj.id.equals(this.id)) {
tmpObj.amountSpent += this.amountSpent;
return true;
}
}
return false;
}
}
First of all, convert your set to an array. Then, get the item by indexing the array.
Set uniqueItem = new HashSet();
uniqueItem.add("0");
uniqueItem.add("1");
uniqueItem.add("0");
Object[] arrayItem = uniqueItem.toArray();
for(int i = 0; i < uniqueItem.size(); i++) {
System.out.println("Item " + i + " " + arrayItem[i].toString());
}
If you could use List as a data structure to store your data, instead of using Map to store the result in the value of the Map, you can use following snippet and store the result in the same object.
Here is a Node class:
private class Node {
public int row, col, distance;
public Node(int row, int col, int distance) {
this.row = row;
this.col = col;
this.distance = distance;
}
public boolean equals(Object o) {
return (o instanceof Node &&
row == ((Node) o).row &&
col == ((Node) o).col);
}
}
If you store your result in distance variable and the items in the list are checked based on their coordinates, you can use the following to change the distance to a new one with the help of lastIndexOf method as long as you only need to store one element for each data:
List<Node> nodeList;
nodeList = new ArrayList<>(Arrays.asList(new Node(1, 2, 1), new Node(3, 4, 5)));
Node tempNode = new Node(1, 2, 10);
if(nodeList.contains(tempNode))
nodeList.get(nodeList.lastIndexOf(tempNode)).distance += tempNode.distance;
It is basically reimplementing Set whose items can be accessed and changed.
If you want to have a reference to the real object using the same performance as HashSet, I think the best way is to use HashMap.
Example (in Kotlin, but similar in Java) of finding an object, changing some field in it if it exists, or adding it in case it doesn't exist:
val map = HashMap<DbData, DbData>()
val dbData = map[objectToFind]
if(dbData!=null){
++dbData.someIntField
}
else {
map[dbData] = dbData
}
I am trying to optimize a piece of code which compares elements of list.
Eg.
public void compare(Set<Record> firstSet, Set<Record> secondSet){
for(Record firstRecord : firstSet){
for(Record secondRecord : secondSet){
// comparing logic
}
}
}
Please take into account that the number of records in sets will be high.
Thanks
Shekhar
firstSet.equals(secondSet)
It really depends on what you want to do in the comparison logic... ie what happens if you find an element in one set not in the other? Your method has a void return type so I assume you'll do the necessary work in this method.
More fine-grained control if you need it:
if (!firstSet.containsAll(secondSet)) {
// do something if needs be
}
if (!secondSet.containsAll(firstSet)) {
// do something if needs be
}
If you need to get the elements that are in one set and not the other.
EDIT: set.removeAll(otherSet) returns a boolean, not a set. To use removeAll(), you'll have to copy the set then use it.
Set one = new HashSet<>(firstSet);
Set two = new HashSet<>(secondSet);
one.removeAll(secondSet);
two.removeAll(firstSet);
If the contents of one and two are both empty, then you know that the two sets were equal. If not, then you've got the elements that made the sets unequal.
You mentioned that the number of records might be high. If the underlying implementation is a HashSet then the fetching of each record is done in O(1) time, so you can't really get much better than that. TreeSet is O(log n).
If you simply want to know if the sets are equal, the equals method on AbstractSet is implemented roughly as below:
public boolean equals(Object o) {
if (o == this)
return true;
if (!(o instanceof Set))
return false;
Collection c = (Collection) o;
if (c.size() != size())
return false;
return containsAll(c);
}
Note how it optimizes the common cases where:
the two objects are the same
the other object is not a set at all, and
the two sets' sizes are different.
After that, containsAll(...) will return false as soon as it finds an element in the other set that is not also in this set. But if all elements are present in both sets, it will need to test all of them.
The worst case performance therefore occurs when the two sets are equal but not the same objects. That cost is typically O(N) or O(NlogN) depending on the implementation of this.containsAll(c).
And you get close-to-worst case performance if the sets are large and only differ in a tiny percentage of the elements.
UPDATE
If you are willing to invest time in a custom set implementation, there is an approach that can improve the "almost the same" case.
The idea is that you need to pre-calculate and cache a hash for the entire set so that you could get the set's current hashcode value in O(1). Then you can compare the hashcode for the two sets as an acceleration.
How could you implement a hashcode like that? Well if the set hashcode was:
zero for an empty set, and
the XOR of all of the element hashcodes for a non-empty set,
then you could cheaply update the set's cached hashcode each time you added or removed an element. In both cases, you simply XOR the element's hashcode with the current set hashcode.
Of course, this assumes that element hashcodes are stable while the elements are members of sets. It also assumes that the element classes hashcode function gives a good spread. That is because when the two set hashcodes are the same you still have to fall back to the O(N) comparison of all elements.
You could take this idea a bit further ... at least in theory.
WARNING - This is highly speculative. A "thought experiment" if you like.
Suppose that your set element class has a method to return a crypto checksums for the element. Now implement the set's checksums by XORing the checksums returned for the elements.
What does this buy us?
Well, if we assume that nothing underhand is going on, the probability that any two unequal set elements have the same N-bit checksums is 2-N. And the probability 2 unequal sets have the same N-bit checksums is also 2-N. So my idea is that you can implement equals as:
public boolean equals(Object o) {
if (o == this)
return true;
if (!(o instanceof Set))
return false;
Collection c = (Collection) o;
if (c.size() != size())
return false;
return checksums.equals(c.checksums);
}
Under the assumptions above, this will only give you the wrong answer once in 2-N time. If you make N large enough (e.g. 512 bits) the probability of a wrong answer becomes negligible (e.g. roughly 10-150).
The downside is that computing the crypto checksums for elements is very expensive, especially as the number of bits increases. So you really need an effective mechanism for memoizing the checksums. And that could be problematic.
And the other downside is that a non-zero probability of error may be unacceptable no matter how small the probability is. (But if that is the case ... how do you deal with the case where a cosmic ray flips a critical bit? Or if it simultaneously flips the same bit in two instances of a redundant system?)
There is a method in Guava Sets which can help here:
public static <E> boolean equals(Set<? extends E> set1, Set<? extends E> set2){
return Sets.symmetricDifference(set1,set2).isEmpty();
}
There's an O(N) solution for very specific cases where:
the sets are both sorted
both sorted in the same order
The following code assumes that both sets are based on the records comparable. A similar method could be based on on a Comparator.
public class SortedSetComparitor <Foo extends Comparable<Foo>>
implements Comparator<SortedSet<Foo>> {
#Override
public int compare( SortedSet<Foo> arg0, SortedSet<Foo> arg1 ) {
Iterator<Foo> otherRecords = arg1.iterator();
for (Foo thisRecord : arg0) {
// Shorter sets sort first.
if (!otherRecords.hasNext()) return 1;
int comparison = thisRecord.compareTo(otherRecords.next());
if (comparison != 0) return comparison;
}
// Shorter sets sort first
if (otherRecords.hasNext()) return -1;
else return 0;
}
}
You have the following solution from https://www.mkyong.com/java/java-how-to-compare-two-sets/
public static boolean equals(Set<?> set1, Set<?> set2){
if(set1 == null || set2 ==null){
return false;
}
if(set1.size() != set2.size()){
return false;
}
return set1.containsAll(set2);
}
Or if you prefer to use a single return statement:
public static boolean equals(Set<?> set1, Set<?> set2){
return set1 != null
&& set2 != null
&& set1.size() == set2.size()
&& set1.containsAll(set2);
}
If you are using Guava library it's possible to do:
SetView<Record> added = Sets.difference(secondSet, firstSet);
SetView<Record> removed = Sets.difference(firstSet, secondSet);
And then make a conclusion based on these.
I would put the secondSet in a HashMap before the comparison. This way you will reduce the second list's search time to n(1). Like this:
HashMap<Integer,Record> hm = new HashMap<Integer,Record>(secondSet.size());
int i = 0;
for(Record secondRecord : secondSet){
hm.put(i,secondRecord);
i++;
}
for(Record firstRecord : firstSet){
for(int i=0; i<secondSet.size(); i++){
//use hm for comparison
}
}
public boolean equals(Object o) {
if (o == this)
return true;
if (!(o instanceof Set))
return false;
Set<String> a = this;
Set<String> b = o;
Set<String> thedifference_a_b = new HashSet<String>(a);
thedifference_a_b.removeAll(b);
if(thedifference_a_b.isEmpty() == false) return false;
Set<String> thedifference_b_a = new HashSet<String>(b);
thedifference_b_a.removeAll(a);
if(thedifference_b_a.isEmpty() == false) return false;
return true;
}
I think method reference with equals method can be used. We assume that the object type without a shadow of a doubt has its own comparison method. Plain and simple example is here,
Set<String> set = new HashSet<>();
set.addAll(Arrays.asList("leo","bale","hanks"));
Set<String> set2 = new HashSet<>();
set2.addAll(Arrays.asList("hanks","leo","bale"));
Predicate<Set> pred = set::equals;
boolean result = pred.test(set2);
System.out.println(result); // true