Nina Savannah

Ranch Hand

Posts: 35

posted 9 years ago

Hello guys, pliz help me out::

I am trying to implement a set concept.

I have a union set U

I have 6 subsets A, B, C, D, E and F.

There can be union sets between two or more of these subsets.

eg.

overlapping figure/union total

A, B, C10

B, E, F15

A, D5

I need a jsp or java code that allows me to specify which subsets overlap each other and the figure like I illustrated above.

After that I want to be able to calculate the total of the union set U.

How do I do that, pliz try to be as simple as possible, I am not a java expert though.

Pliz.

I am trying to implement a set concept.

I have a union set U

I have 6 subsets A, B, C, D, E and F.

There can be union sets between two or more of these subsets.

eg.

overlapping figure/union total

A, B, C10

B, E, F15

A, D5

I need a jsp or java code that allows me to specify which subsets overlap each other and the figure like I illustrated above.

After that I want to be able to calculate the total of the union set U.

How do I do that, pliz try to be as simple as possible, I am not a java expert though.

Pliz.

Nina Savannah

Ranch Hand

Posts: 35

posted 9 years ago

I tried 'googling' the set concept but its complicated for me, just cant seem to get it right.

Could it be possible to use arrays for now

Eg

Array1[] = first combination of subsets

Overlapping Figure of Array1 = x1

Arrat2[] = second combination of subsets

Overlapping Figure of Array2 = x2

.

.

.

Arrayn[] = nth combination of subsets

Overlapping Figure of Arrayn = xn

Total of Universal set = (Total of Subset A + Total of Subset B + ... + Total of Subset F) - ((x1 multiplied by (size of Array1 - 1)) + (x2 multiplied by (size of Array2 - 1)) + ... + (xn multiplied by (size of Arrayn - 1))

Would this perhaps work? I have the concept in my mind though I cant figure out how to implement it in code language...

Could it be possible to use arrays for now

Eg

Array1[] = first combination of subsets

Overlapping Figure of Array1 = x1

Arrat2[] = second combination of subsets

Overlapping Figure of Array2 = x2

.

.

.

Arrayn[] = nth combination of subsets

Overlapping Figure of Arrayn = xn

Total of Universal set = (Total of Subset A + Total of Subset B + ... + Total of Subset F) - ((x1 multiplied by (size of Array1 - 1)) + (x2 multiplied by (size of Array2 - 1)) + ... + (xn multiplied by (size of Arrayn - 1))

Would this perhaps work? I have the concept in my mind though I cant figure out how to implement it in code language...

posted 9 years ago

First:

you should store the values in some type of Set, for example a HashSet will be just fine.

Second:

Look at the methods available to see how it helps you perform your operations

Third:

Consider how you will compare the set instances to determine if they contain the same its and are therefore the same.

Fourth:

Iterate through your problem, combine the sets, then increment a counter that stores the value for this set.

you should store the values in some type of Set, for example a HashSet will be just fine.

Second:

Look at the methods available to see how it helps you perform your operations

Third:

Consider how you will compare the set instances to determine if they contain the same its and are therefore the same.

Fourth:

Iterate through your problem, combine the sets, then increment a counter that stores the value for this set.

Campbell Ritchie

Marshal

Posts: 56570

172

posted 9 years ago

Whenever problems like this arise I send people to the Java Tutorials. There should be something about sets in there, and as DO'M has already said, you will find all sorts of useful things in the Set interface, which I think is here.

I am afraid I don't think the arrays will help.

I am afraid I don't think the arrays will help.

Romeo Kienzler

Greenhorn

Posts: 14

posted 8 years ago

I think what Nina is talking about are the common mathematical set operations like intersection, difference, ...

Fortunately, the all implementers of the Set interface in Java are taking care of the uniqueness of all items (in their mathematical sence).

But this works only for basic Java types (int, String, ...) and not for custom types.

So if you use custom types you must override the equals(Object o) - Method from the Object class.

So for Nina's problem the following mathematical formula is used:

The corresponding Java implementation is very simple:

Hope this helps.

Regards,

Romeo Kienzler

romeo (#) ormium.de

Fortunately, the all implementers of the Set interface in Java are taking care of the uniqueness of all items (in their mathematical sence).

But this works only for basic Java types (int, String, ...) and not for custom types.

So if you use custom types you must override the equals(Object o) - Method from the Object class.

So for Nina's problem the following mathematical formula is used:

The corresponding Java implementation is very simple:

Hope this helps.

Regards,

Romeo Kienzler

romeo (#) ormium.de

Campbell Ritchie

Marshal

Posts: 56570

172

posted 8 years ago

I am afraid it might not help; she was asking last November. Please look at this FAQ.Romeo Kienzler wrote:Hope this helps.

posted 8 years ago

Those Java statements won't compile; the bulk methods do not return a set but a boolean. The statements should be as followed (of course the Set implementation can change):

Almost right. With HashSet and LinkedHashSet, you need to override both equals and hashCode. For TreeSet, you can go two ways:

- have your classes implement Comparable

- use a custom Comparator

Romeo Kienzler wrote:I think what Nina is talking about are the common mathematical set operations like intersection, difference, ...

Those Java statements won't compile; the bulk methods do not return a set but a boolean. The statements should be as followed (of course the Set implementation can change):

But this works only for basic Java types (int, String, ...) and not for custom types.

So if you use custom types you must override the equals(Object o) - Method from the Object class.

Almost right. With HashSet and LinkedHashSet, you need to override both equals and hashCode. For TreeSet, you can go two ways:

- have your classes implement Comparable

- use a custom Comparator

SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6 - OCEJPAD 6

How To Ask Questions How To Answer Questions

Romeo Kienzler

Greenhorn

Posts: 14

posted 8 years ago

You're right! Next time I'll paste it to my compiler first.

With HashSet and LinkedHashSet you don't need necessarily overwrite hashCode. But data access will be a bit slower.

Since TreeSet is sorted, and this feature isn't needed for determining the cardinality of a Set, I consider the implementation of a comparator as unnecessary overhead.

Rob Prime wrote:

Those Java statements won't compile; the bulk methods do not return a set but a boolean. The statements should be as followed (of course the Set implementation can change):

You're right! Next time I'll paste it to my compiler first.

Rob Prime wrote:

Almost right. With HashSet and LinkedHashSet, you need to override both equals and hashCode. For TreeSet, you can go two ways:

- have your classes implement Comparable

- use a custom Comparator

With HashSet and LinkedHashSet you don't need necessarily overwrite hashCode. But data access will be a bit slower.

Since TreeSet is sorted, and this feature isn't needed for determining the cardinality of a Set, I consider the implementation of a comparator as unnecessary overhead.

Romeo Kienzler

Greenhorn

Posts: 14

posted 8 years ago

Hi Ritchie,

sometimes I'm searching for a particular solution to a problem and after I've found the solution I paste it to the forums where it hasn't been answered. Just for letting future searchers be more successful. But if this is undesired, I won't do it on JavaRanch in future.

Cheers,

Romeo

Campbell Ritchie wrote:I am afraid it might not help; she was asking last November. Please look at this FAQ.

Hi Ritchie,

sometimes I'm searching for a particular solution to a problem and after I've found the solution I paste it to the forums where it hasn't been answered. Just for letting future searchers be more successful. But if this is undesired, I won't do it on JavaRanch in future.

Cheers,

Romeo

posted 8 years ago

Ehm, are you sure about not needing to override hashCode? Have you read the API for Object.equals and Object.hashCode?

Let me tell you how HashSet works (and HashMap as well). The set is partitioned into multiple so-called

If you use the default hashCode implementation of Object, then it will most likely look in the wrong bucket. It there will not find an object that is equal, so nothing is found.

An example:

Even though, mc1 and mc2 are equal, the HashSet still can't find mc2. Now remove the comments before the hashCode method, and all of a sudden the HashSet can find it.

So basically, if you override equals or hashCode, make sure the contact between equals and hashCode still holds: two equal objects must have the same hashCode return value.

As a side note: HashSet (and HashMap) cannot handle changing keys well. Consider again my example, but we add a method called setName():

Even though mc1 and the set both point to the very same object, it still can't find mc1. That's because the hashCode() has changed, so the set is trying to look in the wrong bucket.

Romeo Kienzler wrote:Rob Prime wrote:

Almost right. With HashSet and LinkedHashSet, you need to override both equals and hashCode. For TreeSet, you can go two ways:

- have your classes implement Comparable

- use a custom Comparator

With HashSet and LinkedHashSet you don't need necessarily overwrite hashCode. But data access will be a bit slower.

Since TreeSet is sorted, and this feature isn't needed for determining the cardinality of a Set, I consider the implementation of a comparator as unnecessary overhead.

Ehm, are you sure about not needing to override hashCode? Have you read the API for Object.equals and Object.hashCode?

Let me tell you how HashSet works (and HashMap as well). The set is partitioned into multiple so-called

*buckets*. When you add an object, the set determines the bucket to put an object in using the hashCode. It then uses something similar to a linked list within that bucket. When you access an object, the set uses the hashCode of the object to determine the bucket. It then goes through the linked list using equals.

If you use the default hashCode implementation of Object, then it will most likely look in the wrong bucket. It there will not find an object that is equal, so nothing is found.

An example:

Even though, mc1 and mc2 are equal, the HashSet still can't find mc2. Now remove the comments before the hashCode method, and all of a sudden the HashSet can find it.

So basically, if you override equals or hashCode, make sure the contact between equals and hashCode still holds: two equal objects must have the same hashCode return value.

As a side note: HashSet (and HashMap) cannot handle changing keys well. Consider again my example, but we add a method called setName():

Even though mc1 and the set both point to the very same object, it still can't find mc1. That's because the hashCode() has changed, so the set is trying to look in the wrong bucket.

SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6 - OCEJPAD 6

How To Ask Questions How To Answer Questions

Campbell Ritchie

Marshal

Posts: 56570

172

posted 8 years ago

CR

Thank you. Our official policy is to discourage replies after more than about three weeks. And only too often, we find that is mistaken Sorry.Romeo Kienzler wrote:Hi Ritchie,

sometimes I'm searching for a particular solution to a problem and after I've found the solution I paste it to the forums where it hasn't been answered. Just for letting future searchers be more successful. But if this is undesired, I won't do it on JavaRanch in future.

Cheers,

Romeo

CR

Romeo Kienzler

Greenhorn

Posts: 14

posted 8 years ago

Hi Rob, I wasn't completely aware of that. I thought if hashCode isn't overwritten all objects are ending up in the same bucket and the data structure will degenerate to a simple list. But since the default implementation of java.lang.Object#hashCode returns the heap address it definitely will end up in a different bucket. Some logical reasoning about that fact would have given me the answer. So thanks a lot!

Cheers,

Romeo

Rob Prime wrote:When you access an object, the set uses the hashCode of the object to determine the bucket. It then goes through the linked list using equals.

If you use the default hashCode implementation of Object, then it will most likely look in the wrong bucket. It there will not find an object that is equal, so nothing is found.

Hi Rob, I wasn't completely aware of that. I thought if hashCode isn't overwritten all objects are ending up in the same bucket and the data structure will degenerate to a simple list. But since the default implementation of java.lang.Object#hashCode returns the heap address it definitely will end up in a different bucket. Some logical reasoning about that fact would have given me the answer. So thanks a lot!

Cheers,

Romeo