Simplifying Boolean & Int

[Corey Smith]

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.

public boolean posNeg(int a, int b, boolean negative) {
  
  // if (negative) {
  //   return (a < 0 && b < 0);
  // } else if  ((a < 0 && b > 0) || (a > 0 && b < 0)) {
  //   return true;
  // } else {
  //   return false;
  // }
  
  // boolean x = (negative ? (a < 0 && b < 0) : ((a < 0 && b > 0) || (a > 0 && b < 0))) ? true : false;
  // return x;
  
  return (negative == (a < 0 && b < 0) || (a > 0 && b < 0) && (a < 0 && b > 0));

}

I know it can already be simplified to

return (negative ? (a < 0 && b < 0) : ((a < 0 && b > 0) || (a > 0 && b < 0))) ? true : false;

, 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

return (negative == (a < 0 && b < 0) || (a > 0 && b < 0) && (a < 0 && b > 0));

, may I know what went wrong?

[Mike Simmons]

These two bits of code are not equivalent.

return (negative ? (a < 0 && b < 0) : ((a < 0 && b > 0) || (a > 0 && b < 0))) ? true : false;

return (negative == (a < 0 && b < 0) || (a > 0 && b < 0) && (a < 0 && b > 0));

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...

[Junilu Lacar]

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]

@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.

return (negative == (a < 0 && b < 0) || (a > 0 && b < 0) && (a < 0 && b > 0));

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]

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.

class Main {
  public static void main(String[] args) {

    // negative = false
    test(-1, -1, false, false);
    test(1, -1, false, true);
    test(-1, 1, false, true);
    test(1, 1, false, false);
    
    // negative = true
    test(-4, -5, true, true);
    test(-4, 5, true, false);
    test(4, -5, true, false);
    test(4, 5, true, false);

  }
  
  static void test(int a, int b, boolean neg, boolean expected) {
    boolean actual = posNeg(a, b, neg);
    System.out.printf("posNeg(%d, %d, %b) -> %b, Run: %b (%s)%n", a, b, neg, expected, actual, expected == actual ? "Pass" : "Fail");
  }
  
  static boolean posNeg(int a, int b, boolean neg) {
    return // your boolean expression goes here
  }
}

[Campbell Ritchie]

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]

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

a    b    (a ^ b)
F    F       F
F    T       T
T    F       T
T    T       F

[Junilu Lacar]

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]

@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]

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]

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]

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]

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]

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.  

(expression) ?  true : false

is exactly equivalent to

(expression)

[Junilu Lacar]

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

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

[Corey Smith]

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]

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:

// 1
public boolean posNeg(int a, int b, boolean negative) {
    return negative ? a < 0 && b < 0 : a < 0 ^ b < 0;
}

// 2
public boolean posNeg(int a, int b, boolean negative) {
    if (negative) {
        return a < 0 && b < 0;
    } else {
        return a < 0 ^ b < 0;
    }
}

// 3
public boolean posNeg(int a, int b, boolean negative) {
    if (negative) {
        return a < 0 && b < 0;
    }
    return a < 0 ^ b < 0;
}

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]

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]

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:

String grade = score >= 90 ? "A"   // if
    : score >= 80 ? "B"            // else if
    : score >= 70 ? "C"            // else if
    : score >= 60 ? "D"            // else if
    : "F";                         // else

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.

[Piet Souris]

Junilu Lacar wrote:

// 1
public boolean posNeg(int a, int b, boolean negative) {
    return negative ? a < 0 && b < 0 : a < 0 ^ b < 0;
}

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

[Junilu Lacar]

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]

Not good enough for me.

[Junilu Lacar]

Piet Souris wrote:Not good enough for me.

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

[Campbell Ritchie]

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]

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.

String grade = score >= 90 ? "A"   // if
    : score >= 80 ? "B"            // else if
    : score >= 70 ? "C"            // else if
    : score >= 60 ? "D"            // else if
    : "F";                         // else

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.

if (weight < 1)
{
   throw new IllegalArgumentException(
            "There is no such thing as a parcel weight 0 or negative.");
}
if (weight > 5000)
{
   throw new OversizedParcelException("Weight = " + weight +
            "g. Maximum accepted = 5000g.");
}
BigDecimal parcelPrice =
         weight > 3000 ? new BigDecimal("14.50")
       : weight > 2000 ? new BigDecimal("11.50")
       : weight > 1000 ? new BigDecimal( "9.50")
       : weight >  500 ? new BigDecimal( "7.50")
       : weight >  200 ? new BigDecimal( "5.50")
                       : new BigDecimal( "3.50");

Note additional spaces make operators and numbers align vertically.

if (mark < 0 || mark > 100)
{
   throw new IllegalArgumentException("Marks only exist in range 0...100inc.");
}
Grade grade =
       mark < 20 ? Grade.U
     : mark < 30 ? Grade.F
     : mark < 40 ? Grade.F_C
     : mark < 50 ? Grade.D
     : mark < 60 ? Grade.C
     : mark < 70 ? Grade.B
     : mark < 80 ? Grade.A
     :             Grade.A_PLUS;

/* Different positioning of the operators. Please decide which is easier to read */ if (mark < 0 || mark > 100) {   throw new IllegalArgumentException("Marks only exist in range 0...100inc."); } Grade grade =       mark < 20 ? Grade.U     :       mark < 30 ? Grade.F     :       mark < 40 ? Grade.F_C   :       mark < 50 ? Grade.D     :       mark < 60 ? Grade.C     :       mark < 70 ? Grade.B     :       mark < 80 ? Grade.A     :                   Grade.A_PLUS;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.”

[fred rosenberger]

sorry i'm late to the party...I hate long, complicated boolean expressions, just like i hate long, complicated regexes.  I'd rather break this down into many small functions that then can be added up to do what you need.  Plus, if your specs change, it's easier to change small pieces than big...

How about a function that counts how many negative numbers there are...

then all you need is

int count = howManyNegative();

if negativeFlag
   return count == 2;
else
   return count == 1

[Junilu Lacar]

fred rosenberger wrote:

int count = howManyNegative();

if negativeFlag
   return count == 2;
else
   return count == 1

Sorry, Fred, I don't understand what that code is trying to do. It looks like it's trying to count how many of the input are negative. Not sure where the boolean negativeFlag gets its value and not sure why you'd want to clobber the value of count that you just queried with either 1 or 2 depending on whether negativeFlag is true. Also, what is negativeFlag flagging? I thought your approach was to count, not flag.

Edit: I misread the code -- for some reason, I thought you were assigning 1 or 2.