t is strongly recommended (though not required) that natural orderings be consistent with equals. This is so because sorted sets (and sorted maps) without explicit comparators behave "strangely" when they are used with elements (or keys) whose natural ordering is inconsistent with equals. In particular, such a sorted set (or sorted map) violates the general contract for set (or map), which is defined in terms of the equals method.
Campbell Ritchie wrote:Note that case‑insensitive ordering of Strings would give the same problem as above: compareTo() not consistent with equals().
No.tangara goh wrote:. . . can i sum it up that we need to use compareTo for set, and we won't go wrong ?
Campbell Ritchie wrote:
No.tangara goh wrote:. . . can i sum it up that we need to use compareTo for set, and we won't go wrong ?
I think you couldn't, not even if I understood the whole of that sentence. What have sets got to do with it?
This is so because sorted sets (and sorted maps) without explicit comparators behave "strangely" when they are used with elements (or keys) whose natural ordering is inconsistent with equals.
tangara goh wrote:. . . can i sum it up that we need to use compareTo for set, and we won't go wrong ?
You don't use Comparators, nor ordering, for most Sets. If you look up the Set interface, you will find there are quite a lot of implementing classes. The most commonly used is the HashSet, where the iteration order is usually unpredictable. Some people call that an unordered collection, but that isn't a completely accurate title.tangara goh wrote:. . . maybe my set is different from the sets ?
Campbell Ritchie wrote:So, no, both compareTo() and a Comparator most probably will not be all right for a sorted set.
Yes, I wasMike Simmons wrote:. . . do you think there is any use for, say, TreeSet or TreeMap at all? . . . I think you may be overstating things a bit here.
Yes, that is exactly what I meant to say.Perhaps you meant, these methods will not be all right if they are inconsistent with equals. . . .
Shows how much interesting discussion you can get from a mistake.. . . if you think 1.234 and 1.2340 should be equal . . .
. . . and say you are violating the preconditions of that interface by using it for BigDecimal or anything else with compareTo() inconsistent with equals()? And if you violate that precondition, you only have yourself to blame for incorrect results.. . . the ordering maintained by a sorted set (whether or not an explicit comparator is provided) must be consistent with equals if the sorted set is to correctly implement the Set interface.
Note that the ordering maintained by a set (whether or not an explicit comparator is provided) must be consistent with equals if it is to correctly implement the Set interface. (See Comparable or Comparator for a precise definition of consistent with equals.) This is so because the Set interface is defined in terms of the equals operation, but a TreeSet instance performs all element comparisons using its compareTo (or compare) method, so two elements that are deemed equal by this method are, from the standpoint of the set, equal. The behavior of a set is well-defined even if its ordering is inconsistent with equals; it just fails to obey the general contract of the Set interface.
Joshua Bloch wrote:It is strongly recommended, but not required, that (x.compareTo(y) == 0) == (x.equals(y)). Generally speaking, any class that implements the Comparable interface and violates this condition should clearly indicate this fact. The recommended language is "Note: This class has a natural ordering that is inconsistent with equals."
Joshua Bloch wrote:The final paragraph of the compareTo contract, which is a strong suggestion rather than a true requirement, simply states that the equality test imposed by compareTo method should generally return the same results as the equals method. If this provision is obeyed, the ordering imposed by the compareTo method is said to be consistent with equals. If it's violated, the ordering is said to be inconsistent with equals. A class whose compareTo method imposes an order that is inconsistent with equals will still work, but sorted collections containing elements of the class may not obey the general contract of the appropriate collection interfaces (Collection, Set, or Map). This is because the general contracts for those interfaces are defined in terms of the equals method, but sorted collections use the equality test imposed by comareTo instead of equals. It is not a catastrophe if this happens, but it's something to be aware of.
Campbell Ritchie wrote:But if a HashSet adds 1.234 and 1.2340 as two different elements, and a TreeSet only adds one element, which is behaving correctly? Or are there two variants of the general contract of add(E) depending on what you define as equal?
[b]Kushan[/b] | Software Engineer | Java Enthusiast
Campbell Ritchie wrote:I have my own ideas about String, which differ from Java®'s. Thee are at least two ways of comparing Strings, the classic IT version, unofficially called ASCIIbetical, where Zymurgy comes before aardvark, and case‑insensitive, where aardvark comes first. I think that means the Strings don't have a natural ordering. But I shan't manage to implement that notion anywhere.
I disagree. The natural ordering of something depends on that something, not the language you are using. As we have said before, Strings have at least two possible orderings, so‑called ASCIIbetical, and one case‑insensitive. In ASCIIbetical, Zwolle (town in Netherlands) comes before aardvaark, and in case‑insensitive, aardvaark come before Zwolle. Most books use case‑insensitive ordering for words, and most computer languages use ASCIIbetical, only they call it lexical ordering. It follows Unicode and ASCII where capital letters come before lower‑case.kushan dileep wrote:Natural ordering is how Java knows . . . you decide what "natural" means . . .
Campbell Ritchie wrote:The natural ordering of something depends on that something, not the language you are using.
Campbell Ritchie wrote:I think we disagree much less than it might appear.
Agree. OP's Student class has at least two potential orderings.Paul Clapham wrote:Indeed. It's possible that a class can have many total orderings - - .
So I left, I came home, and I ate some pie. And then I read this tiny ad:
New web page for Paul's Rocket Mass Heaters movies
https://coderanch.com/t/785239/web-page-Paul-Rocket-Mass
|