Assuming integer division, for x=3 and y=5 that would give 3, whereas the midpoint is 4.

Because the division is truncated twice, which increases the error. Take x=y=1, or x=y=3 for example.

x/2 + y/2 + (x & y & 1) should work.

That doesn't work when both are odd. For example, for x=1 and y=3 this gives 1 instead of 2.

1/2 + 3/2 + 1 = 0 + 1 + 1 = 2

Your final +1 is not in the expression by OP. You can get it by taking the correction term (x & y & 1) as mentioned in another comment.

woops, misread the indent-depth of the posts as reply, not to the same parent.

Division by 2 is one of the quickest operation. The correct implies 3 additions instead of one, so you go a point.

But y>>1 + x>>1 + (x & y & 1) is easier to remember than ((x^y)>>1) + (x&y).

Dividing by two is just a right shift.

Only if you are dealing with unsigned integers.

For signed integers, you need to be careful depending on the language you are using. Most languages provide a signed right shift that doesn’t lose the sign.

Personally, I think shift should always have been a bitwise operator, without sign extension. To me signed right shift feels as sensible as right shifting a floating point number - a shift is bitwise and not an arithmetical operator. But I guess that’s what comes from being brought up on healthy machine code by robots in the steel jungle.

C recommendation: “INT13-C. Use bitwise operators only on unsigned operands” https://wiki.sei.cmu.edu/confluence/plugins/servlet/mobile?c...

X+y can overflow which is what the post is saying.