Sybex OCP11-Complete - Chapter-3 - Increment and Decrement Operators - Lion and Tiger - Kindle

[Frank Mi]

Hi,

I created a new post because this is on a different book, the complete version. I'm new here and not familiar with the regulation. If this is not allowed, I will delete it.

This problem has been discussed in another post, and according to Campbell Ritchie's reply and tests, the 1z0-815 version, which reads "First, lion is incremented", is correct.

Campbell Ritchie wrote:Yes, as we concluded earlier, the original explanation in the book appears to be correct.

That is to say, in code

int tiger = ++lion *  5 / lion--;

++lion should be evaluated before lion-- because of order of evaluation.

However, it looks like the author misunderstood Campbell Ritchie and put it into errata again.

Jeanne Boyarsky wrote:And back to errata.

And now, it is still in the errata of 1z0-815, and to the contrary, the complete study guide reads "First, lion is decremented."

I can tell, only one of the two versions is correct, right? In my own opinion, the original one is correct.

[Campbell Ritchie]

Welcome to the Ranch

Not got the time or energy to go through this problem in detail, but it appears from the older discussion you quoted that the older versions of the book had the correct explanation but not the later edition. I think my example starting −1 shows that the ++ is executed first. If the -- were executed first, the code wouldn't throw an exception.

[Frank Mi]

Thanks. ^_^

Yes, long story short, the 1z0-815 book might be correct (the same as what you said), but it was put into errata incorrectly, then affect the new complete version.

[Campbell Ritchie]

Again to cut a long story short, whichever version says ++ is executed first is correct.

[Frank Mi]

Got it, thanks. I don't know how to @ person in this forum, could you tell me how to inform the authors to put it onto errata?

[Campbell Ritchie]

Please wait; one of the authors checks this forum regularly.

[Jeanne Boyarsky]

I've added it back to the errata. Scott and I discussed it and we want to get rid of this example. it's too complicated for the exam. It's also too complicated to explain/understand to be useful.

[Frank Mi]

Hi Jeanne and Scott,

Thank you for your reply. Though I don't agree that it is too complicated, actually it is common and in scope of the exam. So please modify but don't get rid of the example.

According to JLS §15.7.1:

JLS §15.7.1 wrote:The left-hand operand of a binary operator appears to be fully evaluated before any part of the right-hand operand is evaluated.

So that,

int tiger = ++lion * 5 / lion--;

is the same as:

int tiger = ((++lion) * 5) / lion--;

Other than that, I've seen several java mock exam questions like the following one:

int x1 = 10;
int y1 = x1++ - ++x1; // y1 = ((x1++) - ++x) = 10 - 12 = -2

int x2 = 10;
int y2 = ++x2 - x2++; // y2 = ((++x2) - x2++) = 11 - 11 = 0

These questions are fine and should be understood by us.

Do you think what I said make sense?

[Jeanne Boyarsky]

Frank,
The number of people who found it confusing suggests it isn't furthering our goals here . I'm glad you understand it though!

[Frank Mi]

Hi Jeanne,

Sorry for bothering you again. But the information in the Errata (both the 1z0-815 and the complete version) is still incorrect. It should be "++lion should execute before lion–",  rather than after.

[Jeanne Boyarsky]

Frank Mi wrote:Hi Jeanne,

Sorry for bothering you again. But the information in the Errata (both the 1z0-815 and the complete version) is still incorrect. It should be "++lion should execute before lion–",  rather than after.

Yup. Thank you

[Cristian Sanchez]

I was reading the edition published in Oreily, I believe the example is a pretty good one, but maybe you can use other numbers in order to avoid that as readers we misunderstand the example.

In the book, we can see

int tiger = 3 * 5 / 3;

Which unfortunately has the same result as the following

int tiger = 4 * 5 / 4;

And that result is (at least from my point of view) the one that got me confused.

After changing the value of the lion's variable to a different number is easier to understand how the operators are changing the lion variable.

[Clark Rig]

I've just signed up to Coderanch because I'm finding so many errors in the complete study guide already, and having reached this one now at chapter 3 my frustration is growing.

To explain my misunderstandings better:
It's not clear in the explanations how the post increment/decrement has the highest order of precedence, since the increment/decrement operation itself happens after the operand has been applied to lower order operations.

The example is also ambiguous because any way you evaluate it, the answer will be the same.

Maybe this is clearer?  

int lion = 1;
int tiger = ++lion * 1 / lion--;

System.out.println("tiger = "+tiger+" lion = "+lion);

OUTPUT:

tiger = 1 lion = 1

CORRECT EVALUATION:

tiger = 2 * 1 / 2 = 1
lion = lion - 1 = 1 (post decrement)

[Jesse Silverman]

I think many people who have gone thru the whole study guide found the Lion and Tiger example one of the most problematic questions/answers/explanations.

There was disagreement about whether it was a good question in the first place or not, I think it is but agree that the initial values could have been chosen better to be more illustrative of what is going on.

Reporting errata had grown into a hobby for me, but I definitely don't regret either buying the book (books, I have the two-volume version) or using it as my primary study guide.

If you understand that specific problem the best move is to probably move on for now and remember to check their errata page for each chapter before starting it.

One thing I was reminded of recently -- if the problem is with the suggested answer(s) for a chapter review question, the errata will be at the page at the end with the answers for it, not on the page with the question, but you probably already know that.

The whole Lion and Tiger thing sparked a whole lot of discussion a while back, and I got a lot from that discussion itself.
The value of it is questionable, because one guideline of writing clear code that is widely accepted is "Do not write expressions that require memorizing the operator precedence table to understand, some good developers will misread it and get confused."

For the exam some people say "Don't bother to memorize the operator precedence table", but at least for the mock questions I've seen, not remembering it could bite you.

Some said memorizing "ASRL" (i.e. Arithmetic, Shift, Relational, Logical) is enough, but there are a few questions where you need to remember that non-short-circuit logical operators are applied before the short-circuit ones, and in the order of &, then ^, then |, or that the assignment operators, including compound ones like *= happen dead last, even after ? : -- you need to remember that stuff to be totally safe on the exams it would seem.

The funniest thing was one instructor gave the dumbest mnemonic I ever heard, he taught that "The unary operators happen first, because that is the easiest to do.  Then the binary operators, because those are harder, then the ternary operator" but after complaining it was the dumbest thing I ever heard I never forgot that again.  Unfortunately, the assignment operators (including the compound ones like /=) are even lower in precedence...

I personally find talking/writing about these things to be the best way for me to actually remember them long term.

I don't think you will have a lot of complaints going forward of this level (most of my complaints are nit-picking about wording), but I will be sure to read them if you do, and so will the authors eventually.

[Clark Rig]

I would say that the table 3.1 is incorrect also because post increment/post decrement must come last in order of arithmetic precedence. But for some reason it is placed at the top.

[Jesse Silverman]

I am not sure I agree.  Let's look at an example because it is confusing.

int x = 1;
int y = 0;
int z = x++ + y++;

In JShell this looks like this:

jshell> int x = 1
x ==> 1

jshell> int y = 0
y ==> 0

jshell> int z = x++ + y++
z ==> 1

jshell> x
x ==> 2

jshell> y
y ==> 1

Explanation: First thing the first operand is evaluated.  x returns its previous value of 1 and gets incremented to 2.
Then the second operand to the + gets evaluated, I think.  y returns its previous value of 0 and gets incremented to 1.
Then those two operands 1 and 0 get added together yielding the result of 1.
If we now look at x and y, we will see the results of the post-increment operators reflected in their values as shown.

This gets more confusing to some people if we have more than one of them (anybody who codes like this should be placed in solitary confinement until they finish judging the next Obfuscated C contest and find a winner)...

jshell> x = 4
x ==> 4

jshell> y = 5
y ==> 5

jshell> z = x++ + y++ + x++ + y++
z ==> 20

If I was allowed to, I would fire anybody on my team that tried to check code like that in, but the results are as I expect.

Why would you say the post-decrements get placed last in operator precedence?  They clearly come before + as we see here.
What comes last is the = of course.  Everything else is already done by then, and the smoke clears....

jshell> x
x ==> 6

jshell> y
y ==> 7

[Jesse Silverman]

And Doh!!  "Welcome to the Ranch, Clark!!"

We really are friendly folk around here, but sometimes the content of the post is so provocative we may forget our manners like it seems I did.

[Clark Rig]

I guess when I think about the post decrement in my mind I reason that it has no bearing on the equation at hand, and therefore the increment operation itself has the lowest precedence.
I suppose there's another way to think about it, but that's how I look at it currently (edit: it appears that way in your Jshell also as the post increments of x and y occur after each addition operation).

I have however just discovered something new, explained in the book in review 3 which has completely thrown me off, and that's that the post operation gets discarded in some cases:

int x = 0;
x = x++;
x == 0 is true.

[Clark Rig]

Jesse Silverman wrote:And Doh!!  "Welcome to the Ranch, Clark!!"

We really are friendly folk around here, but sometimes the content of the post is so provocative we may forget our manners like it seems I did.

Thanks! I appreciate your feedback!

[Jesse Silverman]

This is really pathological, like what if you are microwaving a gremlin when the microwave falls into a bathtub full of heavy water weird, it would never happen in Real Life but they like the questions like this on the Game (I mean Cert Exam) so...

int x = 0; // x is 0, okay

x = x++; // three parts.  We take the value of x, currently 0, to be the value of the expression.
             // next, we increment the value of x, after we have used it, so x is very briefly 1.
             // lastly, because like we said, it has the lowest precedence, finally we take the result from before, which you will recall was 0 and assign that to x.
             // so of course, now at this point, x == 0 is true.

This is less common in real life than a python and an alligator trying to eat each other, while on video, but there we are!

[Clark Rig]

Jesse Silverman wrote:what if you are microwaving a gremlin when the microwave falls into a bathtub full of heavy water weird

That's a genius parallel. Hilarious :-D

I have a lot more to do on this topic.
Thanks for introducing me to jshell, that's very useful! (it's not listed in the book as a command packaged with the JDK. I'll have to see what else is there).

EDIT: Look, my mind is blown again. The parentheses don't change the outcome even though they have a higher order of precedence:

jshell> int x = 0;
x ==> 0

jshell> x = (x++)
x ==> 0


Cheers,
Clark

P.S. I wish the answers were organised at the end of each chapter rather than clumped together somewhere at the back of a ~1200 page book too.

[Jesse Silverman]

Two things.

1. Is this all just pointless stuff like frat hazing, or essential to proving you understand Java?
There is a rule (that is only enforced in certain places) "Don't write any code that requires somebody to have memorized the stupid precedence table to be able to read it!!  Parenthesis cost literally NOTHING at run time, and if you clever code is misread by even one in twenty readers, guess what? -- it sucks" (I may have paraphrased the rule a bit.)

If you work on a large team, and even one or two people fails to follow that, you are still fine as long as everyone follows the other rule "Know the precedence table well enough to be sure that your expressions always mean what you and the rest of your team think they do.  If you misinterpret what any expression does, you are not understanding the code you are working on, and likely to break it in hilarious ways."

I question whether anyone who says they never worked on a large team where someone ignored the first rule and someone else ignored the second rule ever actually worked on a large team.  Code reviews should catch these things but code reviewers are notoriously overworked and too busy and are rushing thru them and likely to make the same mistakes as other readers of the code.  Yes, it is even more important for those doing Code Reviews to be able to look at a bunch of code pretty quickly, and notice if what it does differs at all from what it probably meant to do -- this is something I really think one gets better at by practicing for the exam.

2. So, when I worked with large teams of developers, many of whom violated each rule, and while not doing code reviews much, indeed was co-ordinating and analyzing the results of our Unit Testing and other overnight stuff (and the builds) -- and we are talking about millions of lines of code....literally NO ONE was surprised that I had a copy of the precedence chart for our main language (not Java then) on my cube wall.  When someone blew up our whole world by violating both rules, i.e. forgetting some part of the table and then writing code that depended on it which behaved differently than what they thought it would do and somehow it slipped past their overburdened code reviewer(s)...I might photocopy it so they can stick it up on their cube wall for (well, sometimes a long time)...I wouldn't say this happened daily unless it was a busy week, but if we went a whole week that this never happened it was a quiet one.

3. So the point is, the safest way to play life would be to totally memorize the table and what it means (as you allude  to, many people may even have it memorized but be confused about what it actually means, it really only tells you what an equivalent expression that had explicit parenthesis would look like, but short-circuit evaluation may really change what gets evaluated at all)...to memorize some or all or much of it AND....not to write tricky code that depends on memorizing it to be understood, lest you cause workplace accidents...

This point really is, I *know* all this but kept waffling around about which parts I should have memorized.  Recently, reviewing as I move forward with the Advanced Cool-Sounding Chapters that make it sound like you are an Advanced Java Professional, I realized two things both of which got posted somewhere in this forum.
b. bitwise operations with integers are NOT on the exam any more, they didn't disappear from Real Life but the exam just had too much stuff to cover, so bye!
That didn't mean that non-short-circuit logical ones are out-of-scope.  You should know the precedence of &, ^, | versus && and || and everything else, that is fair game.

a. The last thing that happens, I mean ummmm -- the lowest, lowest precedence is assignment.  Plain old =.  +=, *=, /=, <<=, %=, all the assignments.  They also associate right to left, so we can get lazy and write:
int a = b = c = x / y;

I can't tell you what to do, but if you forget the precedence of the assignment operators you will be confused by mock test questions involving it, and in fact, could write code that doesn't do exactly what you meant it to or more likely, misunderstand your mate's code that you are working on and accidentally break things...

Now I am really, really much less likely to forget these things after telling this whole story!  It causes stuff to stick in my mind by engaging the parts of my brain that involves people and feelings and such instead of just mathematical operators and "Please Excuse My Dumb Aunt Sally" (it was considered okay for people to say those kinds of things back when she grew up)...