Understanding Binary and Hexadecimal

Binary and Hexadecimal are both number systems that get used a lot in the programming world. Unfortunately they are difficult to understand at first.

There are many number systems in the world, they can all be classified by this format: base-<Number>. How do you find out that number? Well, count how many numbers/characters you have to go up to increase by a character. The universal number system is base-ten, you have to go 10* numbers up from 0 to get to 10 (0-9).

Binary

Binary is base-two. Binary only contains 2 numbers because of it's base number, 1 and 0. This makes binary numbers rather large and confusing. The best way to explain this is to show how to count in binary.

You start off with 0 and add one, this increases the 0 to 1 (Just like in base-ten). Now if you add another one you go to 10 because you have reached the base number. Then just continue that pattern on up.

Help Table

1. 1
2. 10
3. 11
4. 100
5. 101
6. 110
7. 111
8. 1000
9. 1001
10. 1010
11. 1011
12. 1100
13. 1101
14. 1111

A good trick for this is take the base number, subtract one. Now when you reach that number set the current number to 0 and carry a 1 to the left.

When working with binary it is very useful to be able to convert back and forth quickly. To do that start with the left most 1, and move to the right performing an action for each number. For a 1: double the number in your mind and add one. For a 0: just double your number. If you do this you should be able to convert any size binary number fairly quickly. The size of the number you can convert of course depends on your memory and multiplication skills.

Now to convert a base-ten number to binary. This is a little more complicated and requires memorization of some (easy) numbers. You will have to remember the powers of two, which you should already know from minecraft. They are 1, 2, 4, 8, 32, 64, 128, 256, 512, 1024, 2048, etc. Now to the method! Find the largest power of two that will fit in your number, write it down and subtract it from you number. Now take the new number and check the next smallest power of two, write 0 to the right of your sequence if it is too big, or 1 if it fits. If you write one then also subtract that power from your number. Repeat this process until you get to the 1 place.

Binary has two formats, little-endian and big-endian. This basically tells you which direction the number is written. Endian means the right most number. So you write your number with the ones place on the right, then its little endian. If your ones place is on the left, then its big endian. Which endian you use if entirely up to you, although most binary numbers are written out in little endian as far as I know.

Bomb Bloke, on 20 March 2015 - 04:58 AM said:

0b100 represents 4. I'm not aware of any system under which you'd try to represent 4 as 0b001. That doesn't mean there isn't one, but it does mean that every time you see 0b100, you can assume it means 4. Likewise, you would assume 48 means forty-eight, unless someone went out of their way to state otherwise - higher digits are always to the left by default.

Little/big-endian representation has to do with the order of bytes, not bits. Let's say you've got the number 1000, and you want to represent it in binary - you'd use 0b1111101000.

However, 0b1111101000 is more than eight bits, and you can only assign eight bits to the byte. So you need multiple bytes to hold it - one will get 0b00000011, and the other will get 0b11101000. In memory, which byte comes first? Under a little-endian system, it's the byte representing the "smallest" part of the number (0b11101000), under a big-endian system it's the byte representing the "largest" part of the number (0b00000011). However, the order of the bits within those bytes remains the same either way.

Hexadecimal
Coming Soon….

*Actually 9 starting off from 0, but you get my point.

Please post some constructive criticism, I am a horrible writer but wanted to help out the beginners.

Looks good, I'm sure someone will find this very useful.

one correction:

A good trick for this is take the base number, subtract one. Now when you reach that number set the current number to 0 and carry the base sub 1 number to the left.

so in base ten we do this?

...
8
9
90
91
92
...

you probably mean

A good trick for this is take the base number, subtract one. Now when you reach that number set the current number to 0 and set the number to the left as it's current value +1.

Lupus590, on 18 March 2015 - 09:14 PM said:

Looks good, I'm sure someone will find this very useful.

one correction:

A good trick for this is take the base number, subtract one. Now when you reach that number set the current number to 0 and carry the base sub 1 number to the left.

so in base ten we do this?

...
8
9
90
91
92
...

you probably mean

A good trick for this is take the base number, subtract one. Now when you reach that number set the current number to 0 and set the number to the left as it's current value +1.

Good point, Ill fix that. I knew it sounded weird when I wrote it.

A nice way to explain binary is by showing the relation to the two counting systems of base two and base 10.

In base 10, you have the numbers 0,1,2,3,4,5,6,7,8,9 to build your numbers, you start at 0, and increment up.

0
1
2
3
4
5
6
7
8
9
10
11

When you reach the end of your set of numbers, you then increment the number to the left of the currently used one, and reset the current one to the starting number, in this case 0.

Base two works in exactly the same way, except you only have two numbers to use, 0 and 1.

0
1
#Oh no, we're at our final number, let's increment the number to the left.
10
11
#Oh, it happened again. (Technically we're at the equivalent of 99 in base 10)
100
101
110
111 #(999)
etc...

If you noticed, when we hit the first one, we added a number to the left, and continued on until we hit a 1 again.


Also, binary does work in powers of two, which means that starting from your 'ones' place, each value of the space to the left is worth double the last one, 100 is 4, because the one's place is worth one, the one to the left is worth two, and the one that has a 1 in it is worth four. Continuing on that pattern, the next would be worth 8 if it had a 1 in it, 16 after that, 32, 64, etc…


(Also, you can count binary on your hands and get to a much higher number than 10. if memory serves with ten fingers you can get to about 1023.)

Dragon53535, on 19 March 2015 - 05:24 AM said:

A nice way to explain binary is by showing the relation to the two counting systems of base two and base 10.

In base 10, you have the numbers 0,1,2,3,4,5,6,7,8,9 to build your numbers, you start at 0, and increment up.

0
1
2
3
4
5
6
7
8
9
10
11

When you reach the end of your set of numbers, you then increment the number to the left of the currently used one, and reset the current one to the starting number, in this case 0.

Base two works in exactly the same way, except you only have two numbers to use, 0 and 1.

0
1
#Oh no, we're at our final number, let's increment the number to the left.
10
11
#Oh, it happened again. (Technically we're at the equivalent of 99 in base 10)
100
101
110
111 #(999)
etc...

If you noticed, when we hit the first one, we added a number to the left, and continued on until we hit a 1 again.


Also, binary does work in powers of two, which means that starting from your 'ones' place, each value of the space to the left is worth double the last one, 100 is 4, because the one's place is worth one, the one to the left is worth two, and the one that has a 1 in it is worth four. Continuing on that pattern, the next would be worth 8 if it had a 1 in it, 16 after that, 32, 64, etc…


(Also, you can count binary on your hands and get to a much higher number than 10. if memory serves with ten fingers you can get to about 1023.)

I thought I pointed most that out (counting wise) in my tutorial? And the doubling thing just get confusing to beginners imo

your binary is backwards. because you have to treat is as a decimal, if a pc saw 100 then it could say "1" or "4", so, if you really want it to be 4, then you can say 001. it is a VERY common mistake to use binary backwards, and you rly should'nt be teaching people that way, if this is their first time hearing of binary.

slow-coder, on 19 March 2015 - 10:18 PM said:

your binary is backwards. because you have to treat is as a decimal, if a pc saw 100 then it could say "1" or "4", so, if you really want it to be 4, then you can say 001. it is a VERY common mistake to use binary backwards, and you rly should'nt be teaching people that way, if this is their first time hearing of binary.

Why don't you read it all?

AssossaGPB, on 18 March 2015 - 06:17 PM said:

-snip-

Binary has two formats, little-endian and big-endian. This basically tells you which direction the number is written. Endian means the right most number. So you write your number with the ones place on the right, then its little endian. If your ones place is on the left, then its big endian. Which endian you use if entirely up to you, although most binary numbers are written out in little endian as far as I know.

-snip-

And really little and big endian is just opinion. Binary makes the most sense to me in little endian, because that's how decimals work. And once you learn one its prty easy to learn the other.

What slow-coder is saying is incorrect, and what AssossaGPB is saying about little/big-endian systems is also incorrect - but for somewhat different reasons.

0b100 represents 4. I'm not aware of any system under which you'd try to represent 4 as 0b001. That doesn't mean there isn't one, but it does mean that every time you see 0b100, you can assume it means 4. Likewise, you would assume 48 means forty-eight, unless someone went out of their way to state otherwise - higher digits are always to the left by default.

Little/big-endian representation has to do with the order of bytes, not bits. Let's say you've got the number 1000, and you want to represent it in binary - you'd use 0b1111101000.

However, 0b1111101000 is more than eight bits, and you can only assign eight bits to the byte. So you need multiple bytes to hold it - one will get 0b00000011, and the other will get 0b11101000. In memory, which byte comes first? Under a little-endian system, it's the byte representing the "smallest" part of the number (0b11101000), under a big-endian system it's the byte representing the "largest" part of the number (0b00000011). However, the order of the bits within those bytes remains the same either way.

Bomb Bloke, on 20 March 2015 - 04:58 AM said:

What slow-coder is saying is incorrect, and what AssossaGPB is saying about little/big-endian systems is also incorrect - but for somewhat different reasons.

0b100 represents 4. I'm not aware of any system under which you'd try to represent 4 as 0b001. That doesn't mean there isn't one, but it does mean that every time you see 0b100, you can assume it means 4. Likewise, you would assume 48 means forty-eight, unless someone went out of their way to state otherwise - higher digits are always to the left by default.

Little/big-endian representation has to do with the order of bytes, not bits. Let's say you've got the number 1000, and you want to represent it in binary - you'd use 0b1111101000.

However, 0b1111101000 is more than eight bits, and you can only assign eight bits to the byte. So you need multiple bytes to hold it - one will get 0b00000011, and the other will get 0b11101000. In memory, which byte comes first? Under a little-endian system, it's the byte representing the "smallest" part of the number (0b11101000), under a big-endian system it's the byte representing the "largest" part of the number (0b00000011). However, the order of the bits within those bytes remains the same either way.

Oh, that makes sense. Let me add your explanation to the tutorial because I don't feel like rewriting that :P/>

nice tutorial, though a bit confusing xD
still a great idea.

8|4|2|1
——–
1|0|1|0 == (8*1)+(4*0)+(2*1)+(1*0) == 8+2 == 10

Increase always to the left (*2)

16|8|4|2|1–>32|16|8|4|2|1