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
• Bear Bibeault
• Ron McLeod
• Jeanne Boyarsky
• Paul Clapham
Sheriffs:
• Tim Cooke
• Liutauras Vilda
• Junilu Lacar
Saloon Keepers:
• Tim Moores
• Stephan van Hulst
• Tim Holloway
• fred rosenberger
• salvin francis
Bartenders:
• Piet Souris
• Frits Walraven
• Carey Brown

# Simplifying Boolean & Int

Greenhorn
Posts: 6
1
I always try to use other methods of solving Java exercises, but this particular exercise, I've been trying to figure out what went wrong because I got most of them right, just not the two.

So the question is:

"Given 2 int values, return true if one is negative and one is positive. Except if the parameter "negative" is true, then return true only if both are negative."

My working solution were all correct except for the last part.

I know it can already be simplified to , but I wanted to try and resolve it in this way since it also looks simplified (I'll try to avoid it if it means bad practicing).

This is what I meant by gotten most of them correct when I used , may I know what went wrong?
Capture.PNG

Rancher
Posts: 3571
39
These two bits of code are not equivalent.

Are you saying the first one works, but the second does not?  There are ways you could simplify the first to something very similar to the second.  But, you've made a small error along the way.  Try double checking your work there...

Sheriff
Posts: 15796
264
When you fix the logic error in your boolean expression, you could still simplify it further using the fact that a negative number multiplied by a positive number will be negative. As it is now, your boolean expression is not at all simple to me. In fact, I find it difficult to analyze and reason as to its correctness.

Corey Smith
Greenhorn
Posts: 6
1
@Mike, the first one worked when using ternary operator, meanwhile, the second one was trying to simplify the whole thing and failed in the end. As you can see in the screenshot, I managed to get most of them correct except for the red ones.

@Junilu, I apologize, I did a mistake by posting the entire code there instead of outlining the codes that went wrong.

This is the code that went wrong, everything else worked except for this one.

Positive numbers are supposed to return a false value, but it returns a value of true, this would work if I put "!negative". However, that means the rest of the output are wrong except for positive numbers.

Junilu Lacar
Sheriff
Posts: 15796
264
There are really only eight unique tests you need to cover this functionality completely. Your boolean expression fails when negative is false and both ints are positive so you need to analyze your expression to see why that is.

Marshal
Posts: 69831
278
The way to solve that sort of problem is to look at the logic first. Drawing a Karnaugh map may help. Consider the exclusive or operator for some of the expressions.
If the numbers must be negative or positive, I presume 0 is excluded?
Is this a codingbat exercise? If so, please give us the link to it.

Junilu Lacar
Sheriff
Posts: 15796
264
If you want to stick with boolean operators, the XOR operator (^) returns true only when the two operands are not the same:

Junilu Lacar
Sheriff
Posts: 15796
264
I think the cognitive load that makes your expression more difficult to analyze and understand is the "negative == " part of the expression. Comparing a boolean value with another boolean value is kind of tricky, cognitively speaking. Add to that the name "negative" and you're really going to be messing with people's brains, including yours.

Corey Smith
Greenhorn
Posts: 6
1
@Campbell, I presume..because it did not display any value of 0. Here's the link to that exercise -> https://codingbat.com/prob/p159227

@Junilu, I haven't learned how to implement that in Java yet...But I assume it's like a table of boolean logical operators? (I might be wrong)

Junilu Lacar
Sheriff
Posts: 15796
264

Corey Smith wrote:@Junilu, I haven't learned how to implement that in Java yet...But I assume it's like a table of boolean logical operators? (I might be wrong)

The operator is literally the ^ symbol (caret, usually above the 6 on your keyboard). You can try this in jshell:

jshell> true ^ false
true

jshell> false ^ true
true

jshell> true ^ true
false

jshell> false ^ false
false

Corey Smith
Greenhorn
Posts: 6
1
That is very true indeed, it is why when I read the question, I'd need to keep in mind that "negative" should return true only if both numbers are negative.

Campbell Ritchie
Marshal
Posts: 69831
278

Corey Smith wrote:. . . it did not display any value of 0.

Thank you. If they are either positive or negative, then a 0 input should be banned.

Here's the link . . .

Thank you. Have tried the exercise.

. . . table of boolean logical operators? . . .

Yes it is; it is called a truth table. You can implement it as Junilu showed you: a ^ b. I also suggest you remind yourself about the different precedences of operators, and learn about the ?: operator.

Mike Simmons
Rancher
Posts: 3571
39

Junilu Lacar wrote:When you fix the logic error in your boolean expression, you could still simplify it further using the fact that a negative number multiplied by a positive number will be negative.

Well, it should be.  Unless you overflow...

Mike Simmons
Rancher
Posts: 3571
39

Corey Smith wrote:@Mike, the first one worked when using ternary operator, meanwhile, the second one was trying to simplify the whole thing and failed in the end. As you can see in the screenshot, I managed to get most of them correct except for the red ones.

Well, I understand your first expression well enough, and it works.  So you should revisit what steps you took to simplify it.  I would say, using a ternary can be fine.  Though there's really no need for the second ternary.

is exactly equivalent to

Junilu Lacar
Sheriff
Posts: 15796
264

Mike Simmons wrote:Well, it should be.  Unless you overflow...

Good point. I would stick with XOR then for a simplified expression.

Corey Smith
Greenhorn
Posts: 6
1
I guess some exercise won't be possible to solve with just only return (exclude ternary operator), I thought it is always better to shorten the expression in if-else statement by writing only "return (expression);". Also, I just learned about XOR operator and I understand how it works now.

Thanks you so much guys for helping and also providing several tips to me

Junilu Lacar
Sheriff
Posts: 15796
264

Corey Smith wrote:I guess some exercise won't be possible to solve with just only return (exclude ternary operator), I thought it is always better to shorten the expression in if-else statement by writing only "return (expression);".

One of the primary considerations you should have when writing code is readability. This includes how easy it is for people reading the code to understand it. Clarity and brevity often go together but sometimes one is sacrificed in favor of the other. Prefer sacrificing brevity instead of clarity.

There are many ways to structure the solution code. Here are three that basically use the same formula:

Which one you go with is a matter of conforming with a coding standard or sticking with a personal preference. Any of them would be good enough for me.

Campbell Ritchie
Marshal
Posts: 69831
278
I would go for No 1; it avoids double return and conforms better to the old Sun Style Guide. I think No 1 is much more elegant than the solution codingbat suggested.

Corey Smith
Greenhorn
Posts: 6
1
I'm not sure why but for most of my exercises, I've noticed that I always ended up using No. 2. So whenever I got my working solution correct using No. 2, I'll usually analyze what I wrote and work on a more simplified version of it. I tend to avoid No. 3 because as a beginner, sometimes, I'll wonder how did the return keyword get there without using else, so it confuses me (I know, it sounds really stupid consider that I know how to use if-else but don't know that I can omit "else"). Like what you said, readability should be considered when writing codes, and I guess that's why I might sometimes took it too far and write something that might cause potential logical holes.

@Campbell, Woah, I've never heard about that website, it is very handy to me and yes, I totally agree with you on using No.1, however, I was told to avoid using nested ternary operator because it will severely impact readability. I don't know why but it understand more clearly when the nested ternary operator uses separators instead of writing in one long line.

This is from a reply I gotten from Eddie (I feel the need to credit him as he's helped me through some difficulties I face while learning Java) in one of the exercises in Udemy:

I guess my brain understands it better when the code uses separators, but I'll keep practicing and challenging myself so that my brain is rewired to easily read those long one line codes.

Bartender
Posts: 4006
156

Junilu Lacar wrote:

the part: "a < 0 ^ b < 0" is incorrect. See OP's specification in his/her opening post.

Junilu Lacar
Sheriff
Posts: 15796
264

Piet Souris wrote:the part: "a < 0 ^ b < 0" is incorrect. See OP's specification in his/her opening post.

How so? Specs say "return true if one is negative and one is positive." The specs are unclear as to what to do with 0 and the tests given don't include data with 0. As far as that goes then, the code is correct. Plus, the site accepts that code, too, so it's good enough for me.

Piet Souris
Bartender
Posts: 4006
156
Not good enough for me.

Junilu Lacar
Sheriff
Posts: 15796
264

Piet Souris wrote:Not good enough for me.

That's fine but the site doesn't agree with you.

Campbell Ritchie
Marshal
Posts: 69831
278

Junilu Lacar wrote:. . . The specs are unclear as to what to do with 0 and the tests given don't include data with 0.

Sorry for the delay in replying; I was all busy with other things yesterday.
As far as I am concerned, the specs are crystal‑clear about 0s. If a number is positive or negative, it can't be 0.

As far as that goes then, the code is correct. Plus, the site accepts that code, too, so it's good enough for me.

That is what I tried and got green throughout from codingbat. But I was quite disappointed by the quality of their suggested solution.

Campbell Ritchie
Marshal
Posts: 69831
278

Corey Smith wrote:. . . how did the return keyword get there without using else . . .

That is something you shoule probably familiarise yourself with. The return in the if causes that block to “terminate abruptly” and the flow of control cannot continue to whatever follows the if.

Nice, but I have a allergy to the >= and <= operators. I believe they are harder to read than > and <. I have a concept of the limiting value, which might end 0 or 00. Is that in the lower category in which case you use >, or is it in the upper category so you use <? In the case of grades, the mark ending 0 is usually in the upper category; you get the same grade for 60 as for 69 but more than for 59.  In the case of parcels, the weight ending 0 is in the lower category; a 1000g parcel costs the same as 501g, and less than 1000.1g, if the scales actually read such small divisions.Note additional spaces make operators and numbers align vertically.Note the indentation of the operators is different in each block; you will have to work out an indentation convention for nested ?:a and stick to it. Use whatever is the easiest to read. Round here, if you get <40 in only one module, and that mark is ≥30, you can usually get away without having to resit that one module, hence F_C. Marks work better as enum elements than as literal Strings.

. . . my brain is rewired to easily read those long one line codes.

No, you should rewire the code to make it easier for your brain to understand. Formatting the code shown so all the colons are aligned vertically is a much better solution. The days of restricted memory, when it cost a significant memory overhead to write spaces or line ends in the code, are long gone. Memory is cheap; use it. Brainpower is expensive; conserve it. The days of restricted brainpower, when it cost a significant brainpower overhead to read programs without spaces or line ends in the code, are still with us. Us mods are expensive; you are lucky to get experience free of charge, but if somebody shows us unformatted code, we are liable simply to fling it back with a shout of, “Format it!” You try it with your boss at work. Your unformatted code will come back about 2sec later with, “Don't waste my time with illegible rubbish like that.”

 Consider Paul's rocket mass heater.