Left shift operators in c - c

I am learning about left shift operators and for multiplying a number with 10 I am using this code.
long int num=a<<3+a<<1;
so that no. a first multiplies with 8 and then with 2 and on adding gets a*10 which is stored in num.
But its giving some strange result like for 5 its 2560, for 6 its 6144.
Can anyone please explain whats wrong in that implementation?

You have a problem with precedence - the order operators are performed. + binds more tightly than <<, so:
a<<3+a<<1
actually means: a << (a+3) << 1
for 5 that is 5 << 8 << 1 which is 2560 :)
You need: (a<<3) + (a<<1)
See: http://www.swansontec.com/sopc.html for clarification.

The format you are using actually goes this way..
num=a<<(3+a)<<1;
make some difference between the two application of shift operators by using parenthesis like
num=(a<<3)+(a<<1);

What about warning: suggest parentheses around ‘+’ inside ‘<<’

+ is processed before <<.
Use (a<<3)+(a<<1)

<< operator has less precedence than + operator (Thumb rule Unary Arthematic Relational Logical )
so use braces
int num = (a<<3) + (a<<1);

Related

What is true and false and & | used for?

I am very new to c programming and we are studying and/or truth tables. I get the general idea of how to do something like C & 5 would come out to 4, but I am very confused on the purpose of this? What is the end goal with truths and falses? What is the question you are seeking to answer when you evaluate such expressions? I'm sorry if this is dumb question but I feel like it is so stupid that no one has a clear answer for it
You need to understand the difference between & and && , they are very different things.
`&` is a bitwise operation. 0b1111 & 0b1001 = 0b1001
ie perform a logical and on each bit in a value. You give the example
0x0C & 0x05 = 0b00001100 & 0b00000101 = 0b00000100 = 4
&& is a way of combining logical tests, its close the the english word 'and'
if(a==4 && y ==9) xxx();
xxx will only be executed it x is 4 and y is 9
What creates confusion is that logical values in C map to 0 (false) and not 0 (true). So for example try this
int a = 6;
int j = (a == 4);
you will see that j is 0 (because the condition a==4 is false.
So you will see things like this
if(a & 0x01) yyy();
this performs the & operation and looks to see if the result is zero or not. So yyy will be executed if the last bit is one, ie if its odd

perl: precedence of array operations

I'm having some trouble wrapping my head around perl's order of operations. I have the following:
>> my $n = 2;
>> my #arr = (1,2,3,4);
>> print $n/scalar #arr * 100;
0.005
But adding parens:
>> my $n = 2;
>> my #arr = (1,2,3,4);
>> print $n/(scalar #arr) * 100;
50
Looking at the order of operations, it seems as though the first thing that should happen are list operations. In this case, the first one encountered would be scalar #arr, which should return 4. The resulting expression should be print $n/4 * 100, which would follow a standard order of operations and produce 50.
But instead, I assume what is happening is it is performing #arr * 100 first, which produces the scalar value 400, then executed scalar 400, which produces 400, then executes $n/400, giving 0.005.
If the latter is what is happening, then my question is where does scalar fall in the order of operations. If something else is going on, then my question is, well, what?
You can see how Perl parses the code by running it through B::Deparse with -p:
perl -MO=Deparse,-p script.pl
I tried 3 different ways:
print $n/scalar #arr * 100;
print $n/(scalar #arr) * 100;
print $n/#arr * 100;
This was the output:
print(($n / scalar((#arr * 100))));
print((($n / scalar(#arr)) * 100));
print((($n / #arr) * 100));
* is higher than the "named unary operators" (where scalar belongs, check the link) in the precedence table in perlop.
From perlop documentation
In the absence of parentheses, the precedence of list operators such
as print, sort, or chmod is either very high or very low depending on
whether you are looking at the left side or the right side of the
operator. For example, in
#ary = (1, 3, sort 4, 2);
print #ary; # prints 1324
the commas on the right of the sort are evaluated before the sort, but the commas on the left are evaluated after. In other words, list operators tend to gobble up all the arguments that follow them, and then act like a simple TERM with regard to the preceding expression.
And * operator has a higher precedence 7. than named unary operator 10.
so in scalar #arr * 100 * has higher precedence.

Associativity interpretation?

In C we often say that the operators are left-associative and right associative,
A left-associative operator is for example which starts from the left side and ends on the right of the user.
If for example in case of assignment operator x=y; for x=5 and y=20, is like saying put value of y in the x, that seems very legitimate.
but in cases like if(x>y), '>` operator has left associativity.
Means it computes Is x greater than y? FALSE.
But, why we go like this we can also say it reading from right associativity
Is y smaller than x? FALSE
Why use left associativity when the output comes same in both cases?
For a ternary operation as Mat says.
The answer to x>y>z really depends on the direction, the answer will vary from right to left , to left to right. but that is because of different comparisons done at different stage.
Both the answers will evaluate a value, but why do we say that we will chose only the one with left associativity
You are confused about operator precedence and operator associativity.
Operator associativity only applies with operators with the same precedence. For example:
1 - 2 + 3
+ and - have the same precedence, and they are left-associative, which means the above is equivalent to:
(1 - 2) + 3
The associativity concept come in play only when the expression has more than one operator. It is a property of the operator in the expression, not the operands. It define how brackets are inserted, not what the operator means.
operator : Some R
expression : x R y R z
left to right : (x R y) R z
right to left : x R (y R z)
edit:
Reference of operator associativity in C
You're confused between the Associativity and Readability.
Why use left associativity when the output comes same in both cases?
This is true for the readability but not for all the evaluations of expressions.
Consider:
x=10, y=20, z=10
Now, left to right associativity:
x<y<z => (x<y)<z => (10<20)<10 => (1<10) =>TRUE
Now, right to reft associativity:
x<y<z => x<(y<z) => 10<(20<10) => (10<0) =>FALSE
Now, the concept of associativity arrives only when there are multiple existence of same operator.

Are leftshift and OR operators commutative in C?

Example:
Operation 1:
d= c | y | z | a<<3 | b <<3 | x;
Operation 2:
m = c|y|z|x;
d = m | a<<3 | b<<3;
does operation 1 and operation 2 yield same results in C?
To answer the question in your title:
Are leftshift and OR operators commutative in C?
the | bitwise-or operator is commutative, but the << operator is not (a<<3 and 3<<a are quite different).
That doesn't appear to be what you meant to ask, though. To answer the body of your question, since << has higher precedence than | (i.e., << binds more tightly), you can think of a<<3 and b<<3 as if they were primary or parenthesized expressions. In effect, you have multiple subexpressions joined by | operators. Rearranging them should have no effect; your two code snippets should behave identically (except that the second one stores a value in m, which doesn't exist in your first snippet).
This assumes that all the variables you're using are of the same type. If they're not, then storing the intermediate value in m might involve a conversion which could alter the results. This probably doesn't apply in your case, but since you didn't show us any declarations it's impossible to be sure of that.
In this case, it should provide the same results since (a) there are no side effects (e.g. built-in pre- or post-increments or decrements), and (b) the << operator has higher precedence than |.
So, the << operations will occur before the | operations.
It's not a question of commutativity, but a question of precedence between operators. Although it does help that | itself is commutative since your choices do change the order in which expressions are or'ed together.

Logical operator to bit wise?

I'm working on a puzzle right now....trying to write
if (x==5 || x==7)
With bitwise operations (in C). Been working on it for a while....can't figure it out.
Any help would be appreciated! Thanks
Ps this isn't homework...trying to study for a test.
EDIT so the format would be something like
if (x _ _) with a bitwise operation in the blanks
SORRY need to specify, can only be two characters (operator or numeric value)
So %8 for example
7d = 111b and 5d = 101b
So bit 0 must be on, bit 1 is don't care, bit 2 must be on and bits 3-31 must be off.
So, mask out bit 1 and test for 101b
so your test becomes ((x & ~2) == 5)
Then ask Bing or wikipedia about "Karnaugh Maps" so you can do your own expression reduction.
Tom's answer below is also correct and is simpler. You could write
((x & 5) == 5)
and this is slightly faster. Perhaps I should have used a Karnaugh map!
You can AND it with '101' and you get the same results for both 5 and 7, which is 101.

Resources