Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Learn more about Collectives

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Learn more about Teams c is 1(true) if (a+b) is *much greater" than 1 :-) mathworld.wolfram.com/MuchGreater.html – Arun Sep 23, 2010 at 23:24

It returns the average of a and b , rounded down. So, if a is 5 and b is 8, then the result is 6.

ETA: This method is busted if a and b add up to a negative number, like if both are negative, or if integer overflow occurs.

The >> 1 is a particularly hack-y way of dividing by 2, because it bit-shifts to the right by 1. – Ross Light Sep 23, 2010 at 16:28 @Quartz: Some people do it as a micro-optimisation because they think the compiler can't handle /2 properly. I, of course, disagree. – C. K. Young Sep 23, 2010 at 16:30 Not correct in general case. Since a + b can be negative, the behavior of >> is implementation-defined. – AnT stands with Russia Sep 23, 2010 at 16:31 I always disagree with the optimization with some tricky code. 20% of your code will use almost 80% performance of your systems. It must be the place to be optimized, not these things :) – coolkid Sep 23, 2010 at 16:39

Note, that there can't be any meaningful explanation of what your code means until you explain what a and b are.

Even if a and b are of built-in type, beware of the incorrect answers unconditionally claiming that built-in right shift is equivalent to division by 2. The equivalence only holds for non-negative values. The behavior of the >> operator for negative values is implementation-defined.

In other words, without extra information, the only thing that can be said is that the code calculates the "sum" a + b and "shifts" it right by 1 bit. I used quotes in the last sentence because in case of overloaded operators + and >> there's no way to predict what they are doing.

Agree, though, my answer was trying to address the intent of the code, rather than what it actually does. – C. K. Young Sep 23, 2010 at 16:39 In more detail, a twos-complement negative number starts with 1 (negative numbers are 2^n-x, where n is the number of bits used to store a number and x is the absolute value of the number). A strict bit-shift of that number to the left will replace this 1 with a zero; in decimal math the transformation would follow abs(x)/2+2^(n-1) – KeithS Sep 23, 2010 at 16:44 @KeithS: Right, and that's what AndreyT's point is: it's implementation-defined. On x86, there are two instructions, SHR and SAR . SHR does what you say: shifts in 0. SAR shifts in the top bit. So, since compilers are free to choose which instruction to use, you can get varied results. – C. K. Young Sep 23, 2010 at 23:35

That depends on the type of c, a and b. If it's int then the above statement is the same as:

c = (a+b)/2;
>> means shift right one bit.
                If a or b is floating-point, then >> doesn't work and the program won't compile anyway. So, we'll safely assume they're both integral.
– C. K. Young
                Sep 23, 2010 at 16:34
It means to add A to B, then bit-shift the result by one bit to the right. Bit-shifting a positive integer generally has the effect of multiplying or dividing by 2^n where n is the number of bits being shifted. So, this is roughly equivalent to (a+b)/2 in integer math (which has no remainders or fractional parts).
It means that you add a and b, then shift the result one bit to the right.
It's the same as:
int c = (a + b) / 2;
        
Thanks for contributing an answer to Stack Overflow!
Please be sure to answer the question. Provide details and share your research!
But avoid …
Asking for help, clarification, or responding to other answers.
Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.