Win a copy of TensorFlow 2.0 in Action this week in the Artificial Intelligence and Machine Learning forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Paul Clapham
  • Bear Bibeault
  • Jeanne Boyarsky
Sheriffs:
  • Ron McLeod
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Jj Roberts
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • salvin francis
  • Scott Selikoff
  • fred rosenberger

compareTo method

 
Ranch Hand
Posts: 65
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Does this method look correct given the circumstances or am I missing something?


 
Marshal
Posts: 70684
288
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Afraid not.

The idea behind implementing Comparable is to define a natural ordering. That means there is a feature on which everybody would order the objects. Numbers have a natural ordering and dates have a natural ordering, but employees have several different potential orderings. You might order employees by age, length or employment, salary level, name, or maybe something else. That suggests to me that an employee class shouldn't implement Comparable<Employee> in the first place. It would be better to create a Comparator to compare salaries. You can then create other Comparators for name, length of employment, etc.
Your code shows another error, that of using doubles for money. If you require precision, which you always do for money, either use integer arithmetic or a BigDecimal object. A double cannot provide such precision.
 
Andrew Bauer
Ranch Hand
Posts: 65
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:Afraid not.

The idea behind implementing Comparable is to define a natural ordering. That means there is a feature on which everybody would order the objects. Numbers have a natural ordering and dates have a natural ordering, but employees have several different potential orderings. You might order employees by age, length or employment, salary level, name, or maybe something else. That suggests to me that an employee class shouldn't implement Comparable<Employee> in the first place. It would be better to create a Comparator to compare salaries. You can then create other Comparators for name, length of employment, etc.
Your code shows another error, that of using doubles for money. If you require precision, which you always do for money, either use integer arithmetic or a BigDecimal object. A double cannot provide such precision.




Could you provide an example since I'm supposed to be comparing pay rates?
 
Campbell Ritchie
Marshal
Posts: 70684
288
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The good new is, you can create a Comparator in one line. I am assuming there is a getSalary() method returning a double. The built‑in methods e.g. comparingDouble() have been tested extensively and are designed to take strange values including ±∞ and NaN into consideration.:-The bad news is, you will have to go through the comparingDouble() method, and at least most of this part of the Java™ Tutorials to understand the code. I am afraid I am too tired to give a fuller explanation now. Maybe tomorrow.
 
Saloon Keeper
Posts: 12431
269
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can't write a valid comparator with the requirements that you have documented.

Let's say that Employee x has a salary of 9.999, Employee y has a salary of 10.000 and Employee z has a salary of 10.001. That would mean that according to your comparator, x == y and y == z, but x < z. That violates the transitivity rule of comparators and will lead to buggy behavior when you're using it to sort a list.

Explain to us why you want such a comparator, maybe we can suggest a better alternative.

Another thing; you REALLY should not be using floating point number to express monetary values. Why don't you express a salary in integer units?
 
Campbell Ritchie
Marshal
Posts: 70684
288
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:. . . you REALLY should not be using floating point number to express monetary values. . . .

Agree; if you used BigDecimal, or integers denominating the salary in pence/cents/etc., that problem would vanish altogether.
 
Campbell Ritchie
Marshal
Posts: 70684
288
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You also wouldn't suffer that problem with comparingDouble(), but you can have two salaries, 111.11 * 9.0 and 9999.9 / 10.0 which don't count as equal because of the imprecision of floating‑point arithmetic. Either of the solutions we have told you would completely obviate that problem too; BigDecimal might bee better because using an int would limit your salary to slightly over €20,000,000/£20,000,000/$20,000,000.
Let's see if I can't explain what I showed you last night. Please await next post.

[addition] I didn't mean that 111.11 * 9.0 and 9999.9 / 10.0 will be different, but they might differ. Such errors with floating‑point arithmetic are unpredictable, but once they have occurred they are easily repeatable.
 
Campbell Ritchie
Marshal
Posts: 70684
288
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you go through the Java7 documentation, you will find that Comparator has one method absolutely having to be implemented and one you are allowed not to implement (equals()). But in Java8 you find it had gained fifteen new methods. If you look at them, they are (?mostly) factory methods returning Comparator. You can use those methods to create Comparators that will do the comparisons, and which have been extensively tested for correctness. If you have a method returning double, which I am assuming, you find there is a comparingDouble() method. That produces a Comparator taking something which produces a double. Your Employee objects have a getSalary() method, so you can call that to supply the information required.
If you went through the Java™ Tutorials link I gave you yesterday, you will realise that simply calling a method can be implemented by a method reference. You can write the class name, :: and the method name, and the compiler will interpret that as, “Take an Employee object and call its getSalary method.” Then it creates a Comparator object and you can assign it to a reference as usual.
 
look! it's a bird! it's a plane! It's .... a teeny tiny ad
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic