i would be grateful if somebody could help me with this problem. The book I am currently reading has a question
Q What will be the output?
#include <stdio.h>
void main()
{
int a = 3, b = 2;
a = a ==b==0;
printf("%d, %d",a,b);
}
The answer is given as
1,2 ( even on codeblocks got the same answers)
Now i understand that equality operator has precedence over the assignment operator.
So it must be a== b or b == 0 first
Then as both the above have the same operator, The associativity rule causes
a == b to be evaluated first.
But from here on I am lost!
How does one get to 1 and 2 as the answer?
See https://en.cppreference.com/w/cpp/language/operator_precedence
Note the line that says, "Operators that have the same precedence are bound to their arguments in the direction of their associativity." You can see the associativity for each operator on the far right column.
Note that equality operator is on line 10, with associativity left-to-right.
Note that assignment is line 16, so it has lower precedence than equality.
// original
a = a == b == 0
// precedence rule
a = (a == b == 0)
// associativity rule
a = ((a == b) == 0)
I believe that the equality operator does does not have precedence over the assignment operator. C just works itself from left to right.
in
a = a == b == 0;
a is assigned to everything on the right of the equal sign.
On the right side of the equal sign, a == b is evaluated to false. Then we compare equality of the answer to a==b with 0. In c, 0 is equal to false, so we get true. This is our answer to "everything to the right of the equal sign". So then, we assign that value(true) to a, which is an integer. Because of automatic conversion, true is converted to 1 and assigned to a. Now a equals 1.
As an equation, the above process can be represented as: a = (( a == b ) == 0)
Hope this makes sense. Tell me if I need to clarify further.
Related
Isn't order of execution generally from left to right in Raku?
my #a = my #b = [9 , 3];
say (#a[1] - #a[0]) == (#b[1] R- #b[0]); # False {as expected}
say (#a.pop() - #a.pop()) == (#b.pop() R- #b.pop()); # True {Huh?!?}
This is what I get in Rakudo(tm) v2020.12 and 2021.07.
The first 2 lines make sense, but the third I can not fathom.
It is.
But you should realize that the minus infix operator is just a subroutine under the hood, taking 2 parameters that are evaluated left to right. So when you're saying:
$a - $b
you are in fact calling the infix:<-> sub:
infix:<->($a,$b);
The R meta-operator basically creates a wrap around the infix:<-> sub that reverses the arguments:
my &infix:<R->($a,$b) = &infix:<->.wrap: -> $a, $b { nextwith $b, $a }
So, if you do a:
$a R- $b
you are in fact doing a:
infix:<R->($a,$b)
which is then basically a:
infix:<->($b,$a)
Note that in the call to infix:<R-> in your example, $a become 3, and $b becomes 9 because the order of the arguments is processed left to right. This then calls infix:<->(3,9), producing the -6 value that you would also get without the R.
It may be a little counter-intuitive, but I consider this behaviour as correct. Although the documentation could probably use some additional explanation on this behaviour.
Let me emulate what I assumed was happening in line 3 of my code prefaced with #a is the same as #b is 9, 3 (big number then little number)
(#a.pop() - #a.pop()) == (#b.pop() R- #b.pop())
(3 - 9) == (3 R- 9)
( -6 ) == ( 6 )
False
...That was my expectation. But what raku seems to be doing is
(#a.pop() - #a.pop()) == (#b.pop() R- #b.pop())
#R meta-op swaps 1st `#b.pop()` with 2nd `#b.pop()`
(#a.pop() - #a.pop()) == (#b.pop() - #b.pop())
(3 - 9) == (3 - 9)
( -6 ) == ( -6 )
True
The R in R- swaps functions first, then calls the for values. Since they are the same function, the R in R- has no practical effect.
Side Note: In fuctional programming a 'pure' function will return the same value every time you call it with the same parameters. But pop is not 'pure'. Every call can produce different results. It needs to be used with care.
The R meta op not only reverses the operator, it will also reverse the order in which the operands will be evaluated.
sub term:<a> { say 'a'; '3' }
sub term:<b> { say 'b'; '9' }
say a ~ b;
a
b
ab
Note that a happened first.
If we use R, then b happens first instead.
say a R~ b;
b
a
ba
The problem is that in your code all of the pop calls are getting their data from the same source.
my #data = < a b a b >;
sub term:<l> { my $v = #data.shift; say "l=$v"; return $v }
sub term:<r> { my $v = #data.shift; say "r=$v"; return $v }
say l ~ r;
l=a
r=b
ab
say l R~ r;
r=a
l=b
ab
A way to get around that is to use the reduce meta operator with a list
[-](#a.pop, #a.pop) == [R-](#a.pop, #a.pop)
Or in some other way make sure the pop operations happen in the order you expect.
You could also just use the values directly from the array without using pop.
[-]( #a[0,1] ) == [R-]( #a[2,3] )
Let me emulate what happens by writing the logic one way for #a then manually reversing the operands for #b instead of using R:
my #a = my #b = [9 , 3];
sub apop { #a.pop }
sub bpop { #b.pop }
say apop - apop; # -6
say bpop - bpop; # -6 (operands *manually* reversed)
This not only appeals to my sense of intuition about what's going on, I'm thus far confused why you were confused and why Liz has said "It may be a little counter-intuitive" and you've said it is plain unintuitive!
How can I check if a variable is equal to something, and set to a new variable in the child scope?
For example:
bar = 'foobar'
my_slice = bar[:3]
if my_slice == 'foo':
print(my_slice)
It seems like the new walrus operator here would be useful, but it's not immediately straightforward how you'd go about using it here
Walrus operators work here very well, we just need to understand exactly how they work.
if (my_slice := bar[3:]) == 'foo':
print(my_slice)
Walrus operators set a variable to the output of some expression. It's almost identical to the equal sign in function except it can be used inline.
So this expression:
(my_slice := bar[3:]) == 'foo'
Can be boiled down to (variable = expression) == value
So because the output of my_slice := bar[:3] is equal to bar[:3], the above is equivalent to
bar[3:] == 'foo'
Note: The parenthesis here are required, or else variable is going to equal the output of the comparison operation, i.e. True or False
I am having issues with some Boolean logic.
Essentially I want something to program in VBA a filter such that,
A = True AND (B = True OR B = False)
I just cannot seem to get the coding right to do this in VBA (I am using MS Access).
I have tried:
A = True AND B = True OR B = False
But this obviously fails (looks for either A,B = True OR B = False, essentially).
Am I missing something obvious here?
I chose to left out the actual code, but if requested I can post. My thinking is that I am missing some basic with the Boolean logic.
If A, B, and C are Boolean expressions, then comparing them to a Boolean literal (True, False) is redundant: the expression is already a Boolean expression.
That makes the original logic go like this:
If A And (B Or Not C) Then
The And operator has greater priority than the Or operator, so it gets evaluated first; if the (B Or Not C) part needs to be evaluated as a whole, then the parentheses are required, otherwise A And B takes precedence, making the expression (wrongly) evaluate as:
If (A And B) Or Not C ' redundant parentheses to illustrate operator precedence
Edit: I misread the OP, my brain put that C in there. If A And (B Or Not B) Then is redundant, as BigBen pointed out - the simplified logic would be If A Then. Still worth noting operator precedence and using parentheses when applicable and appropriate though.
I was working on making a game, and I was wondering why the construct with the == operator doesn't work while the lower one does. I used an NSLog message afterwards to test.
if (pipe.position.x == bird.position.x){ no idea why this doesn't work
if ((pipe.position.x <= bird.position.x) & (pipe.position.x > bird.position.x - 1)){
This is because one (or both) of the position.x's are a floating-point2 value with a non-zero difference1 between the two position values such that only the second condition is true.
Since p <= b is true for all values that make p == b true, to see why this works "unexpectedly" let's choose some values such that the expression p == b is false2 yet p < b is true and p > b - 1 is true.
Given p = 3.2 (pipe) and b = 3.7 (bird), as an example, then
p == b
-> 3.2 == 3.7
-> false
but
(p <= b) & (p > b - 1)
-> (3.2 <= 3.7) & (3.2 > 3.7 - 1)
-> (3.2 <= 3.7) & (3.2 > 2.7)
-> true & true
-> true
Instead, to detect when the bird "is crossing" the pipe, assuming that x increases to the right, consider
// The bird's head to the "right" of the pipe leading edge..
bird_x >= pipe_x
// ..but bird's butt is not to the "right" of the pipe trailing edge.
// (Also note use of the &&, the logical-AND operator)
&& (bird_x - bird_width <= pipe_x + pipe_width)
Of course, using a non-rectangle (or forgiving overlap) collision detection would lead to less frustrating flapping!
1 This issue occurs because there are some particular floating-point values (but there are no integer values) which can cause the observed effect.
First, reiterate the assumption that p is not equal to b, given that the first condition does not succeed. Let's suppose then that p <= b is written as p == b || p < b but since p == b is false , we can write it as p < b by tautology.
Since both clauses in the second condition are true (such that true && true -> true), we have the rules: 1) p < b is true, and 2) p > b - 1 is true.
Rewriting p < b as p - b < 0 and p > b - 1 as p - b > -1, and then replacing p - b with x yields: x < 0 and x > -1. However, there is no integer value of x which satisfies -1 < x < 0.
(In first section, where p = 3.2 and b = 3.7, x = (p - b) = 0.5 which satisfies the given constraints when x is not restricted to an integer value.)
2 With all above aside, it is possible for p and b to be "very close but different" floating-point values such that there is a non-zero difference between them - due to rounding, they may even be displayed as the same integer value! See How dangerous is it to compare floating point values? and related questions for the cause and "odd" behavior of such when using ==.
If this is the case then round to integer values and use an integer comparison, or; rely entirely on relational comparison such as shown in the proposed condition, or; use epsilon comparison for "nearly equal" of floating-point values.
if you choose abs(pipe.position.x) == abs(bird.position.x) the first condition may satisfy.
I'm trying the following condition, the compiler give no warning but the code does not seems to work. Should This work?
if (self.finishLine > hero.position.y > self.startHeight)
{
hero.position = CGPointMake( hero.position.x + translation.x, hero.position.y);
}
Comparison operators return boolean values.
(self.finishLine > hero.position.y > self.startHeight)
-> ((self.finishLine > hero.position.y) > self.startHeight)
-> ((<0 or 1> > self.startHeight)
I doubt that self.startHeight is ever less than 1, let alone less than 0.
The correct form in C is:
((self.finishLine > hero.position.y) && (hero.position.y > self.startHeight))
I have not tried it but I believe it is a valid expression. AFAIK Objective C does not support sandwiches..
(a > b > c) should evaluate to TRUE or FALSE respectively YES or NO. But how? The compiler would start from left to right here as all operators are equal. (a > b) will evaluate to YES or NO. Those are internally represented by 1 and 0. 1 and 0 may be larger than c or not.
I wonder if the compiler throws a warning at least.
Did you go for it and tried it?