ternary operator not working - java

Netbeans is saying that my ternary operator isn't a statement. How come?
int direction;
direction = (Math.random() < 0.5) ? 0 : 1; // direction is either L or R (0 or 1)
direction == 0 ? System.out.print('L') : System.out.print('R');
I tried it's if/then/else counterpart and it works fine:
int direction;
direction = (Math.random() < 0.5) ? 0 : 1; // direction is either L or R (0 or 1)
if(direction == 0){
System.out.print('L');
} else {
System.out.print('R');
}

The statements in the ternary operator need to be non-void. They need to return something.
System.out.println(direction == 0 ? 'L' : 'R');

A ternary operator is intended to evaluate one of two expressions, not to execute one of two statements. (Invoking a function can be an expression if the function is declared to return a value; however, System.out is a PrintStream and PrintStream.print is a void function.) You can either stick with the if...else structure for what you're trying to do or you can do this:
System.out.print(direction == 0 ? 'L' : 'R');
NOTE: The comment by #iamcreasy points out a bit of imprecision in how I phrased things above. An expression can evaluate to nothing, so what I should have said was that a ternary operator evaluates one of two non-void expressions. According to the Java Language Specification §15.25:
It is a compile-time error for either the second or the third operand
expression to be an invocation of a void method.

From the JLS section 15.25. Conditional Operator ?:
It is a compile-time error for either the second or the third operand expression to be an invocation of a void method.
both the second and third operand expression here:
direction == 0 ? System.out.print('L') : System.out.print('R');
are void so this is a not a valid use of a ternary expression. You could either stick to the if else or use something similar to this alternative:
System.out.print( direction == 0 ? 'L' : 'R' );
Also the logic here is not correct:
direction = (int)(Math.random() * 1);
direction will always evaluate to 0 since Math.random() generates numbers in the range [0.0,1.0) which means it does not include 1.0 and casting a double to int will just drop the decimals. Using nextInt(2) is a good alternative.

Related

Java: boolean expression (x==y && a<b) [duplicate]

Which set is short-circuiting, and what exactly does it mean that the complex conditional expression is short-circuiting?
public static void main(String[] args) {
int x, y, z;
x = 10;
y = 20;
z = 30;
// T T
// T F
// F T
// F F
//SET A
boolean a = (x < z) && (x == x);
boolean b = (x < z) && (x == z);
boolean c = (x == z) && (x < z);
boolean d = (x == z) && (x > z);
//SET B
boolean aa = (x < z) & (x == x);
boolean bb = (x < z) & (x == z);
boolean cc = (x == z) & (x < z);
boolean dd = (x == z) & (x > z);
}
The && and || operators "short-circuit", meaning they don't evaluate the right-hand side if it isn't necessary.
The & and | operators, when used as logical operators, always evaluate both sides.
There is only one case of short-circuiting for each operator, and they are:
false && ... - it is not necessary to know what the right-hand side is because the result can only be false regardless of the value there
true || ... - it is not necessary to know what the right-hand side is because the result can only be true regardless of the value there
Let's compare the behaviour in a simple example:
public boolean longerThan(String input, int length) {
return input != null && input.length() > length;
}
public boolean longerThan(String input, int length) {
return input != null & input.length() > length;
}
The 2nd version uses the non-short-circuiting operator & and will throw a NullPointerException if input is null, but the 1st version will return false without an exception.
SET A uses short-circuiting boolean operators.
What 'short-circuiting' means in the context of boolean operators is that for a set of booleans b1, b2, ..., bn, the short circuit versions will cease evaluation as soon as the first of these booleans is true (||) or false (&&).
For example:
// 2 == 2 will never get evaluated because it is already clear from evaluating
// 1 != 1 that the result will be false.
(1 != 1) && (2 == 2)
// 2 != 2 will never get evaluated because it is already clear from evaluating
// 1 == 1 that the result will be true.
(1 == 1) || (2 != 2)
Short circuiting means the second operator will not be checked if the first operator decides the final outcome.
E.g. Expression is: True || False
In case of ||, all we need is one of the side to be True. So if the left hand side is true, there is no point in checking the right hand side, and hence that will not be checked at all.
Similarly, False && True
In case of &&, we need both sides to be True. So if the left hand side is False, there is no point in checking the right hand side, the answer has to be False. And hence that will not be checked at all.
boolean a = (x < z) && (x == x);
This kind will short-circuit, meaning if (x < z) evaluates to false then the latter is not evaluated, a will be false, otherwise && will also evaluate (x == x).
& is a bitwise operator, but also a boolean AND operator which does not short-circuit.
You can test them by something as follows (see how many times the method is called in each case):
public static boolean getFalse() {
System.out.println("Method");
return false;
}
public static void main(String[] args) {
if(getFalse() && getFalse()) { }
System.out.println("=============================");
if(getFalse() & getFalse()) { }
}
In plain terms, short-circuiting means stopping evaluation once you know that the answer can no longer change. For example, if you are evaluating a chain of logical ANDs and you discover a FALSE in the middle of that chain, you know the result is going to be false, no matter what are the values of the rest of the expressions in the chain. Same goes for a chain of ORs: once you discover a TRUE, you know the answer right away, and so you can skip evaluating the rest of the expressions.
You indicate to Java that you want short-circuiting by using && instead of & and || instead of |. The first set in your post is short-circuiting.
Note that this is more than an attempt at saving a few CPU cycles: in expressions like this
if (mystring != null && mystring.indexOf('+') > 0) {
...
}
short-circuiting means a difference between correct operation and a crash (in the case where mystring is null).
Java provides two interesting Boolean operators not found in most other computer languages. These secondary versions of AND and OR are known as short-circuit logical operators. As you can see from the preceding table, the OR operator results in true when A is true, no matter what B is.
Similarly, the AND operator results in false when A is false, no matter what B is. If you use the || and && forms, rather than the | and & forms of these operators, Java will not bother to evaluate the right-hand operand alone. This is very useful when the right-hand operand depends on the left one being true or false in order to function properly.
For example, the following code fragment shows how you can take advantage of short-circuit logical evaluation to be sure that a division operation will be valid before evaluating it:
if ( denom != 0 && num / denom >10)
Since the short-circuit form of AND (&&) is used, there is no risk of causing a run-time exception from dividing by zero. If this line of code were written using the single & version of AND, both sides would have to be evaluated, causing a run-time exception when denom is zero.
It is standard practice to use the short-circuit forms of AND and OR in cases involving Boolean logic, leaving the single-character versions exclusively for bitwise operations. However, there are exceptions to this rule. For example, consider the following statement:
if ( c==1 & e++ < 100 ) d = 100;
Here, using a single & ensures that the increment operation will be applied to e whether c is equal to 1 or not.
Logical OR :- returns true if at least one of the operands evaluate to true. Both operands are evaluated before apply the OR operator.
Short Circuit OR :- if left hand side operand returns true, it returns true without evaluating the right hand side operand.
There are a couple of differences between the & and && operators. The same differences apply to | and ||. The most important thing to keep in mind is that && is a logical operator that only applies to boolean operands, while & is a bitwise operator that applies to integer types as well as booleans.
With a logical operation, you can do short circuiting because in certain cases (like the first operand of && being false, or the first operand of || being true), you do not need to evaluate the rest of the expression. This is very useful for doing things like checking for null before accessing a filed or method, and checking for potential zeros before dividing by them. For a complex expression, each part of the expression is evaluated recursively in the same manner. For example, in the following case:
(7 == 8) || ((1 == 3) && (4 == 4))
Only the emphasized portions will evaluated. To compute the ||, first check if 7 == 8 is true. If it were, the right hand side would be skipped entirely. The right hand side only checks if 1 == 3 is false. Since it is, 4 == 4 does not need to be checked, and the whole expression evaluates to false. If the left hand side were true, e.g. 7 == 7 instead of 7 == 8, the entire right hand side would be skipped because the whole || expression would be true regardless.
With a bitwise operation, you need to evaluate all the operands because you are really just combining the bits. Booleans are effectively a one-bit integer in Java (regardless of how the internals work out), and it is just a coincidence that you can do short circuiting for bitwise operators in that one special case. The reason that you can not short-circuit a general integer & or | operation is that some bits may be on and some may be off in either operand. Something like 1 & 2 yields zero, but you have no way of knowing that without evaluating both operands.
if(demon!=0&& num/demon>10)
Since the short-circuit form of AND(&&) is used, there is no risk of causing a run-time exception when demon is zero.
Ref. Java 2 Fifth Edition by Herbert Schildt
Document from docs.oracle
As logical expressions are evaluated left to right, they are tested for possible “short-circuit” evaluation using these rules:
false && anything is short-circuit evaluated to false.
true || anything is short-circuit evaluated to true.
The rules of logic guarantee that these evaluations are always correct. Note that the anything part of the above expressions is not evaluated, so any side effects of doing so do not take effect.
https://docs.oracle.com/cd/E57185_01/HIRUG/ch31s05s01.html

Short - Circuit OR and OR [duplicate]

Which set is short-circuiting, and what exactly does it mean that the complex conditional expression is short-circuiting?
public static void main(String[] args) {
int x, y, z;
x = 10;
y = 20;
z = 30;
// T T
// T F
// F T
// F F
//SET A
boolean a = (x < z) && (x == x);
boolean b = (x < z) && (x == z);
boolean c = (x == z) && (x < z);
boolean d = (x == z) && (x > z);
//SET B
boolean aa = (x < z) & (x == x);
boolean bb = (x < z) & (x == z);
boolean cc = (x == z) & (x < z);
boolean dd = (x == z) & (x > z);
}
The && and || operators "short-circuit", meaning they don't evaluate the right-hand side if it isn't necessary.
The & and | operators, when used as logical operators, always evaluate both sides.
There is only one case of short-circuiting for each operator, and they are:
false && ... - it is not necessary to know what the right-hand side is because the result can only be false regardless of the value there
true || ... - it is not necessary to know what the right-hand side is because the result can only be true regardless of the value there
Let's compare the behaviour in a simple example:
public boolean longerThan(String input, int length) {
return input != null && input.length() > length;
}
public boolean longerThan(String input, int length) {
return input != null & input.length() > length;
}
The 2nd version uses the non-short-circuiting operator & and will throw a NullPointerException if input is null, but the 1st version will return false without an exception.
SET A uses short-circuiting boolean operators.
What 'short-circuiting' means in the context of boolean operators is that for a set of booleans b1, b2, ..., bn, the short circuit versions will cease evaluation as soon as the first of these booleans is true (||) or false (&&).
For example:
// 2 == 2 will never get evaluated because it is already clear from evaluating
// 1 != 1 that the result will be false.
(1 != 1) && (2 == 2)
// 2 != 2 will never get evaluated because it is already clear from evaluating
// 1 == 1 that the result will be true.
(1 == 1) || (2 != 2)
Short circuiting means the second operator will not be checked if the first operator decides the final outcome.
E.g. Expression is: True || False
In case of ||, all we need is one of the side to be True. So if the left hand side is true, there is no point in checking the right hand side, and hence that will not be checked at all.
Similarly, False && True
In case of &&, we need both sides to be True. So if the left hand side is False, there is no point in checking the right hand side, the answer has to be False. And hence that will not be checked at all.
boolean a = (x < z) && (x == x);
This kind will short-circuit, meaning if (x < z) evaluates to false then the latter is not evaluated, a will be false, otherwise && will also evaluate (x == x).
& is a bitwise operator, but also a boolean AND operator which does not short-circuit.
You can test them by something as follows (see how many times the method is called in each case):
public static boolean getFalse() {
System.out.println("Method");
return false;
}
public static void main(String[] args) {
if(getFalse() && getFalse()) { }
System.out.println("=============================");
if(getFalse() & getFalse()) { }
}
In plain terms, short-circuiting means stopping evaluation once you know that the answer can no longer change. For example, if you are evaluating a chain of logical ANDs and you discover a FALSE in the middle of that chain, you know the result is going to be false, no matter what are the values of the rest of the expressions in the chain. Same goes for a chain of ORs: once you discover a TRUE, you know the answer right away, and so you can skip evaluating the rest of the expressions.
You indicate to Java that you want short-circuiting by using && instead of & and || instead of |. The first set in your post is short-circuiting.
Note that this is more than an attempt at saving a few CPU cycles: in expressions like this
if (mystring != null && mystring.indexOf('+') > 0) {
...
}
short-circuiting means a difference between correct operation and a crash (in the case where mystring is null).
Java provides two interesting Boolean operators not found in most other computer languages. These secondary versions of AND and OR are known as short-circuit logical operators. As you can see from the preceding table, the OR operator results in true when A is true, no matter what B is.
Similarly, the AND operator results in false when A is false, no matter what B is. If you use the || and && forms, rather than the | and & forms of these operators, Java will not bother to evaluate the right-hand operand alone. This is very useful when the right-hand operand depends on the left one being true or false in order to function properly.
For example, the following code fragment shows how you can take advantage of short-circuit logical evaluation to be sure that a division operation will be valid before evaluating it:
if ( denom != 0 && num / denom >10)
Since the short-circuit form of AND (&&) is used, there is no risk of causing a run-time exception from dividing by zero. If this line of code were written using the single & version of AND, both sides would have to be evaluated, causing a run-time exception when denom is zero.
It is standard practice to use the short-circuit forms of AND and OR in cases involving Boolean logic, leaving the single-character versions exclusively for bitwise operations. However, there are exceptions to this rule. For example, consider the following statement:
if ( c==1 & e++ < 100 ) d = 100;
Here, using a single & ensures that the increment operation will be applied to e whether c is equal to 1 or not.
Logical OR :- returns true if at least one of the operands evaluate to true. Both operands are evaluated before apply the OR operator.
Short Circuit OR :- if left hand side operand returns true, it returns true without evaluating the right hand side operand.
There are a couple of differences between the & and && operators. The same differences apply to | and ||. The most important thing to keep in mind is that && is a logical operator that only applies to boolean operands, while & is a bitwise operator that applies to integer types as well as booleans.
With a logical operation, you can do short circuiting because in certain cases (like the first operand of && being false, or the first operand of || being true), you do not need to evaluate the rest of the expression. This is very useful for doing things like checking for null before accessing a filed or method, and checking for potential zeros before dividing by them. For a complex expression, each part of the expression is evaluated recursively in the same manner. For example, in the following case:
(7 == 8) || ((1 == 3) && (4 == 4))
Only the emphasized portions will evaluated. To compute the ||, first check if 7 == 8 is true. If it were, the right hand side would be skipped entirely. The right hand side only checks if 1 == 3 is false. Since it is, 4 == 4 does not need to be checked, and the whole expression evaluates to false. If the left hand side were true, e.g. 7 == 7 instead of 7 == 8, the entire right hand side would be skipped because the whole || expression would be true regardless.
With a bitwise operation, you need to evaluate all the operands because you are really just combining the bits. Booleans are effectively a one-bit integer in Java (regardless of how the internals work out), and it is just a coincidence that you can do short circuiting for bitwise operators in that one special case. The reason that you can not short-circuit a general integer & or | operation is that some bits may be on and some may be off in either operand. Something like 1 & 2 yields zero, but you have no way of knowing that without evaluating both operands.
if(demon!=0&& num/demon>10)
Since the short-circuit form of AND(&&) is used, there is no risk of causing a run-time exception when demon is zero.
Ref. Java 2 Fifth Edition by Herbert Schildt
Document from docs.oracle
As logical expressions are evaluated left to right, they are tested for possible “short-circuit” evaluation using these rules:
false && anything is short-circuit evaluated to false.
true || anything is short-circuit evaluated to true.
The rules of logic guarantee that these evaluations are always correct. Note that the anything part of the above expressions is not evaluated, so any side effects of doing so do not take effect.
https://docs.oracle.com/cd/E57185_01/HIRUG/ch31s05s01.html

Java - ternary operator weird behaviour

I was trying to remove the fractional part from a double in case it is whole using:
(d % 1) == 0 ? d.intValue() : d
And encountered the following behavior which i don't understand:
public static void main(String[] args) {
Double d = 5D;
System.out.println((d % 1) == 0); // true
System.out.println((d % 1) == 0 ? d.intValue() : "not whole"); // 5
System.out.println((d % 1) == 0 ? d.intValue() : d); // 5.0
}
As you can see on the third line, the operator chooses the else value - 5.0 even though the condition (d % 1) == 0 is met.
What's going on here?
The return type of the ternary conditional operator must be such that both the 2nd and 3rd operands can be assigned to it.
Therefore, in your second case, the return type of the operator is Object (since both d.intValue() and "not whole" must be assignable to it) while in the third case it is Double (since both d.intValue() and d must be assignable to it).
Printing an Object whose runtime type is Integer gives you 5 while printing a Double gives you 5.0.
The type of an expression a ? b : c is always the same as c or the closest common parent of b and c.
System.out.println((d % 1) == 0 ? d.intValue() : "not whole"); // Comparable a parent of Integer and String
System.out.println((d % 1) == 0 ? d.intValue() : d); // Double is a widened int
BTW d % 1 will only check it is a whole not, not that it's small enough to fit in anint value. A safer check is to see if the value is the same when cast to an int or long
double d = 5.0;
if ((long) d == d)
System.out.println((long) d);
else
System.out.println(d);
or you can prevent it widening the long back to a double with
double d = 5.0;
System.out.println((long) d == d ? Long.toString((long) d) : Double.toString(d));
It chooses correctly. Then it wraps it in double. These are 3 key points:
If the second and third operands have the same type, that is the type of the conditional expression. In other words, you can avoid the whole mess by steering clear of mixed-type computation.
If one of the operands is of type T where T is byte , short , or char and the other operand is a constant expression of type int whose value is representable in type T, the type of the conditional expression is T.
Otherwise, binary numeric promotion is applied to the operand types, and the type of the conditional expression is the promoted type of the second and third operands.
In your case the second and third arguments of the ternery operator are types "int" and "Double". Java must convert these values to the same type so they can be returned from the ternary operator. The rules for doing this are given in the Java language specification. https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.25
In your case these rules result in the conversion of both parameters to type "double" (the "Double" is unboxed, the int is value-converted).
The fix is to cast the arguments to the ternary operator so that they are of the same type (there may be more brackets in the below than strictly needed, i'm a bit rusty on java operator precedence rules).
System.out.println((d % 1) == 0 ? ((Number)(d.intValue())) : (Number)d);

Java operator precendece confusion && and ++

&& is a short-circuit operator evaluated from left to right, so if the operand on the left side of && operator is evaluated to false, evaluation should not continue. BUT I expected that the ++ should be evaluated before && because it has higher precedence, and (from the link):
Operators with higher precedence are evaluated before operators with relatively lower precedence.
In that case, why doesn't count increment in the third line of this code?
int mask = 2;
int count = 0;
if( !(mask > 1) && ++count > 1) { mask += 100; }
System.out.println(mask + " " + count);
No, the way the expression is evaluated goes from left to right, while taking operator precedence into account. So once in a && b the a gets false, b is not evaluated anymore.
JLS §15.23. Conditional-And Operator && says:
The conditional-and operator && is like & (§15.22.2), but evaluates its right-hand operand only if the value of its left-hand operand is true.
Here is a detailed step by step evaluation of how this works:
This is because, when you parse an expression as a human being, you start with the lowest precedence operators first. In this case && has lower precedence then ++.
++a < 0 && foo
^^
start
In order to compute the result of &&, you should know the left operand:
++a < 0 && ++b
^^^^^^^
so compute this
Now, when you want to know the result of ++a < 0, take a look at the lowest precedence operator first, which is <:
++a < 0
^
evaluate this
In order to do that, you will need both left and right operand. So compute them:
++a
0
This is the moment were ++a gets increased.
So, now we are at the bottom. Let's make our way back to the top:
false && foo
And this is where the fact that && is short circuit comes in. Left operand is false, so the right operand expression foo is not evaluated anymore. Which becomes:
false
without the evaluation of the right operand.
Edit: I missed the point of the question. See revisions for semi-detailed explanation of short-circuit evaluation.
Each operand of the logical-AND and logical-OR operators is a separate expression, and thus, treated independently (given its own order of operators to evaluate, according to correct operator precedence).
So, while ++ has the highest precedence in ++count > 1, that expression is never even evaluated (because of the short-circuiting).
You seem to be dissatisfied with the short circuit evaluation explanation. Why is precedence not important here?
Imagine this code:
if( !(mask > 1) && Increment(count) > 1)
Function application (that is, calling a function by writing the brackets) is the highest precedence, yet the function call will never happen. If short circuit evaluation made allowances for precedence, it wouldn't really work at all.
To expand a little - operators such as ++ , - , etc all map to function calls. However, the compiler needs to understand the order that they bind. This is not the order that they are evaluated in.
So a + b * c doesn't mean workout b * c then the sum. It means only this add( a, multiply(b, c)) The order of evaluation is different in the case of && (though not in my example), to make it easier for programmers to write quick code.
To avoid confusion, recall that
if (a && b) {
// do something
}
is semantically the same as:
if (a) {
if (b) {
// do something
}
}
Obviously, if a evaluates to false, the term b will never be seen. In particular, an increment opertor there will not execute.
By recalling this expansion, the behaviour should be easier to understand. It's best to consider && as a shortcut for above nested-if statement. (In the case of having an else statement, you will also need to add two copies of the else code, so it's not as easy.)
A more "exact" representation would be to use a condition method:
boolean condition() {
if (!a) return false;
if (!b) return false;
return true;
}
Again, b will never be evaluated if a returns false already.
if( !(mask > 1) && ++count > 1) { mask += 100; }
What this line indicates is:
!(2>1) ie !(true) ie false
In && left side is false it doesnot futher go for checking rightside
so count is not incremented.

What is the difference between '==' and '='?

I know that one of them is bitwise and the other is logical but I can not figure this out:
Scanner sc = new Scanner(System.in);
System.out.println("Enter ur integer");
int x=sc.nextInt();
if(x=0)//Error...it can not be converted from int to boolean
System.out.println("...");
The error means that x cannot be converted to boolean or the result of x=0 can not be converted to boolean.
== checks for equality.
= is assignment.
What you're doing is:
if( x = Blah ) - in Java this statement is illegal as you can not test the state of an assignment statement. Specifically, Java does not treat assignment as a boolean operation, which is required in an if statement. This is in contrast with C/C++, which DOES allow you to treat assignment as a boolean operation, and can be the result of many hair-pulling bugs.
When you write 'x = 0' you are saying "Store 0 in the variable x". The return value on the whole expression is '0' (it's like this so you can say silly things like x = y = 0).
When you write 'x == 0' it says "Does x equal 0?". The return value on this expression is going to be either 'true' or 'false'.
In Java, you can't just say if(0) because if expects a true/false answer. So putting if(x = 0) is not correct, but if(x == 0) is fine.
== is a comparison operator, and = is assignment.
== is an equality check. if (x == 0) // if x equals 0
= is an assignment. x = 0; // the value of x is now 0
I know the question has been answered, but this still comes up from time to time not as a programmer error but as a typographical error (i.e., the programmer knew what he meant, but failed). It can be hard to see, since the two look so similar.
I've found that a way to help avoid doing this is to put the constant expression on the left-hand-side, like so:
if (0 == x)
...
That way, if I accidentally use only one "=" sign, the compiler will fail with an error about assigning to a constant expression, whether or not the assignment operator is left-associative and whether the if conditional expects a strongly-typed Boolean.
if(x=0)
Here you're assigning the value of 0 to the variable x. The if statement in Java can't evaluate an integer argument as it can in many other languages. In Java, if requires a boolean. Try
if(x == 0)
to do a comparison.
Interpret the error to mean
"The expression
x=0
cannot be converted to Boolean."
Just to clarify about C/C++ - assignment is evaluated to the right operand
if(a = n)
is evaluated to n, so (n = 1) is true (n = 0) is false
One interesting note: Since assignment operator evaluates to the right operand, the following is valid in Java(albeit not pretty):
if (( x = blah ) > 0) ...
Parenthesis are needed because of operator precedence ( '>' binds stronger than '=').
As others have already said, '=' is assignment; '==' is compare.
in your program change
if(x=0)
to
if(x==0)
"==" checks for equality
"=" Is used for assignment.
It is giving you error cause you're assigning value to x in if(), where you're supposed to check for the equality. Try changing it to equality instead of assignment operator.
As others stated, = assigns while == compares.
However, these statements have their own values as well.
The = operator returns the value of its right-hand operand. This is how statements like a = b = c = 5 work: they are parsed as a = (b = (c = 5)), which evaluates to a = (b = 5) and then a = 5.
The == operator returns a boolean that is true if its operands are equal. The if statement runs its body if its argument is true. Thus, if headers like if (5 == 5) translate to if (true). This is why sometimes you see infinite while loops with header while (true); the while loop runs "while" toe argument is true.
If you had a boolean in your if statement, it would give no error and run the code if the value being assigned (or "compared to") was true. This is why it is so important to never mix up the = and == operators, especially when working with booleans.
Hope this helped!!

Categories

Resources