• 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
  • Paul Clapham
  • Ron McLeod
  • Bear Bibeault
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Junilu Lacar
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Jj Roberts
  • Tim Holloway
  • Piet Souris
Bartenders:
  • Himai Minh
  • Carey Brown
  • salvin francis

OCP Java SE 11 Programmer I Study Guide (Sybex) Ch 6 -- possible errata

 
Ranch Hand
Posts: 48
3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There were two things that jumped out at me in Chapter 6 of the OCP Java SE 11 Programmer 1 Study Guide.

One was about the very tricky subject of Comparator.  I have seen videos from people who have a lot of generally good stuff teaching that incorrectly, as in if you followed their presentation you would get the opposite of what you wanted, which tells me it is tricky.

While the description of it in Chapter 6 wasn't flat-out wrong like that (reversing the polarity of the comparison in terms of sort order or tree placement) it was still a little confusing or ambiguous I thought.

The description in the text reads:



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.
" (end of quote from book)
While I agree with the explication that then followed on how to sort descending, i.e. by either reversing s2.compareTo(is) or unary minus negation of the value from s1.compareTo(s2), I found that even after learning Comparator, it was somewhat easy to forget how it works, in terms of occasionally getting the opposite of what one intends.  Having a good mnemonic way to not forget that is important.

Two common ways that Comparator is used are for custom sort orders passed to sort() and for proper element placement in TreeSet or TreeMap.  I feel that some explication that would be easy to remember for those uses would cover "What we need to remember about Comparator for success in life".

The sentence "This is a positive number that means the first number is bigger and we are sorting in ascending order" didn't help me.
For sort(), we can say the comparator is answering the question "I want to sort in ascending order, are you positive I need to swap these two elements?" tho "I want to sort in descending order, are you positive that these two elements should be left as they are?" doesn't have the same ring to it.  I had tentatively memorized the first of those two sayings.

When positioning something in a TreeMap (I am not up to the 816 book yet but have had to do this in real life, interviews, exams, etc.) it is answering the question "Am I positive that the new element should be placed to the right of the node I am looking at?" or do I have that backwards?  I am still desperately seeking a neat mnemonic device...

So, my real goal is to have a short neat way to never get this tricky thing wrong that I see other smart people with significant Java knowledge messing up sometimes.  Please excuse my dear aunt Sally.

I didn't find "This is a positive number that means the first number is bigger and we are sorting in ascending order." to do the trick.  I might have preferred "This is a positive number that means the first number is bigger and since we are sorting in ascending order, sort will need to swap the elements for us" as clearer, but still short of a great mnemonic device.

So I think a neat mnemonic to prevent the not-rare-enough mistakes of inverting comparator definitions from what is intended would be of high value.

Anyway, the other thing is *way* simpler:

On page 236 of the print book, we currently say:
"It turns out the keySet() and values() methods each return a Set."

Wait, values() explicitly returns a Collection (probably a List but I think not officially specified) because it most certainly may, and quite often does, contain duplicates.
If one actually needs a Set of values, one needs to create it from the returned likely chock-full-of-duplicates Collection.

Question 7 even teases us with this, because they posit a mythical .valueSet() as an answer choice to trick us.

Anyway, I love the book, and this chapter, but as a very high percentage of people reading it are going to be taking the 819, I consider it harmful to even casually mention that Map's .values() methods return a Set.
The code example works just fine, because we can .foreach() over a Set or a List equally handily.

As always, thanks for all of your hard work helping people learn this often rather tricky material.

Thanks,
Jesse



 
Marshal
Posts: 71047
291
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Jesse Silverman wrote:. . . the very tricky subject of Comparator. . . .

There is nothing tricky about Comparators. It is object ordering that is tricky.

The ints comparator uses natural sort order. . . .

But it doesn't. Look what happened when I tried that Comparator on JShell:-

My JShell wrote:jshell> Comparator<Integer> ints = (i1, i2) -> i1 -i2;
ints ==> $Lambda$26/0x0000000800ba5450@3d646c37

jshell> ints.compare(2_000_000_000, -2_000_000_000)
$6 ==> -294967296

jshell> ints.compare(5, 3)
$7 ==> 2

You will find some of the pitfalls about ordering in the Java™ Tutorials. That link explains how straight subtraction and negation of the result can both go wrong.

Two common ways that Comparator is used . . .

You should be using Comparators for any type with more than one possible criterion for ordering. If your type has only one possible criterion for ordering, then make the type implement Comparable. A tree can fail to operate correctly if it has to deal with a type whose compareTo() method isn't “consistent with equals()”.

. . . "This is a positive number that means the first number is bigger and we are sorting in ascending order" . . . "I want to sort in ascending order, are you positive I need to swap these two elements?" . . .

If whatever appears on the left is “larger” than whatever appears on the right, you get a positive result. The built‑in sorting methods always sort in ascending order full stop. If you want to sort descending, you will have to pass a Comparator or similar making 3 bigger than 4. Example:-Afraid I don't know any straightforward mnemonics.

. . . "Am I positive that the new element should be placed to the right of the node I am looking at?" . . .

Or simply remember which is bigger and trust the collection's implementation to sort it for you.

. . . values() explicitly returns a Collection (probably a List but I think not officially specified) . . .

Have you tried it? Have you seen what type is returned from Map#values()? It is most unlikely to be a List.

Question 7 . . . posit[s] a mythical .valueSet() . . . to trick us.

The real exam may contain questions requiring such knowledge of the methods in the API.
 
author & internet detective
Posts: 40283
819
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Added the return type of values() one to the errata. Thanks!
 
No matter. Try again. Fail again. Fail better. This time, do it with this tiny ad:
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
reply
    Bookmark Topic Watch Topic
  • New Topic