I've taken quite a few intro programming classes in my day, mostly just to get my feet wet in every different kind of programming I find. Not surprisingly, just about every class runs through the same format : intro to hardware, intro to software, and then you get into the actual programming. While understanding how the hardware and software works is very important, I've always been confused by one topic that has been in every single course.

In the intro to software section I've found, without fail, they always put large emphasis on being literate in binary, hexadecimal, and sometimes even octal number systems. I understand that it's good to understand what these things are, and how a computer would interpret them, but I've never found myself actually needing to know how to read and write any of those number systems. Really, the only time I've seen something other than base 10 is for colors in CSS, which is even easier if you use something like www.colorpicker.com

Have I just been ignorant of the wonderful uses of these non-base-10 number systems in the programming world, or is just an old tradition to include these sections in all programming textbooks? Does anyone have a good example of where the average programmer would actually use an octal number?

• Does anyone have a good example of where the average programmer would actually use an octal number? Yes, if you ever find yourself writing software related to the Aviation industry then you will likely encounter Transponder codes, which are a 4-digit octal number. en.wikipedia.org/wiki/Transponder_%28aviation%29 Sep 2 '12 at 20:18

All the answers are good but they don't address what I think is the most valuable part. Learning to "Think" in different bases makes you much more fluent with the way computers handle numbers.

If you wanted to store a string of lower case letters packed fairly well, how would ou do it?

Well, there are 26 lower case letters, that translates easily into a range of 0-31 which is a 5-bit number, you can pack 6 5-bit numbers into a 32 bit field (int?) and even have enough left over for a few punctuation marks.

I'm not saying hex helps with stuff like this, but understanding how numbers convert does.

Another case, every so often you use base-64 for passing somewhat long numbers in ascii. Would you know how to implement this? Why implement it that way? Did you even realize that's what you were typing in every time you typed the "CD KEY" into a game's registration box?

Also, for fun, play around with base 12 for a while sometime. Math turns out to be really interesting in base 12 (base 10 is stupid in comparison, I wish we'd evolved with 6 fingers--we could be decades ahead in our comprehension of math). Some very smart early humans used base 12 to develop the clock.

In base 10 we have 3 "Cool" numbers that create easy patterns, 2, 5 and 9 with 8, 6 and 4 as "Minor" cool numbers. In base 12 you have 2,3,4,6,11 as "Cool" numbers with 8,9 and 10 as "Minor" cool numbers, meaning that if we used base 12 we'd be much better at recognizing patterns in numbers because we'd be seeing them all the time.

Also, binary. You can count on one hand to 32--I do it quite a bit, comes in handy sometimes when counting to 5 just doesn't cut it :)

Binary is lots of fun, but it just doesn't translate well. When you get good with hex, you start to see "A" as 1010 and "5" as 0101, and these things start to really matter. If you have a bitfield that you want to extract the 6th bit:00100000, what do you "and" it with? You should just know that it's 0x20.

If you see code that ands something with 0x0600 which bits are being extracted? You should know without even thinking about it--you should actually read that as though it were written 0000011000000000 (but easier to read because you don't have to count zeros).

Why would you want to limit your brain and its ability to process data?

• Actually, clocks were developed in base60. Jun 15 '11 at 17:59
• @Denis I was under the impression that the current theory was that they were developed by a people who counted in base twelve that lost out to dumber people who couldn't think passed their fingers. 60 is just the 12 divisions further divided up into groups of 5 and seems like an after-hack by the base 10 grunts :) Jun 15 '11 at 21:04
• Might be. To be honest, I'm by no means a specialist. Your comment merely brought back some long-forgotten memory. I also recall that angles measured in 360 degrees comes from base-60 (and by the same babylonian inventors, at that), but as you point out it may be that base-10 grunts merely overwhelmed what originally was base-12 mathematicians. :-) Now, imagine if we were counting in base-20, like some american indians did. :-D Jun 15 '11 at 21:11

What's to learn? You need to understand different number bases to be a competent programmer, but regarding hex there is little to learn, except that ABCDEF come after 9.

• OP may be referring to being able to mentally transpose to base 10 from other bases. This may have been a useful skill at one point, and may still be for a certain category of low-level programmers, but is largely irrelevant today. You can do the conversion in vim trivially, for instance. Jun 8 '11 at 17:13
• That's correct. I should have been more clear. Jun 8 '11 at 17:18
• @Rein I've never been very good at doing that (I have to do the math in my head), so I can't say. However I used to be mentally able to transpose from hex into Z80 assembly language, which was a useful thing to be able to do at the time. I suspect the ability to transpose from hex to 80x86 assembler (or whatever) is still useful for programmers working today. Jun 8 '11 at 17:18
• @Neil Butterworth: 8080 opcodes make more sense viewed in octal, really, if memory serves. My memory's real hazy about how that applied to the Z80 extensions to it. Jun 8 '11 at 20:12
• @Neil: I think the significant part was the move register-to-register instructions, which appear to be 01xxxyyy in bit format, where xxx is destination and yyy source. I don't know if there's any other octal significance. Jun 8 '11 at 21:09

Does anyone have a good example of where the average programmer would actually use an octal number?

Octal? Not generally, no, with an exception for *nix permissions.

Hexadecimal? You bet. You're ignoring the rather large number of us who are shuffling bits around embedded systems, looking at protocols or file formats on a bit level, et cetera. But sure, if you're far off the metal doing application or web work, you might get away with it easier.

Example: Configuration registers on microcontrollers and the like.

Take the number 54312, taken by randomly punching keys. Can you tell which bits are set? I can't, at least not off the top of my head. The hexadecimal equivalent then, that's 0xd428. That on the other hand, tells me right away that the bit pattern I'm looking at is 1101 0100 0010 1000. It's more logically structured for that sort of thing, and you find yourself needing this all the time when you're close to the metal. Let's say the above number is what I get on reset from the mcu, and that I need bits 7 and 9 set for some reason. In hex, I can easily see that the resulting number should be 0xd6a8, but in decimal? That's 54952, nowhere near as intuitive if you ask me. Sure, it's a matter of adding 640 to the value, but it's more of a pain to figure out. Of course, in practice, one might simply shift in bits to the correct position and OR that with the original value, but you still might want to know what the final representation is.

• Which kind of prompts the question "why should I care which bits are set?" For some (many? most?) applications this isn't relevant. Jun 8 '11 at 18:45
• Agreed--assuming we're talking high level development. Low level, whether a particular bit is set or cleared not just might, but will sometimes determine if the bloody micro boots at all, or if a certain peripheral you need gets power, or if it runs at a clock speed of x rather than y. That's just the start of it, and if you deal with this sort of development, basically, single bits matter. Sometimes a lot. But again, it depends on your domain, I'm just saying; Don't forget the embedded world. =)
– n42
Jun 8 '11 at 19:00
• +1 - the closer to the machine you get the more you need to use different bases. It's not just embedded; most languages have bit flags and they are often written in hex for obvious reasons. Conversely it is fairly pointless to teach in a first programming course, but then most first programming courses are fairly pointless. Almost all programmers teach themselves right?
– user23157
Jun 8 '11 at 21:14
• @Davor: It's because hex is easier to read. I can make sense of an 8 digit hex value a lot faster than a 32 digit binary value. Jun 8 '11 at 21:57
• @Steve S: Honestly, I suspect it's because we're a lazy bunch, as well.. 0x80 is shorter to write than 0b10000000. But I agree. I'd also agree that it's largely meaningless in a first programming course, but you might shove it into discrete maths, realtime programming, computer organisation, and the like.
– n42
Jun 9 '11 at 4:46

Does anyone have a good example of where the average programmer would actually use an octal number?

If you're setting permissions on a file in Unix (or Linux), you use a 3-digit octal number. The first digit is the user's permissions, the second is the group's permissions, and the last digit is the permissions that everyone else gets.

I had to understand this fact in code that I wrote last week.

If you look at the output of standard hashing algorithms like MD5, you'll often find them written out in hex. I've seen a number of cases where this lead to arithmetic in unusual bases.

If you want to understand how floating point is internally represented, and therefore why 1/10 is not represented precisely, you absolutely need to understand how to do arithmetic in different bases. This is esoteric knowledge until the day when it bits you in the rear and suddenly you actually need to understand it in a hurry.

And there are a ton of other cases where you'll find the fundamental binary nature of data inside of computers cropping up. Of course if you're just writing a CRUD website, you'll likely never encounter any of them because it happens at levels that someone else has already dealt with.

• *nix permissions aren't true octal. You don't perform mathematical calculations with these representations. At best they are octal representations of a binary mask. Jun 8 '11 at 17:26
• @Joel Etherton: When you get the permissions from a file stat, they come in as numbers which by default will display in base 10. If you don't understand converting to/from octal, those numbers are hard to understand. I was writing documentation that needed to explain this fact. There were plenty of mathematical calculations. Jun 8 '11 at 17:40
• @btilly: You misunderstand what I'm saying. If you set permissions on a file to 755 you will not have to add this to anything. It's just a mask that describes the permission combinations. Sure you have to recognize that it means (4+2+1)(4+0+1)(4+0+1), but these are still just representations of the binary mask. What are you referring to when you say "file stat"? I've never seen a file stat for permissions delivered in base 10 (sticking strictly to that example). Jun 8 '11 at 17:46
• @Joel Etherton: Try `perl -le '@stat = stat(shift); print \$stat[2]' some_file` and you'll get a stat as a number in base 10. You need to pass it into Perl's `chmod` in the same way. Therefore it makes sense to store the number that way in a database, at which point I need to document what those numbers have to do with more familiar Unix permissions. As I said, this was not a hypothetical example. Jun 8 '11 at 18:20
• @Joel Etherton: say you have a file whose permissions are 419 (decimal), you want to make the file user-executable, but not world-readable. How do you need to modify the number? The value returned in the C stat() call is an int, how you choose to print is, well, another matter. Jun 9 '11 at 16:44

Hopefully, in the real world, you won't be quizzed on converting Hex to binary to decimal. You will have tools at your disposal to convert any which way you desire.

I agree you should have an understanding of what is going on, but why memorize when you can look it up?

However, I have found it useful to remember key numbers (for me 0x64 = 100, 0xFF = 255, 0xFFFF = 65535, etc) because they come up a lot.

Could I rattle off what 8675309 is in binary, hex and octal? No, but I can open up a tool that can when I need to.

• You forgot 57005, commonly used as const `elvis = 57005;` Jun 9 '11 at 7:28

The only thing I have ever used octal for is file permissions on unix systems.

Hex and binary are very useful if you do any work with close to the wire protocols, or close to the metal data transfer. Fundamentally data flows in binary, which is trivially represented nibble at a time as hex.

You'll also find that data-sheets often quote hex values so it's better to show the value in code as it appears in the datasheet.

If you use either of them much you end up fairly proficient at converting to and from decimal in your head, at least for common values.

All that said; I suspect the heavy emphasis is mostly historical. As you say there are plenty of programmers who have little need for anything other than decimal.

You are actually asking why learn power of 2 number representations?

Computers are made of circuits, electrical current flows through the circuits in two different levels, high and low to represent the two level of currents, we use binary digits because they can hold two states, either one (high) or zero (low).

Binary digits form patterns. For example, if the only way that you and I can talk, is through out a circuit, we can establish that if you want to send me the letter A, you will send me the binary pattern: 1000001. Since I'm lazy, I don't want to memorize the 7 seven digits. Rather, I will use a power of 2 numbering system to represent large binary digits into a smaller one. I can use 8(2^3), or 16(2^4).

As you can see most computer hardware and software use a binary representation and we humans use power of 2 representations like octal and hexadecimal to read the binary representation in a more efficient and painless way.

Now example of the average programmer that needs to understand power of 2 representations:

1. ASCII
2. Unicode
3. Understanding memory management programming (stack, heap,memory addresses, core dumps)
4. Debugging
5. Reading binary data is done on mostly in Hex editor.

Now my last two cents, I'm very confident that you can learn pretty quickly any power of 2 representations (since you already managed intro programming courses).. You might forget conversion, but it shouldn't be a foreign concept if you want to be an average programmer.

I've never used octal but it's not unusual to see hex in the debugger and on occasion it makes a lot more sense to use hex in your source code (normally, because the underlying data is bit flags.)

I don't know whether there is much need these days, but many years back, when I was a Systems Programmer, being able to read and understand hex was essential. I would be presented with a storage dump (all in hex) and decode the hex representation back into IBM Assembly language. After doing that for a while you end up being able to do it directly - read the hex and write the assembly equivalent. Very handy for debugging. Adding and subtracting hex values was useful for computing offsets from base registers.

I suspect there is little need for it in practice now, but knowledge of it can hardly be a bad thing.

• That was where I acquired my hex skills, too. Later, sharpened when I was forced to debug code without a symbolic debugger on VAX/VMS (we shipped code to customers without any symbol info). Nowadays, I rarely use it, although we encode some info in certain URLs in hex, and once in a while it's helpful to be able to decode them on the fly.
– TomG
Jun 9 '11 at 1:55

It's not about being "fluent" in reading binary / hexadecimal, but comfortable enough that you can quickly do a mental conversion when you encounter them. Imagine programming without being comfortable with simple arithmetic, and you had to go to a calculator every time you needed to multiply by two.

Hexadecimal / binary is important because this is the language that computers speak in. You will invariably encounter it in places, especially when going through debugging exercises and your data is in hex.

I would also emphasize the importance to understand base-2 in the context of how different numeric types are represented internally, and how arithmetic works. With this you'll have a better grasp on when and how to deal with floating point rounding issues and integer overflow, for example.

As one more example, bitwise operations and bit flags are still prevalent in programming, and this is another place where an understanding of base-2 is important.

Really, the only time I've seen something other than base 10 is for colors in CSS,

You've never had to look up a character in the Unicode code charts? Never seen a URL that had `%20` in it? Never used a GUID? Never seen an IPv6 address? Never wrote a `BLOB` literal in SQL? Never viewed a file in a hex editor? There's a lot of computer-related stuff that's conventially notated in hex.

As for octal, it's rare nowadays, but still used for Unix filesystem permissions.

Even if you're able to avoid ever doing any "close to the wire" programming, it's still important to be aware of the fact that computers operate in binary, for one simple reason: Abstractions leak.

The `int` abstraction in most languages leaks its fixed-width nature. Integers overflow, and they do so at "round" binary numbers like 231. A decimal-only thinker wouldn't be able to explain the Year 2038 bug.

The `float`/`double` abstraction leaks its radix of 2. If you write `0.1`, you really get 0.1000000000000000055511151231257827021181583404541015625. And you'll get bugs if you were expecting an exact 0.1.

Recognizing particular numbers whose patterns are simple in other bases is often a huge clue when solving bugs. If your answer is wrong by 347, that maybe doesn't mean anything, but if it's off by 256 or 128, perhaps that does mean something. If you put -1 into an unsigned 16-bit data type, you get 65535, which is 1 less than 65536. If you happen to know 2^16, you spot your problem immediately.

As for octal, take a look at these questions and see if recognizing octal when you accidentally ask for it would have made any of these people better programmers.

There are some highly effecient math and data compression techniques you can use when you understand these systems and how they work. You probably will not use them much in your first few jobs. But having them in your back pocket when you become a senior and you are asked to make the overworked legacy system running on the underpowered overworked dinosaur server is nice to have.
It gets more important when you are dealing with controllers and electronics that do not have an api. Especially if you are writing that api.

In intro to programming courses that are part of study in computer science, it makes a lot of sense to know that material well. You revisit the topic when programming in assembly language, when designing hardware, taking a course on formal languages, etc. All the electrical engineers at my university require a course in intro to programming and they'll likely continue to use that information. Outside of that, not terribly important.

Octal numbers are occasionally useful when dealing with charsets. The latter are byte based, and one octal = 8 bits = one byte. In UTF-8, for instance, non-ASCII characters can have two or more bytes; octal numbers are more convenient to represent them than hexadecimal numbers.

Bits are useful because... hey! You do know that your computer is constantly dealing with 0s and 1s, right? I mean seriously... It's not merely about being able to joke that computer scientists are the only ones who know that 1 + 1 = 10. It's also useful for bit-related operators or as varbits. The latter allow to reduce the storage requirements in databases when dealing with series of flags.

As for hexadecimal, I take it you've never opened a hex editor to boost your RPG character's stats and equipment. Had you done so instead of downloading a character editor, you'd know full well why it's convenient to be able to make sense of hex numbers. ;-)

• I think you mean "octet", not "octal". One octal digit is three bits. The use of octal constants for non-ASCII characters is a holdover from the early days of C, which was developed on a PDP-11, which used octal representation in most of the documentation (see this PDP-11 reference card).
– TMN
Jun 15 '11 at 17:53
• I might be. English isn't my mother tongue. :-) Jun 15 '11 at 17:54

I graduate from university 3 years ago, and I think it is very important to be able to read and write hex numbers. I mess with a lot of large XML files for work (large meaning 100MB+). Sometimes you will get XML file that complains invalid XML character, which is not displayable in any text editor so I had to use Hex editor and write code to pinpoint the invalid characters. That task would be very hard without knowing hex number.

Many years ago I learned the value of hex while working on 8 bit systems.

The clarity of understanding that something was located at B000 or E7FF was amazing.

Yesterday I needed to know exactly what characters were at the end of a line of text. Knowing the difference between 0x0A and 0x0A 0x0D can be really important.

Does anyone have a good example of where the average programmer would actually use an octal number?

Octal these days is pretty rare, but I use hex very frequently, and often think about problems in binary.

I program primarily in C and C++, with some Objective C, and do a lot of work with raster and vector graphics on Linux and Mac OS X. In those arenas, it's paramount to write code that runs efficiently and makes good use of storage. You also have to understand the way the machines internally represent what you're working with. The most convenient way to look at that is in hex. For instance, a standard 24-bit color pixel is represented in three bytes, and knowing at a glance that 0x000000 is black, 0x00FF00 is red, and 0x008000 is pink is really, really useful!

I also work a lot with international standards for file formats. One I've been working with recently is MXF, which is used for storing video for broadcast, DVDs, etc. It's a binary format, and again, it's most easily dealt with using hex or sometimes binary. When you're debugging why some MXF-based video isn't playing right on your system, it's really handy to be able to glance at some 32-bit field and realize the bit to blank the screen is inadvertently set - and you can do that in hex, but it's pretty much impossible in base 10.

If you're going to spend your career writing Perl to massage text strings, then no, you probably don't need to be very familiar with hex, octal, or binary. But the moment you start dealing with the kinds of things I do, hex and binary at least are essential.

You should know hexadecimal if you want to be a programmer. It would just be too awkward for you to have to admit at work on the rare day you need to know it that you don't understand it.

Doesn't mean you have to be able to add hexadecimal numbers in your head. It starts messing you up on the rules for regular addition if you do anyway. :)

What binary, hex and octal have in common is not that they are not base10, but that they are all powers of two. Since Computers are inherently binary, this gives each of them some application where they are the most appropriate or efficient way to display and deal with data.

This used to be very important, back when all programming was low level. In high-level programming that today, power-of-2 Number systems are a lot less important. Having a thorough introduction to them in every programming course might be a relic of the olden days.

But these numbers systems still have their uses, even when you work in high-level languages. Color, for example, is still stored in 24bits, 8 bits per primary color. And since hexadecimal is the best way to represent a byte in a human-readable way, it is even part of CSS, which is supposed to be usable by people who never had an introduction to programming.

You can't understand computers without understanding binary. An introduction to binary is a necessary part of every thorough introduction to programming. You may not need to do a lot of conversions between number systems in everyday work, but doing exercises like that is the only way to really get familiar with these number systems*. Knowing more than one non-base10-number system is the only way to properly understand, that data can be represented in many ways, all of them valid.

• As John von Neumann said: "[..] we don't understand things, we get used to them."

I think conversion as such from one base to another is not very important for programming. In high level programming you don't need the conversions (and might you ever do so, lib functions and the calculator are available.) When you dive into lower level programming, you're not in an introductory course anymore.

I think two (related) issues are important to cover in a basics course.

1. About encoding. It is not about mathematical conversion but about using numbers (any type of numbers) to store information (any type of information). You could illustrate this with morse code or paint by numbers as well, if you'd wanted to. But since computers rather use binary and binary usually is displayed as hex, things usually are illustrated with hexy examples. (And, while they are at it, they might explain a bit about line endings, which have been mentioned in this topic. I'd only advise to recognise the various shapes and forms this could take, a few of those are 0x0D, 0x0A, CRLF, '\n' and '\r')

2. Overflow issues. Once again, there is no need to illustrate this with hex. You could use the y2k example (which had nothing to do with hex whatsoever) Here also I'd just advise to recognise the various most likely indicators (255, 32767, 65535, 2M14) Why they are indicators is directly linked to the bytewise nature of internal storage, but the conversion is not the important part.

I disagree that you need to know it for bitflags (because in an introduction course of programming, named constants are much more instructional and useful.)

If you go into low-level embedded programming, you will be using hexadecimal. It is used for things like specifing bit patterns in hardware registers, and byte values in memory dumps. You will also learn to use every bit-wise operator in whatever programming language that you use.