Binary and hexadecimal

Open any file with a tool that shows its raw bytes, and you get a wall of little pairs like 4A, F3 and 9C. Underneath, the machine holds nothing but ones and zeros. People move between those two views all day, and it takes no dividing and no subtracting, just a pair of scissors.

This is video five of nine in Binary and number bases. If today feels shaky, C S oh one, oh two, Denary to binary and back, covers the step just before this one.

The whole method rests on one fact about size, so let me show you why that fact holds. Four bits give you sixteen different patterns, from all four switched off to all four switched on, and not one pattern more. Hexadecimal has exactly sixteen digits, zero to nine and then A to F. Sixteen patterns, sixteen digits, so every four-bit block has a digit waiting for it and nothing is left over. That is the line from the video on why hexadecimal exists, C S oh one, oh three: one digit, four bits; two digits, one byte. There is a second reason the two systems lock together. In a byte, the left half is worth sixteen times the right half. In hexadecimal, the left digit is worth sixteen times the right digit as well. Both systems climb in steps of the same size, which is why you can read one straight off the other. Try one now. On screen is a four-bit block reading one, zero, one, one, with the place-value header you already use sitting under it. Across four bits that header reads eight, four, two, one. Is the block the hexadecimal digit A, B, or D? Take your pick, and hold on to your reason. I'll wait. It is B. Eight, plus two, plus one, makes eleven, and eleven is written B, since A is ten, B is eleven, C is twelve. Pick D and you have counted the four, and the four is switched off. Pick A and you have dropped the one at the very end. Sixteen patterns and sixteen digits, matched one to one, and everything else in this video is only about cutting in the right place.

Let me cut a real byte in half and show you what falls out. Here is the byte from that file: one zero one one, one one zero zero. Put the scissors in from the right-hand end, count off four, and you have two four-bit blocks with a gap between them. Some people call a four-bit block a nibble. The left block is one zero one one, which you just marked as B. What matters is that you read it on its own, as its own little four-bit number, eight, four, two, one, and not as its place inside the whole byte. The right block is one one zero zero. Eight and four make twelve, and twelve is written C. So the byte is B C. B for the left half, C for the right half, and the two halves never had to talk to each other. The value has not changed at all. You have written the same number in two characters instead of eight. No dividing, no subtracting, and no going through ordinary numbers on the way, and that is not a shortcut around the method. That is the method.

Not every pattern turns up in a tidy eight bits, and that is where this one goes wrong. Take a six-bit pattern: one zero one one zero one. Group it into fours from the left and you get one zero one one, then a stray zero one hanging off the end, and you have quietly changed what the pattern is worth. Group it from the right instead, pad the front, and convert both blocks on their own. I want the two hexadecimal digits. Have a think. I'll wait. From the right you take one one zero one, which leaves one zero sitting on its own. Pad the front with two zeros to make zero zero one zero, and that is two. One one zero one is eight and four and one, which is thirteen, and thirteen is D. The answer is two D. Padding the front costs you nothing, because the front is the big end and a zero there adds nothing to the value. The right-hand end is the ones end, so the right-hand end is what you have to keep still. Here is your line for this video: always four, and start from the right. Four bits to a digit, every single time, and when you are cutting a pattern up, you start at the right-hand end. Group from the left and you get a wrong answer out of perfectly good arithmetic, which is the worst kind of wrong.

Run the scissors backwards now, because coming from hexadecimal you are not cutting anything, you are expanding it. Convert F three into binary. Take the digits one at a time and never as a pair. F is fifteen, which is eight and four and two and one, so all four bits are on: one one one one. Three is the one that gets dropped. Three is two and one, so it comes out as zero zero one one, and those two zeros at the front are not optional. Write just one one and you have handed in a two-bit digit, and there is no such thing. Join them in order and you have one one one one, zero zero one one. Eight bits, one byte, two hexadecimal digits, and the value is exactly what F three was worth all along. Your turn, and this one marks itself. Take B C from earlier in this video, expand each digit into four bits, and see whether you land back on the byte we cut up. Try it on paper before I show you. I'll wait. B is eleven, so eight, two and one are on, giving one zero one one. C is twelve, so eight and four, giving one one zero zero. Side by side, you are back at the byte we cut up, so the two directions really are one rule, read forwards and backwards. Convert each digit on its own, then join them. Doing the whole thing in one sweep is where the errors hide.

One wrong digit in the middle of a conversion does not stay where you put it. O C R set a question giving candidates the hexadecimal number two F, to be converted into an ordinary number with the working shown. The most common method candidates used was turning each digit into four-bit binary first, which is exactly the move in this video. Here is the line from the examiner report. Some candidates did not accurately convert F to binary, for example giving one one zero one instead of one one one one, which then left the final conversion incorrect. Watch what that does on screen. The method was right and the other digit was right, and one block read wrong at the start took the whole answer down with it. Nothing later in the working can rescue it. So build the check in. Convert one digit, look at that digit on its own, then move to the next. F is worth knowing cold, because F is all four bits on, and F is the digit that catches people. For the ordinary-number route, that is the video on denary and hexadecimal, C S oh one, oh four. This is a precision topic rather than a clever one. The digits are small and the method is short, so the care you take over each digit is the whole job.

Always four, and start from the right. That is the video in one line, and here is the rest of it in order. Going into hexadecimal, cut the pattern into fours from the right, pad the front if you come up short, and convert each block on its own using eight, four, two, one. Coming out of hexadecimal, expand each digit into exactly four bits, keep any zeros sitting at the front of that digit, and join the blocks in order. And it works because sixteen patterns meet sixteen digits, one for one, with nothing left over. This is not a shortcut you are getting away with. It is the correct method, and it happens to be the quick one.

The thumbs coming up on screen are for you rather than for me. Put one on every video in this chapter you have properly nailed, so when you come back to revise you can go straight past those and spend the time on the ones with no thumb. If this one has not landed yet, leave it un-thumbed and save the video, or save the whole chapter, then come back in a few days. Conversions like this often click on a second run.

Next in the chapter: Binary addition, where those same eight bits start getting added together and carrying.

For more, visit scholafly.com, or watch the next video.