"We're kind of on the level of crossword puzzle writers... And no one ever goes to them and gives them an award." ~Joe Strummer
sscce.org
marc weber wrote:
Personally, I don't see a reason for creating Integer objects here. I would just stick with ints,
return -1 if frequency < d.frequency; or return 0 if frequency == d.frequency; or return 1 if frequency > d.frequency.
Ernest Friedman-Hill wrote:... compareTo() is only required to return negative or positive, not -1 or +1...
"We're kind of on the level of crossword puzzle writers... And no one ever goes to them and gives them an award." ~Joe Strummer
sscce.org
Ernest Friedman-Hill wrote:But compareTo() is only required to return negative or positive, not -1 or +1; therefore the fastest, cleanest, simplest implementation is actually just
SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6 - OCEJPAD 6
How To Ask Questions How To Answer Questions
Rob Spoor wrote:Except that code will return an invalid value if the subtraction overflows. What if the first frequency is Integer.MIN_VALUE and the second one is 1?
marc weber wrote:Note that each instance of HuffmanData has a char called "letter" and an int called "frequency." So yes, your examples of A4, B6, and C9 would each represent separate objects.
The compareTo method is intended to compare the current object (in this case, an instance of HuffmanData) with some other object (presumably of the same type). In other words, compare this instance of HuffmanData to Object d. The implementation in this example assumes that Object d is, in fact, an instance of HuffmanData.
But either way, this compareTo method is basically just comparing the frequency value of the current object to the frequency value of the other object. It does this by converting the frequency int values to Integer instances, so it's comparing (Integer)frequency to (Integer)d.frequency. Then the actual comparison uses the compareTo method of the Integer class, which is why it's written...
"We're kind of on the level of crossword puzzle writers... And no one ever goes to them and gives them an award." ~Joe Strummer
sscce.org
marc weber wrote:You can create a new HuffmanData instance for each of your examples...
"Object d" is only the argument list for the compareTo method. Nothing is assigned to d until that method is called, which you can do once you have references to these instances. For example...
Cheryl Scodario wrote:... Thanks! This makes perfect sense. One question though, when we call the compareTo method, it just compares the frequencies of these different objects, but it doesn't actually DO anything. like it doesn't swap like what sorting would do. So what's the point of just comparing different frequencies? Would it make a difference if I didn't include compareTo method in my code?
"We're kind of on the level of crossword puzzle writers... And no one ever goes to them and gives them an award." ~Joe Strummer
sscce.org
marc weber wrote:
Cheryl Scodario wrote:... Thanks! This makes perfect sense. One question though, when we call the compareTo method, it just compares the frequencies of these different objects, but it doesn't actually DO anything. like it doesn't swap like what sorting would do. So what's the point of just comparing different frequencies? Would it make a difference if I didn't include compareTo method in my code?
Your class, HuffmanData, IS Comparable, meaning it implements the Comparable interface. The API documentation says, "This interface imposes a total ordering on the objects of each class that implements it. This ordering is referred to as the class's natural ordering, and the class's compareTo method is referred to as its natural comparison method.
So by declaring that HuffmanData IS Comparable, you are saying that instances of HuffmanData can be ordered in a way that makes sense for these instances. In particular, they are guaranteed to have a compareTo() method that behaves in a predefined way -- returning "a negative integer, zero, or a positive integer as this object is less than, equal to, or greater than the specified object."
This is important because instances of HuffmanData can now be used in other code that you know nothing about. For example, suppose you need to sort a huge array of HuffmanData instances. The class java.util.Arrays contains a sort() method that will do this for you! That sort() method requires only that all elements in the array implement Comparable, because that's what it will use for ordering.
Note that the sort() method doesn't care what else these instances are -- whether they're Strings, Integers, HuffmanData, MyOwnWeirdObject, etc. -- as long as they are Comparable. After all, how would sort() know what "order" means for MyOwnWeirdObject? I need to describe that, and I do it in a way other code can understand: The CompareTo() method.
This is why interfaces are sometimes described as "contracts." They don't "do" anything by themselves, but they guarantee that a class will implement the behavior described by the interface.
This parrot is no more. It has ceased to be. Now it's a tiny ad:
Gift giving made easy with the permaculture playing cards
https://coderanch.com/t/777758/Gift-giving-easy-permaculture-playing
|