• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

“Sybex” OCP 11 - Chapter 6, page 230

 
Ranch Hand
Posts: 127
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In the middle paragraph, it says:

"This is a positive number that means the first number is bigger and we are sorting in ascending order".

I think it should be descending order. Correct me if I am wrong.

If the first number is bigger than the second number and gives you positive, isn't it descending? First number is bigger and second number is smaller...and so on.
 
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Is that Boyarsky's and Selikoff's book?
Please show some more for those of us who don't have that book.
 
henry leu
Ranch Hand
Posts: 127
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes it is Jeanne and Scott's book.

Here are the exact wordings from the paragraph:

"Comparator<Integer> ints = (i1, i2) -> i1 - i2;

The ints comparator uses natural sort order. If the first number is bigger, it will return a positive number. Try it. Suppose we are comparing 5 and 3. The comparator subtracts 5-3 and gets 2. This is a positive number that means the first number is bigger and we are sorting in ascending order".


I think it should be descending order. Correct me if I am wrong.

If the first number is bigger than the second number and gives you positive, isn't it descending? First number is bigger and second number is smaller...and so on.
 
Bartender
Posts: 5465
212
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The book is correct and so I correct you    

Sorting is always in ascending order, from "small" to "large". But what is small and what is large is defined by the compareTo or the compare method. For instance, suppose you have this Comparator<Integer>:

Then sorting the list {-3, -2, -1} results in: {-1, -2, -3}. This is not what you would call: in ascending order, yet it is, according to the Comparator being used.
 
Bartender
Posts: 3904
43
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Probably you mix "sorting order" and "order of parameters".
Indeed order of parameters 5 - 3 = 2 , you can call it "descending" 8)), but we never care of it
What we care -- sorting order which this comparator will result in, and it will be 3, 5 => ascending
I believe the book is correct in this place 8-)
 
Enthuware Software Support
Posts: 4810
52
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Piet Souris wrote:
Sorting is always in ascending order, from "small" to "large". But what is small and what is large is defined by the compareTo or the compare method.


By that logic, one could as easily say that Sorting is always in descending order, from "large" to "small"!

The fact is that this has nothing to do with large or small. A Comparator orders two elements x, y in that order if x-y is <=0 (this implies that it orders them as y, x if x-y>0). In practice, x and y are generated using some property of the objects that you want to compare. In case of numeric values, x and y are same as the items that are being compared. One can certainly implement a Comparator that doesn't follow this rule and provides a different way of ordering two items.

If you apply the Comparator in question (  (i1, i2) -> i1 - i2 ),  to any pair of numbers (for example, (4, 3) or (3 , 4) ), they will be ordered as 3, 4. That means, to us humans, the numbers are being ordered in "ascending" order. So, the book is correct but may be the explanation can be made clearer.



 
henry leu
Ranch Hand
Posts: 127
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

So this is what I perceived. Please advise if this is correct.

Java sees this:

Positive: swap the element
Negative: no swap
Zero: no swap

If obj1 should APPEAR BEFORE obj2 in a sorted list, then we return a negative number. (No swap)
If obj1 should APPEAR AFTER obj2 in a sorted list, then we return a positive number. (Swap)
If we don't care which object comes first (because they might be equal), then we return zero. (no swap)

Example:



 
Paul Anilprem
Enthuware Software Support
Posts: 4810
52
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

henry leu wrote:
If obj1 should APPEAR BEFORE obj2 in a sorted list, then we return a negative number. (No swap)
If obj1 should APPEAR AFTER obj2 in a sorted list, then we return a positive number. (Swap)
If we don't care which object comes first (because they might be equal), then we return zero. (no swap)



Correct!
 
Campbell Ritchie
Marshal
Posts: 79177
377
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

henry leu wrote:. . .
Positive: swap the element
Negative: no swap
Zero: no swap

I am not convinced that is right. I think it would be more like what follows, but I think even that isn't accurate.

If obj1 should APPEAR BEFORE obj2 in a sorted list, then we return a negative number. (No swap)
If obj1 should APPEAR AFTER obj2 in a sorted list, then we return a positiv default e number. (Swap)
If we don't care which object comes first (because they might be equal), then we return zero. (no swap)
. . .

A Comparator (as does the Comparable interface) imposes an ordering on objects of a particular type. The word “ordering” is used in the sense the mathematicians would use is.
  • 1: If you get a positive result from compare(x,y), then x is regarded as larger than y.
  • 2: If you get a negative result from compare(x,y), then x is regarded as smaller than y.
  • 3: If you get a zero result from compare(x,y), then x is regarded as the same size as y.
  • There is an explanation of how Java® implements ordering in the Java™ Tutorials. That link tells you about Comparator and Comparable, and the many errors which can beset naïve attempts at ordering.

    If you reember that sorting is usually implemented in ascending order, you will have to redefine the comparison so you get the sign different.
  • 1: Ascending order: make "Campbell" smaller than "Henry"
  • 2: Descending order: make "Campbell" larger than "Henry"
  • By writing that Comparator, you are defining a different ordering for names. That doesn't make the names any different, but your definition of which order you want them in is different.
    Don't think about, “don't care,” please. We do care. Nor, “appear before”. Think “larger and smaller, as I am defining it at present.” The sorting algorithms will then interpret the result from comparison methods like this:-
  • 1: Negative: in the desired order: has already been sorted.
  • 2: Positive: in the wrong order: sorting required.
  • 3: Zero result: the two are “the same”: mustn't be altered.
  • Because comparisons are so error‑prone, several static methods were added to Comparator in Java8. It is now much more reliable to writethanMy second code block shows very unreliable code, which can be relied on to produce incorrect results in many cases. That is an example showing that you are usually better using one of the methods of Comparator than writing your own comparison method like that. The comparison method you showed in your second post is similarly incorrect.
    If you look through the methods of Comparator, you will find two which change “smaller” to “larger” and vice versa.


    I think this question is no longer certification‑specific, so I shall add you to a more general forum.
     
    With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
    reply
      Bookmark Topic Watch Topic
    • New Topic