A bit confusing

This is all about bit operations, I will try to explain it to you.

A byte is 8 bits, a bit is either a 1 or a 0. This is the basic units that computers use.

So since a byte is made up of 8 bits, a byte would like like this, 00001000. That is a binary representation of the decimal 8. But wait how do I know that is an 8 in binary? Well glad you asked. :)

Binary ------ Decimal --- 2^x (2 to some power)
00000001 --- 1 --------- 0
00000010 --- 2 --------- 1
00000100 --- 4 --------- 2
00001000 --- 8 --------- 3
00010000 --- 16 -------- 4
00100000 --- 32 -------- 5
01000000 --- 64 -------- 6
10000000 --- 128 ------- 7

Ok, so now you know how to get those numbers. But wait about numbers in between those? So say you want to know how to write 27 in binary. So first look at the chart and see that it is less then 32. So 16 is the first number we can subtract from it, so we have (00010000) or 16, 27-16 = 11, so now we can subtract 8 (00001000), 11-8 = 3. So we can not subtract 4 so on to 2 (00000010) 3-2 = 1, so subtract 1 (00000001) 1-1 = 0, so we are done. Ok, now we have all the parts that make up 27. Now we just add them together (In binary speak we do an OR)

00010000 --- 16
00001000 --- 8
00000010 --- 2
00000001 --- 1
-------------------
00011011 --- 27

So now you can turn decimals into binary and if you just reverse the process can turn binary into decimals.

So how does all of this relate to bit shift operators?

Lets do a bit shift on 1 and see what we get.
1 = 00000001 So we do a left sift <<, and we get 00000010 which is equal to 2. Now if we do this 1 << 5 what do we get? Well we have 1 - 00000001 and we shift is 5 places to the left, so we get 00100000, which is 64 in decimal. The right shift just moves the bits to the right.

Wow that turned into a lot of typing.

Hope that helps.
theTroll

Thankyou so much TheTroll you are an angel. That was a great explanation.

I suppose the next question from this is; is there any example(s) you can think of where you would want to do this?

In the past, shifting had the potential to be faster for integer multiplication and division by a power of two. This is rarely true nowadays, especially for non-embedded systems, and even then there are usually coarser optimizations to be had before you must start replacing all your easy-to-read arithmetic operators with somewhat obscure "bitsex."

In modern times, bitshifting is primarily valuable in the context of other bitwise operations, such as determining the number of bits set in a particular number (occasionally useful for flag bitfields) or packing smaller integers (such as bytes) into the storage space of a larger one (such as ints) -- this is often done to turn a four-component floating-point color tuple (R,G,B,A) into a single 32-bit integer for use on a graphics card, for example.

Some people also like to use bitshifting in the definition of flag bitfield constants, using the sequence of statements { 0, 1 << 0, 1 << 2, 1 << 3 } instead of the equivalent sequence { 0, 1, 2, 4, ... } because the latter is often easier to read and modify, especially when you get into larger numbers.

Years ago, memory and hard drives were a lot smaller, and internet speeds were nothing compared to what they are now. So you wanted your application to have a very small "memory footprint". So you would do bit packing to reduce the memory requirements and also to bitmasking to store a bunch of bool values (flags) in an int, short or character.

With current techniques all of this is pretty much a thing of the past.
theTroll

So would learning this be a bit like learning stick shift driving as well as automatic, even though (in the States at least, I believe) most likely you will spend your time driving an automatic?

Nope, you have to go back further. It would like learning to drive a horse and buggy, even though not too many people drive them nowadays. :)

A horse & buggy? Fancy modern American luxuries! In the UK the only person with transport is the queen. She straps 2 of her pet corgis to each foot & holds a sausage on a fishing rod in front of her to get the little beggars moving.

Quote:

Lets do a bit shift on 1 and see what we get. 1 = 00000001 So we do a left sift <<, and we get 00000010 which is equal to 2. Now if we do this 1 << 5 what do we get? Well we have 1 - 00000001 and we shift is 5 places to the left, so we get 00100000, which is 64 in decimal. The right shift just moves the bits to the right.

So for the right shift >> . If I have 1 = 00000001 and I do a right shift (exp: 1>>2). Where is the bit "1" supposed to move? There is no spaces to the right ...

Quote:

Original post by kosodo Quote: Lets do a bit shift on 1 and see what we get. 1 = 00000001 So we do a left sift <<, and we get 00000010 which is equal to 2. Now if we do this 1 << 5 what do we get? Well we have 1 - 00000001 and we shift is 5 places to the left, so we get 00100000, which is 64 in decimal. The right shift just moves the bits to the right. So for the right shift >> . If I have 1 = 00000001 and I do a right shift (exp: 1>>2). Where is the bit "1" supposed to move? There is no spaces to the right ...

It falls off the edge. 1 >> 1 == 0.

int x = ???;x >> 32 == 0x << 32 == 0