• Post Reply Bookmark Topic Watch Topic
  • New Topic

Comparing GeometricObjects based on pre-defined parameters  RSS feed

 
Charles Cole
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I need to compare objects based on given criteria that compares more than just the object's areas.

Criteria:
1.) A blue circle is larger than any other figure.
2.) Transparent objects (filled = false) contribute with only 50% of their area.

How would I go about finishing my compareTo() method to meet this criteria?

Driver:


GeometricObject:


The expected result should be:
c1 ? c1 0
c1 ? c2 -1
c1 ? c3 -1
c1 ? c4 1
r1 ? r2 -1
r1 ? r2 -1
c1 ? r2 1
r3 ? r4 -1
 
Campbell Ritchie
Marshal
Posts: 56584
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Does a blue circle size 10 exceed a blue circle size 9?
Write down the rules carefully and turn them into words of one syllable so even a Government Official can use them to make a decision. Once you have them written down in plain English, it will be much easier to turn them into code.

Go through the Java Tutorials. See what that section says about Comparators. That might be an easier way to implement your problem.
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:Write down the rules carefully and turn them into words of one syllable so even a Government Official can use them to make a decision...

Oh come on, Campbell. You don't want to depress the poor lad.

@Charles: However, what Campbell said is absolutely correct. You need to come up with a description that satisfies ALL possible combinations of GeometricObjects, including "blue" and "non-blue", transparent and not. For example, presumably the actual area IS still a factor, even when these other things are the same.

Also: I would suggest NOT using a String for colour. Java already has a perfectly good Color class of its own: java.awt.Color (←click) - which includes a Color.BLUE constant.

For more information, read the StringsAreBad page.

HIH

Winston
 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So what happens when you compare a Blue-transparent-Circle with an area of X and a Red-non-transparent-Circle with an area of 2X?

Or a Red-non-transparent-Circle with area of X and a Blue-transparent-Circle with an area of 2X?

Or a Blue-non-transparent-Rectangle with area of 2X and a Blue-transparent-Circle with an area of 2X?

Or a Blue-non-transparent-Circle with area of X and a Blue-transparent-Circle with area of 2X?

I think some clarification of "A blue circle is larger than any other figure" is in order:
1. Does this only apply when comparing a circle against non-circles?
2. What about circle vs circle? Blue-circle vs blue-circle?

(so many edits: this is bringing out the tester in me )
 
Charles Cole
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is what I have so far, but I am having trouble when comparing c1 with c4. The result should be 1, but it comes out as -1.

Also to clarify the criteria, no matter what the circumstance is, if the object is a blue circle it will always produce the result of 1 except when the otherfigure is also a blue circle, then it will go back to comparing areas.

In the GeometricObject class I have this:



and in the Circle class I have this:



I'm struggling to get the result of 1 when comparing a Blue Circle with a Black Circle (c1 compareTo c4).

I tried this, but it had no effect:

 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You also have to consider this requirement for compareTo:
Java API docs wrote:The implementor must ensure sgn(x.compareTo(y)) == -sgn(y.compareTo(x)) for all x and y

That is:

I think you'll have a problem with getting your current code to work like this. Also, in the Circle class, a check like if (this instanceof Circle) is really unnecessary, the check will always evaluate to true.
 
Charles Cole
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Junilu Lacar wrote: if (this instanceof Circle) is really unnecessary, the check will always evaluate to true.


Thanks I didn't realize that. I took it out, however I still don't understand how to make my compareTo work for c1 compareto c4.

From my understanding right now, my compareTo states that if the object is a Circle and the color is blue -> and if the otherfigure is a blue circle it will compare areas -> if the otherfigure it not a circle, it will return 1 indicating that the first figure (blue circle) is greater -> and then if none of that criteria is met it will return to comparing areas.

However, I need it to return 1 when the otherfigure is a circle, but the color is not blue. When I tried to add that line of code it did not work. Am I not understanding something clearly?
 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just off the top of my head, I would look at using the Comparator<T> interface. I would try this strategy:

1. In general, ask the other object for a Comparator and use that to compare this object and the other object. You will implement a Comparator for the general case where you're comparing area + filled/not filled. You have to be careful which reference you pass to the Comparator.compareTo(a, b) so that you get the right semantics.
2. If you're a Circle, you have to decide whether to use the same general behavior or override it and use a special comparator because of the "BLUE is bigger" rule.

I haven't tried coding it but I think this will get you the correct behavior for all types of shapes.

Edit: The reason I think this will work is that if you're a whatever shape getting compared to a Blue circle and you ask it for a Comparator, the Blue Circle will give back its special Comparator with the "BLUE is bigger" rule logic in it. Any other shape will give back a Comparator that has the general area + filled rule. Again, you just have to think carefully about which reference (this or other) goes to which parameter of the Comparator.compareTo(x, y).
 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Also note that the documented behavior of Comparable.compareTo() and Comparator.compareTo() is that they will return a negative integer, zero, or positive integer. -1 and 1 are not the only values that can be returned besides 0, even though many implementations do that anyway. It's perfectly legal to return any negative or positive integer. This makes calculation easier, especially if you're dealing with integer values directly, since you can just subtract two values and get a positive integer if the first is greater, zero if both are the same, or negative integer if the second is greater.
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Charles Cole wrote:From my understanding right now, my compareTo states that if the object is a Circle and the color is blue -> and if the otherfigure is a blue circle..

Charles,

StopCoding (←click).

There should never be any "from my understanding" when you write code; you should KNOW what it will do - in every case. And either it does what you want it to do, or you made a mistake.

Sorry if that sounds bombastic, but it's true. You will NEVER solve problems by coding, or "tweaking" code. That was fine when you were writing "Hello World" programs, but you're getting into the big leagues now - and it just doesn't work.

You need to understand the problem, and that means that - as Campbell said a few posts back - you need to write out a description of it, in English (or your native tongue) before you write Line 1 of your Java code.

Right now, you're just "band-aiding". You might end up with something that works; but it will be far from a good program.

HIH (and it's meant with the best intentions)

Winston
 
Campbell Ritchie
Marshal
Posts: 56584
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Junilu Lacar wrote: . . . if you're dealing with integer values directly . . . you can just subtract two values . . .
Not a reliable technique. It is all explained in the Java Tutorials link I posted yesterday.

What happens if you compare 2000000000 and -200000000 like that?
 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:
Junilu Lacar wrote: . . . if you're dealing with integer values directly . . . you can just subtract two values . . .
Not a reliable technique. It is all explained in the Java Tutorials link I posted yesterday.
What happens if you compare 2000000000 and -200000000 like that?

I should have gone with my first instinct. I was going to mention something about underflow/overflow but deleted it before posting that reply. Thanks for pointing that out, Campbell.
Java Tutorials wrote:
One last note: You might be tempted to replace the final return statement in the Comparator with the simpler:

return e1.number() - e2.number();

Don't do it unless you're absolutely sure no one will ever have a negative employee number! This trick does not work in general because the signed integer type is not big enough to represent the difference of two arbitrary signed integers. If i is a large positive integer and j is a large negative integer, i - j will overflow and will return a negative integer. The resulting comparator violates one of the four technical restrictions we keep talking about (transitivity) and produces horrible, subtle bugs. This is not a purely theoretical concern; people get burned by it.


Although, if you think about it, area is always going to be positive...
 
Don't get me started about those stupid light bulbs.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!